5 ms·
If you're already writing Rust, why would you even bother writing Go?
by kmicklas 9y ago
If you're already writing Rust, why would you even bother writing Go?
- tejasmanohar 9y agoIn my and many other opinions, Go is practically superior for the 90% case.
- legendiriz68 9y agoGo is probably one of the worst and most useless language invented for the last 20 years lol.
- kmicklas 9y agoGo deserves a lot of hate because they set out to create a language from scratch without any legacy baggage, but instead of learning from the mistakes of the past and consulting people who actually know a thing about programming languages, they repeated all the same mistakes and then some.
- schmichael 9y ago-
- ewillbefull 9y agoI think you misread the parent comment. :)
- Thaxll 9y agoThe same reason why Go is used to write many applications where Rust is not. - Fast compilation - Multi platform - Great tooling - Good std lib - Easy learning curve - Fast enough for most scenarios - Good concurrency model
- kmicklas 9y ago- Fast compilation In return, you spend more time debugging since there are no interesting static guarantees. - Multi platform So is Rust? Even if it weren't, you've already tied yourself to the platform support of Rust at this point. - Great tooling Not familiar enough to comment on this one. - Good std lib I can't take Go's stdlib seriously with the way they handle errors. - Easy learning curve Despite using it for a year I still have to google Go's syntax and semantics daily. By far the least consistent and hardest to learn general purpose language I have touched. - Fast enough for most scenarios Sure. - Good concurrency model This is literally just wrong. How can you claim to be serious about concurrency when you have no concept of immutability in your language?
- Vendan 9y ago- - Fast compilation - In return, you spend more time debugging since there are no interesting static guarantees. I spend almost no time debugging my Go code... It generally either works correctly, or fails to compile... and in the cases where it doesn't work correctly, I'd prefer to have a test that makes it obvious what went wrong, and then make the test pass. - - Great tooling - Not familiar enough to comment on this one. Go's tooling is one of the reasons I use it, esp. the very strict formatting style - - Good std lib - I can't take Go's stdlib seriously with the way they handle errors. I prefer the way Go handles errors, cause it makes it so all control flow is visible by default. - - Easy learning curve - Despite using it for a year I still have to google Go's syntax and semantics daily. By far the least consistent and hardest to learn general purpose language I have touched. I'd seriously question this, I was competent in the language after about a week, meaning at the point of just having to look up package specific stuff. Granted, I have a lot of background in C family languages, but still... - - Good concurrency model - This is literally just wrong. How can you claim to be serious about concurrency when you have no concept of immutability in your language? Share memory by communicating, don't communicate by sharing memory. Yes, it's completely different from what most people are used to, but it's a valid paradigm. I'd go look up "communicating sequential processes" and do some reading if I were you.
- 9y ago
- saghm 9y agoI'm guessing this is more intended to facilitate using Rust in projects primarily written in Go rather than vice-versa.