Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tech.allo-media.net

Post reply on HN
Print view View original

41–50 of 78 posts

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

#41

Post by 0815test »

Evidlo wrote: 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…

"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.)

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

#42

Post by weiming »

ngngngng wrote: post #21

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…

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...

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

#44

Post by estebarb »

apta wrote: post #23
dev_dull wrote: 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’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.

Actually is pretty good. The world have a lot of bugs in prod because C doesn't zero newly allocated memory (heap or stack).

There are APIs with autogenerated structs that span a lot of fields (even thousands)... Imagine having to initialize each field when you just want... the default zero value...

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

#45

Post by saghm »

dev_dull wrote: 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…

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.

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

#46

Post by stcredzero »

> This was the show stopper for me. I realized that I couldn’t rely on the compiler to get my back when I was doing mistakes.

No! One shouldn't mindlessly rely on the compiler "to get your back." Instead, one should code (or alter code) so that you've manipulated the situation, such that the compiler will flag any errors. With a language like golang, this means that you should make sure that the "zero values" are always copacetic. (Analogous to crash-only software.)

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

#47

Post by stcredzero »

sytelus wrote: post #24
dev_dull wrote: 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.

It's not "you" in the traditional formulation. It's "CPU." You, the programmers, often have to pay continuously for "you pay for what you use."

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

#48

Post by fauigerzigerk »

whateveracct wrote: post #8
dev_dull wrote: 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.

I think there is a wider issue. Go simply does not provide a way to restrict the state of public struct fields.

Enforcing the initialization of all fields achieves relatively little given that public fields could easily be modified elsewhere. Requiring initialization to anything more specific than an automatic zero value is only useful in languages that have read-only fields.

So the only way to handle this in Go is to make struct fields private or accept that all combinations of public field values are valid (including the zero value) and deal with it at the point of use (or rather at all points of use).

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

#49

Post by steveklabnik »

estebarb wrote: post #44
apta wrote: post #23

Earlier quoted context omitted.

> 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.

Actually is pretty good. The world have a lot of bugs in prod because C doesn't zero newly allocated memory (heap or stack). There are APIs with autogenerated structs that span a lot of fields (even thousands)... Imagine having to initialize each field when you just want... the default zero value...

There are more options in the design space than those two extremes. Rust does not do either of these two things, for example. It will not let you use something you haven’t initialized, but it also doesn’t force you to declare a default value for each type. If a default value makes sense, you can make one, but you still have to explicitly ask for a default, rather than it implicitly happening.

I think each of these three languages have made the correct choice, given their design ideals.

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

#50

Post by jdefr89 »

kahlonel wrote: post #27
elnygren wrote: post #22

Earlier quoted context omitted.

Maybe you should try the dev experience of Elm or ReasonML before shooting down the author’s comments. I get what you are saying and I also get what the author is saying it might be that you are missing something truly great in our engineering field.

If the author had explained a real reason for abandoning Python in favor of Go, it would've made a lot more sense to write this article. "Not feeling it right" isn't how engineers choose their tools. He could've said that he wanted to try something other than Python, and I would have respected that. On top of it, his reason to switch from Go to Rust is laughable at best.

I also can’t believe no one mentioned one of the things Go does best... Concurrency. When it comes to its concurrency and parallelism model. Go is just awesome.
Post reply on HN