Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not related to the article, but after years of using Rust, it still is a pain in the ass. While it may be a good choice for OS development, high frequency trading, medical devices, vehicle firmware, finance software, or working on device drivers, it feels way overkill for most other general domains. On the other hand, I learned Zig and Go both over a weekend and find they run almost as fast and don't suffer from memory issues (as much as say Java or C++).


This comment would have been more useful with some qualification of why that’s the case. The language, tooling, library ecosystem? Something else?


For me the hangup is that async is Still Hard. Just a ridiculous amount of internal implementation details exposed in order to just write, like, an http middleware.

We looked at proposing Rust as the second blessed language in addition to Go where I work, and the conclusion was basically... why?

We have skilled Go engineers that can drop down to manual memory management and squeeze lots of extra performance out of it. And it's still dead simple when you don't need to do that or the task is suitable for a junior engineer. And channels are simply one of the best concurrency primitives out there, and baked into the language unlike Rust where everything is library making independent decisions. (to be fair I haven't tried Elixir/Erlang message passing, I understand people like that too).


For Go, it's a design decision. From the start, they strived to make compilation as fast as possible.

https://en.wikipedia.org/wiki/Go_(programming_language)#Desi...


Not to be that guy who comes to Rust’s defense whenever Go is mentioned, but... Rust protects from a much larger class of errors than just memory safety. For instance, it is impossible to invalidate an iterator while iterating over it, refer to an unset or invalid value, inadvertently merely shallow copy a variable, or forget to lock/unlock a mutex.


If only these were common problems that were difficult to otherwise avoid.


I like Rust, but I think this post is unfairly downvoted. Rustaceans often annoyingly point out that "you can't use super-common-footgun X with Rust!" which, while true, they also omit the compromises made are immense (frankly, compiler performance is one of them).


The parent did not mention any of these compromises, beyond claiming that they are uncommon (which is untrue for many domains)


They are uncommon in many languages though that don't require Rust's type system, such as functional languages that simply pass values around and nothing else.


Nah, bringing out this argument in any thread that dares to mention whatever the commenter dislikes is just plain old off-topic. Go threads get people complaining. Rust threads get people complaining. The complaining is not a great addition to the discussion.


Does it really have to be either or?

I get the feeling that spending a lot of time in Rust makes you believe not having that kind of backup is madness.

Yet programmers all over the world get by just fine without it.

And it's not free by any means, there's a fair bit of a learning curve and increased effort involved.

Can't hurt the language to take these problems seriously, can it?


Rust feels like wearing a giant bubble just to go outside safely.

C++ feels like driving a car. Dangerous but doable and often necessary and usually safe.

(Forth feels like being drunk?)


Any non-trivial C++ program includes unchecked int casts


Could you elaborate on the memory issues in all four languages that you ran into?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: