Live data from Hacker News

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

tech.allo-media.net

51–60 of 78 posts

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

#51
rust is great if you have enough experience to pick it up without dying trying. and you need to start reading the book. the enforced safety helps even experienced devs with a formal background to reinforce and see some concepts more clearly.

all that said, when you have to do advanced things and go unsafe, it can feel really annoying (fighting the compiler) and limiting. most common problems can be modeled in rust without issue, but if you have a clear idea of something that you want to do that's more advanced... the language will actively work against you, that's its goal. that has both a good and a bad side. maybe it will get better in the future. still an awesome language today.

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

#52

I went from python to go to nim. Actually I still like go - but nim is an easy transition from python. I think nim is the best thing out there for building tiny CLI utilities. It’s a fun language to code in.

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

Do you ever regret choosing "coffeescripter" as your handle? I loved CS and contributed to the CoffeeScript Redux compiler but the language is definitely pretty hated these days...

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

#53
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…

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.

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

#54

Earlier quoted context omitted.

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

I appreciate your work on Rust, I find it to be a very interesting language.

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

I feel that's kind of side-stepping the issue though. The approach that golang took could match their design goals, but it doesn't mean that those goals aren't a bad idea in the first place.

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

#56

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.

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

The sentence immediately following the phrase "it didn’t feel right anymore":

> Well, to be honest, it’s not really at “some totally random point” that it started not to feel right anymore, it was when I started to enjoy programming with a strongly typed language: Elm.

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

#57
post #50

Earlier quoted context omitted.

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.

[deleted]

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

#58
post #50

Earlier quoted context omitted.

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.

Making concurrency/parallelism easy is not necessarily a good thing. You need guard rails in place to reduce the risk of bugs.

Node.js does that by only having concurrency, not parallelism. Rust does that by having very robust memory safety checking.

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

#59
post #54

Earlier quoted context omitted.

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

I appreciate your work on Rust, I find it to be a very interesting language. > I think each of these three languages have made the correct choice, given their design ideals. I feel that's kind of side-stepping the issue though. The approach that golang took could match their design goals, but it doesn't mean that those goals aren't a bad idea in the first place.

For any set of correctness-improving primitives in a language, you can practically always come up with some disjoint set of additional primitives, and then make the argument that the lack of those additional primitives constitute "bad design". Sometimes you'll even be right (it's not clear to me in this case). But it will almost always be a boring argument.

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

#60
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…

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

Except when you've imported a package you're not currently using, that is a mortal sin :)

Post reply on HN