From Python to Go to Rust: an opinionated journey (2018) (opens in new tab)

Go has two mechanisms for initializing structs, name based and position based.

    type Sample struct {
        A int
        B int
    }

can be initialized as Sample{A: 1, B: 2}, or Sample{1, 2}.

The name-based method allows arbitrary elision of fields, which will be initialized to their zero value. This includes Sample{}, which will be interpreted as a name-based initialization that specified no fields.

The position-based method requires all fields to be specified, in order, with the correct type, or it's a compile-time fail.

So if the author of the article could have gotten the latter behavior with a slight syntax tweak.

This would not necessarily entirely satisfy, though, since you can't do any mix-and-match, and in particular, it can be nice to have names on the larger structs even if you want them to be fully initialized, but there is no in-between. But, nevertheless, if you are willing to pay for the behavior that the compiler will complain on any type-changes to the struct, including growing or shrinking, Go has that.

It seems to be the Go community's "best practice", above my objections, to claim that all struct initializations MUST use the name-based initialization and that positional-based inits is a mistake, on the theory that if structs change and add fields it's important for all uses of structs to continue compiling without changes. If the author's introduction to Go came from a tutorial from someone who believed that, they could easily have picked that up mistakenly as a characteristic of the language itself.

My objection is that there's a time and a place for each behavior, and there have been plenty of times I've been grateful for the compiler pointing out every place I need to change my struct to include a new member because I could tell it was a "tuple-like" struct that should always be initialized with all the fields. You can argue with the putative "best practice" or agree with it, but fortunately it doesn't really matter because you can do the one you want regardless of what the community thinks. There is no chance either method is ever going to be removed.

I wouldn't have left Go just because of these but before you write this off as minor thing, I would suggest you look this as one of the core language design decision. It reveals two important language philosophies:

1. Go doesn't follow "you pay for what you use" model.

2. Go isn't too deeply invested in compilation as means for catching errors.

Above are not binary language decisions. If you go in one direction strongly then there are consequences in other. Therefore all languages chose some balance point (aka compromises). Go has chosen a balance point that is weaker than Rust (and may be even C++) but stronger than Python.

You're focusing on the wrong detail. The lack of compiler message isn't the actual problem, it's just a symptom of the fact that in Go, everything has an implicit zero value, and this leads to bugs.

Hell, just the other day I complained to my backend team that the PubSub event was passing null for a non-optional array, and it was traced to the Go code declaring a map variable without ever initializing it. The compiler never caught that, it wasn't until it hit my Swift code that it became apparent.

> I’ve heard a lot of valid criticisms of the language but this is a new one for me.

We've had bugs in prod because of this "feature". It's another bad design decision in golang.

It's a pretty big annoyance with Go though. I hate that all struct fields are optional.

Yes, this would be pretty easy to solve with an initialization function and using that everywhere. Change the arguments in the function prototype and the compiler will definitely complain!

I was confused too. At the end they say they'd rather do python than Go. And yet it was going so well until this issue which is not any better in Python.

The criticism is that a struct literal allows you to not specify some (or all!) of the field. The argument is that this is brittle since, as with what was described in the post, if you add a new field, you might forget to use the field in all instances of the struct being constructed.

Just wanted to correct some things, as a fan of both Elixir and Rust.

> No for loops

But we do have for loops? That's what comprehensions are: https://elixir-lang.org/getting-started/comprehensions.html

> no typed parameters

But if you need types on your parameters, you have Guards, which... check for type? Sure, you don't type every last parameter, but if you want that you can upgrade to Dializer and get that feature too. It's just not as useful as you likely treat it.

> implied returns

I understand that some may not like this, but it comes out of the idea that generally, you want to avoid "side effects"- ie, things in code that happen without anyone but the original function causing them being able to tell. Elixir doesn't completely lack them, as that would be pretty unreasonable, but it does at least ask that you're clear about the purpose of functions by having them always return something.

> IO.puts() refuses to print certain objects (list of ints) and just prints a newline, making it useless for debugging.

This seems like something must be going wrong. `IO.puts` certainly prints lists of ints, however, it might also be mistaking them for a charlist, which is definitely a concern. That's why generally, you want to use `puts` for text, and `IO.inspect` for data structures. As an added convenience, if you want to annotate your data structure with text, you can modify `IO.puts` like so: `IO.puts "List: #{inspect(list_of_numbers)}"`. That will parse the list to the inspect version and insert it into your `puts` line.

For the record, I'm not saying any of these necessarily shouldn't be a reason to not like Elixir- we all have our preferences, but the reason behind many of these choices is philosophical, and I'd be happy to explain anything else that has puzzled you, if you're still interested in learning more about Elixir.

This is really interesting to read. I've been writing Go for about ~4 years professionally, and recently (<6 months) jumped into Elixir (and a bit of Rust). They've been nothing but a breath of fresh air, and I can't wait to write more as I'm starting my new thing. I'm definitely more excited about Elixir as it's really, really pleasant to write and in some sense, a major increase in productivity.

Agree about typed parameters + implied returns, but you can get some of that back using guards + dialixer/dialyzer.

I also write Go for a living, and feel sort of the same way about other languages. But then I have some good news for you with Rust, you'd like it (at least I did/do). It's different from Go, for sure, and in my head fulfils different purposes from Go, but it's nice to have a choice between two things I like.

Fair warning, though, before Go, I wrote Delphi for a living.

You can accomplish iterations more concisely using other means, for example list operations in `Enum` [1]. Not too different from other modern languages often using `foreach` vs. i-based iteration.

Also, try `IO.puts inspect foo` for printing stuff.

`IO.puts` can be compared to print() behavior in other languages expecting toString() is fully implemented (`to_string` in this case for your custom typed data structs. [2][3])

[1] https://hexdocs.pm/elixir/Enum.html

[2] https://hexdocs.pm/elixir/String.Chars.html

[3] https://code.tutsplus.com/articles/polymorphism-with-protoco...

Nim is very nicel Not that it matters much in most cases, but the compiled binary sizes are also quite low compared to Rust.

I wonder if there's any performance difference between Cython and Nim.

"Crates" are just compilation units. Do you feel "turned off" if a C/C++ library includes "dozens" of source code files, some of which might come from outside projects? (A sibling comment mentioned --release already, which is obviously something that one should be familiar with when discussing Rust's performance.)

Yes, unfortunately reqwest pulls in lots of dependencies, but I think you should be able to get a binary under 10MB if you compile in release mode using the --release flag.

I get the fascination people have with Rust and I love to use Rust myself. Part of the fascination certainly is it’s tooling and that Rust nearly seems to force you to make the right decisions. I’ve never wrote in a language were I were so focused on the structure of my program rather than hammering in what I felt. And when you hit compile and it works, it usually does so flawlessly.

However I use Python very often still, just not for every task. Just like you said: Rust is another tool in the tool box and it isn’t that single purpose machine that you buy and use once for a single project, it is that japanese handsaw that is incredible useful and powerful in the hands of the right person. But sometimes you just need to make many cuts fast and then the handsaw (no pun intended) doesn’t cut it.

Python certainly has it’s place for me, but so does have Rust..