Live data from Hacker News

From Python to Go to Rust: an opinionated journey (2018)

tech.allo-media.net

31–40 of 78 posts

Re: From Python to Go to Rust: an opinionated journey (2018)

#31

I've yet to try Rust. But Go is the best and worst thing to happen in my career. Best because it's amazing, worst because now I don't like working in other languages. I'm trying elixir currently, and it makes me want to rip my hair out. No for loops, no typed parameters, implied returns. Who in the world though any of this was a good idea? IO.puts() refuses to print certain objects (list of ints) and just prints a ne…

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.

Re: From Python to Go to Rust: an opinionated journey (2018)

#32

I've yet to try Rust. But Go is the best and worst thing to happen in my career. Best because it's amazing, worst because now I don't like working in other languages. I'm trying elixir currently, and it makes me want to rip my hair out. No for loops, no typed parameters, implied returns. Who in the world though any of this was a good idea? IO.puts() refuses to print certain objects (list of ints) and just prints a ne…

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.

Re: From Python to Go to Rust: an opinionated journey (2018)

#33
post #6

> I compiled the code and … no error message. Everything went fine. But?! I just added a field to a struct, the compiler should say that my code is not good anymore because I’m not initializing the value where it should be! This is your big hangup with Go? You added a new field, didn’t use that field anywhere, and the compiler didn’t complain? I’ve heard a lot of valid criticisms of the language but this is a new one…

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!

Re: From Python to Go to Rust: an opinionated journey (2018)

#34
post #6

> I compiled the code and … no error message. Everything went fine. But?! I just added a field to a struct, the compiler should say that my code is not good anymore because I’m not initializing the value where it should be! This is your big hangup with Go? You added a new field, didn’t use that field anywhere, and the compiler didn’t complain? I’ve heard a lot of valid criticisms of the language but this is a new one…

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.

Re: From Python to Go to Rust: an opinionated journey (2018)

#35
The “zero value of a type should be useful” concept is pretty fundamental to Go’s design. You can imagine compiler tooling that didn’t alter the language allowing you to catch unintended uninitialized values, but a language that changed the underlying default would no longer be Go.

Re: From Python to Go to Rust: an opinionated journey (2018)

#36

I've yet to try Rust. But Go is the best and worst thing to happen in my career. Best because it's amazing, worst because now I don't like working in other languages. I'm trying elixir currently, and it makes me want to rip my hair out. No for loops, no typed parameters, implied returns. Who in the world though any of this was a good idea? IO.puts() refuses to print certain objects (list of ints) and just prints a ne…

This is really interesting to read. I've been writing Go for about ~4 years professionally, and recently (Agree about typed parameters + implied returns, but you can get some of that back using guards + dialixer/dialyzer.

Re: From Python to Go to Rust: an opinionated journey (2018)

#37
post #29
post #6

> I compiled the code and … no error message. Everything went fine. But?! I just added a field to a struct, the compiler should say that my code is not good anymore because I’m not initializing the value where it should be! This is your big hangup with Go? You added a new field, didn’t use that field anywhere, and the compiler didn’t complain? I’ve heard a lot of valid criticisms of the language but this is a new one…

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…

The problem with using the positional method is that

1) It's much more difficult to read since you have to know the position of elements of the struct

2) You swap one compile time error for another: in the case you add and remove a field of the same type, it's entirely possible the program will compile fine if you use the positional initialization instead of the named one.

#2 makes me think that the author would still be unsatisfied

Re: From Python to Go to Rust: an opinionated journey (2018)

#38
post #26

I was working on a simple Rust CLI program to parse JSON from the Github API, but I got turned off by some of the unfriendliness of the available http libs. One http library pulled in dozens of other crates and turned my 10 line program into a 50MB binary [0], while another had an unpleasant api [1]. [0] https://docs.rs/reqwest/0.9.18/reqwest/ [1] https://docs.rs/hyper/0.12.29/hyper/client/index.html Maybe I have too…

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.

Re: From Python to Go to Rust: an opinionated journey (2018)

#39
post #24
post #6

> I compiled the code and … no error message. Everything went fine. But?! I just added a field to a struct, the compiler should say that my code is not good anymore because I’m not initializing the value where it should be! This is your big hangup with Go? You added a new field, didn’t use that field anywhere, and the compiler didn’t complain? I’ve heard a lot of valid criticisms of the language but this is a new one…

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 stron…

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

To be fair, isn't that implied since Go uses a GC? The "pay for what you use" model is only really viable for languages that don't rely on a fixed GC runtime. (You could have "pluggable" GC libraries like the Boehm collector for C/C++, but those imply very different tradeoffs.)

Re: From Python to Go to Rust: an opinionated journey (2018)

#40
post #6

> I compiled the code and … no error message. Everything went fine. But?! I just added a field to a struct, the compiler should say that my code is not good anymore because I’m not initializing the value where it should be! This is your big hangup with Go? You added a new field, didn’t use that field anywhere, and the compiler didn’t complain? I’ve heard a lot of valid criticisms of the language but this is a new one…

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

Isn't this something you could catch with a linter, if you wanted to?
Post reply on HN