Live data from Hacker News

Tell HN: Rust Is Complex

news.ycombinator.com

21–30 of 102 posts

Re: Tell HN: Rust Is Complex

#21

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

[deleted]

Re: Tell HN: Rust Is Complex

#22
Yes - 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 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

#23

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

#24

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

> There's nobody forcing you to use Pin ...

... in your greenfield solo project with no legacy code or third party contributors.

Re: Tell HN: Rust Is Complex

#26
I agree. I've played with Rust a bit and I program with Go for work. Go is much much more productive for me. Yes, it has rough edges, but it's good for getting stuff done. I feel like everything I've done in Rust would take half the time in most other languages I know

Re: Tell HN: Rust Is Complex

#27

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

JSON marshalling is a big one

Re: Tell HN: Rust Is Complex

#28
post #23

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

This is true, though. You can write most programs with simple use of types as template rags for containers, and defining only simple templates, where you just abstract over the given type itself in a “find and replace” way (no type traits, sfinae, template overload / recursion stuff).

Re: Tell HN: Rust Is Complex

#29
post #25

Nim is far less complex, but isn't as popular. The community is working quite hard to change that though.

I really like Nim. I was able to build some non-trivial things in it after just a few hours of googling and reading documentation (supplemented with a few questions on IRC). I do sometimes worry though about investing in a language that, due to its lack of popularity of "catching on", may never have the richness of tooling and packages/libraries needed to use it in the context of a larger project or larger team. But perhaps that concern is misplaced...maybe it's a social thing where you feel a bit out on your own when there isn't a large community coalescing around the language.

Re: Tell HN: Rust Is Complex

#30

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

Far from an expert in Go or Rust, but I think the use-case for Go is you need to do something very by-the-numbers and you want it to be easy to maintain and performant.

Once you start reaching for more off-the-shelf solutions, you hit diminishing returns with it as a language.

Post reply on HN