The problem with go is not it's simplicity, it's it's inconsistency . As a small-minded programmer my hobgoblin is tripping over having to remember that X works this way but not Y, which looks vaguely like x. It feels like the designers of go tripped over themselves to make things simple for some definition of simple and then ran into some feature they wanted and then just bolted the feature on without thinking about…
Do you have more examples? I’ll admit that Go is full of weird quirks, but nothing feels bolted on. Generics were agonized over for so long because they had to fit it within the existing language
Tell HN: Rust Is Complex
21–30 of 102 posts
Re: Tell HN: Rust Is Complex
#22There's even nobody forcing you to use async code. In fact it might be the wrong choice for > 99% of use-cases, since it adds complexity and limits on which functions can be called in certain places, adds limitations like not being able to perform recursive function calls, and can even lead to higher latencies (no preemption) and more memory usage (for `Future` state allocations) than the boring synchronous versions.
I've worked together with multiple teams building > 30 applications/services in Rust and had seen even > 100 engineers in those teams picking up Rust successfully. So for me there's more than enough datapoints that it's complexity is manageable after an initial rampup period of 1-3 month.
To be fair: What I definitely haven't found is engineers outside the Rust core group that really understands how async and Pin work - usually people just put async in function definitions and .await where the compiler asks and assume that will do it's job - which is mostly good enough. So yes, I definitely second that those details are hard. And even I - as someone who contributed to async/await standardization and was active in the async working group am giving up mentally in the new discussions around Pin/poll_fn safety. But as I said earlier - knowing Pin is not necessary to write programs successfully in Rust.
Re: Tell HN: Rust Is Complex
#23Yes - Rust can be complicated. However it doesn't have to be. There's nobody forcing you to use Pin. Even async code doesn't do, if you just stick to using library functions, don't write any Future implementation manually and just stick to async-trait. There's even nobody forcing you to use async code. In fact it might be the wrong choice for > 99% of use-cases, since it adds complexity and limits on which functions…
Re: Tell HN: Rust Is Complex
#24Yes - Rust can be complicated. However it doesn't have to be. There's nobody forcing you to use Pin. Even async code doesn't do, if you just stick to using library functions, don't write any Future implementation manually and just stick to async-trait. There's even nobody forcing you to use async code. In fact it might be the wrong choice for > 99% of use-cases, since it adds complexity and limits on which functions…
... in your greenfield solo project with no legacy code or third party contributors.
Re: Tell HN: Rust Is Complex
#25Re: Tell HN: Rust Is Complex
#26Re: Tell HN: Rust Is Complex
#27The problem with go is not it's simplicity, it's it's inconsistency . As a small-minded programmer my hobgoblin is tripping over having to remember that X works this way but not Y, which looks vaguely like x. It feels like the designers of go tripped over themselves to make things simple for some definition of simple and then ran into some feature they wanted and then just bolted the feature on without thinking about…
Do you have more examples? I’ll admit that Go is full of weird quirks, but nothing feels bolted on. Generics were agonized over for so long because they had to fit it within the existing language
Re: Tell HN: Rust Is Complex
#28Yes - Rust can be complicated. However it doesn't have to be. There's nobody forcing you to use Pin. Even async code doesn't do, if you just stick to using library functions, don't write any Future implementation manually and just stick to async-trait. There's even nobody forcing you to use async code. In fact it might be the wrong choice for > 99% of use-cases, since it adds complexity and limits on which functions…
Yes - C++ can be complicated. However it doesn't have to be. There's nobody forcing you to use templates......
Re: Tell HN: Rust Is Complex
#29Nim is far less complex, but isn't as popular. The community is working quite hard to change that though.
Re: Tell HN: Rust Is Complex
#30Complexity is relative. Go is a language for high-level application development. It has a runtime, garbage collection, and a sophisticated M:N threading scheduler that are all designed to help the programmer express themselves in terms of the problem domain. It competes with Java, C#, and (in some cases) Python or Ruby. Rust is a language for low-level systems programming. It needs far more complexity than Go because…
The issue with Go is it's a "worse is better" situation: it's easy to go from 0 to a limited amount of productivity, but then it peaks because of the impractical and unreasonable design limitations due to absurd governance decisions. It's too minimal and too limited in key ways out of design purity. Rust's syntax and verbosity sometimes leaves much to be desired or the convoluted syntax and structures to get interior…
Once you start reaching for more off-the-shelf solutions, you hit diminishing returns with it as a language.