Live data from Hacker News

Ask HN: What's the Deal with HN and Rust?

news.ycombinator.com

51–60 of 108 posts

Re: Ask HN: What's the Deal with HN and Rust?

#51

Rust might be a better C++. (Zig is the better C) The memory safety thing seems to be appealing to some people who believe it will dramatically reduce the security issues found in many software. (they usually know very little about actual security exploits) Rust is building a cult-like community around it, and I think it could be its demise, I personally hate it (the community)

> The Chromium project finds that around 70% of our serious security bugs are memory safety problems. Our next major project is to prevent such bugs at source.

https://www.chromium.org/Home/chromium-security/memory-safet...

> As was pointed out in our previous post, the root cause of approximately 70% of security vulnerabilities that Microsoft fixes and assigns a CVE (Common Vulnerabilities and Exposures) are due to memory safety issues. This is despite mitigations including intense code review, training, static analysis, and more.

https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...

Removing 70% of security exploits, especially those which can easily lead to arbitrary code execution compared to e.g. logic bugs or DoS issues right at the compiler seems like a huge win?

Re: Ask HN: What's the Deal with HN and Rust?

#52

Earlier quoted context omitted.

There isn’t anything you can do in Rust that somebody couldn’t do in C-Thulu, but the Rust version might be secure and the C-Thulu version won’t be.

There are lots of things C++ can do where Rust can't (ex. templates in C++ are much more powerful than Rust's generics as of now), and lots of things Rust can do where C++ can't (ex. handling memory ownership in a much more secure way, hygienic and procedural macros). You might still want to use C++ for any sort of complex programming involving numerical computation and graphics (Rust is getting there but is still a…

Note that generics in Rust are not intended to replicate everything that C++ templates do, Rust has macros for the more complex uses. There's also a lot of vaporware coming from C++ standard development proposals about "metaclasses" and "reflection" being added to some future version of C++, this would basically be their way of doing the equivalent of hygienic macros in Rust. C++ has also added recent support for parallel and heterogenous programming (GPUs, accelerators etc.) for which Rust has no equivalent as of yet.

Re: Ask HN: What's the Deal with HN and Rust?

#53
post #41

Earlier quoted context omitted.

Same take. I don't see Haskell / Erlang / Elixir and the like truly ever taking off. It's not because they aren't awesome (because they are) - it's because what they solve isn't as desperately needed as what Rust solves. I don't feel like this aspect is debatable. Our systems are miserably insecure and unwilling to trade off performance to become more secure. Without Rust or something like it, there's no chance - tha…

> it's because what they solve isn't as desperately needed as what Rust solves. Undoubtedly, the issue of memory safety while remaining performant is a game-changer, but the word need is a bit strong here...

> but the word need is a bit strong here...

When 52% of curl's security vulnerabilities were due to it being written in C (mostly buffer overreads/overwrites), I say "need" is indeed adequate.

https://daniel.haxx.se/blog/2021/03/09/half-of-curls-vulnera...

Re: Ask HN: What's the Deal with HN and Rust?

#55
It solves a lot problems, but mainly it solves problems in a kind of idiomatic way that makes it feel like a big paradigm shift, which contributes to genuine enthusiasm. This combined with the massive funding and community around it helps it feel like something you can give yourself to a be supported.

Whether its the best solution or "deserves" its hype is not a real fruitful question you can ask, as there are many things you need a computer to do, and some of them aren't systems programming. Some things benefit from different kinds of ergonomics, thats ok.

Is there a language that is more funded out there right now?

Re: Ask HN: What's the Deal with HN and Rust?

#56
post #47
post #32

Earlier quoted context omitted.

Curious - what class of problems do you see Rust and its ecosystem handling that C++ doesn't?

Rust may allow 100 engineers to work on the same codebase without spending all their time debugging memory corruption errors. I say "may" because I don't have firsthand experience in a team that big.

I'm hoping to hear something other than debugging memory corruption errors. I've worked in C++ for 15 years in 4 different organizations and across many different teams and memory corruption was never really an issue, certainly not enough of an issue to abandon C++ and adopt a whole new ecosystem. This is the primary reason I hear for adopting Rust and it just isn't an issue for me so I'm interested in learning what other classes of problems does Rust and its ecosystem resolve?

Re: Ask HN: What's the Deal with HN and Rust?

#57
As someone who looks at Rust and other alternative languages every now and then. I think many C/C++ programmers are looking for an alternative. C/C++ accumulated a lot of legacy stuff over the years, and things like #includes, .h vs .cpp, non-trivial metaprogramming, limited IDE capabilities, no standarized package manager show how old these languages are.

Compare it to Rust, which has one build tool/package manager. No more hunting down dependencies, arguing make vs cmake vs 20 other tools. 99% of projects just use cargo and building a project on every platform is just one cargo build run away. Compiler is smart and can show you many errors in your code that C++ never could. Old mechanisms like header files are replaced with a modern module mechanism. Also some interesting features like the traits system.

All that with performance close to C/C++ and with increased safety. Also, there is a lot of hype behind the language making it reach critical mass. It's not surprising to see many people flock to it. Some people dumped C/C++ in the past for Java/C#, but these languages don't support the same usecases as C/C++ do. Rust does.

Personally I dumped C/C++ for D years ago and don't regret it. It's not as popular as Rust is, and doesn't have the same ecosystem or big companies behind it, but it works for my needs. If Rust existed at the time I was looking for an alternative, I'd probably be using Rust now.

Re: Ask HN: What's the Deal with HN and Rust?

#58
I know that Rust seems quite powerful, but after years spent invested into learning C-family languages (C, C++, Java, Javascript, etc) it's just a pain to learn.

I've not personally spent much time in it, but I hear the biggest complaint is still the compiler support/performance being somewhat random. Can anybody here speak to that?

Re: Ask HN: What's the Deal with HN and Rust?

#59
post #46

Well, many people don’t want to pay the factor of 2 performance cost of a managed language like Java and strcpy in C is Turing complete and most code has to portable to at least x86 and ARM (often both 32 and 64 bits) so assembly is out…

> 2 performance cost of a managed language like Java It can be a lot worse too. Java lacks the ability to have really compact data structures and can not lean in too much into the hardware acceleration without becoming incompatible. You can't exactly set `--fast-math`. Shame GCJ got dropped. > strcpy in C is Turing complete Not something I've heard of - is this an abuse of Unicode? > most code has to portable to at l…

> strcpy in C is Turing complete

Maybe GP meant printf [0]?

[0] https://www.ioccc.org/2020/carlini/index.html

Re: Ask HN: What's the Deal with HN and Rust?

#60
post #46

Well, many people don’t want to pay the factor of 2 performance cost of a managed language like Java and strcpy in C is Turing complete and most code has to portable to at least x86 and ARM (often both 32 and 64 bits) so assembly is out…

> 2 performance cost of a managed language like Java It can be a lot worse too. Java lacks the ability to have really compact data structures and can not lean in too much into the hardware acceleration without becoming incompatible. You can't exactly set `--fast-math`. Shame GCJ got dropped. > strcpy in C is Turing complete Not something I've heard of - is this an abuse of Unicode? > most code has to portable to at l…

> strcpy in C is Turing complete

I was curious too, but my google-fu did not succeed. The closest I found is about printf being Turing-complete [1], which is also new to me.

[1] https://www.ioccc.org/2020/carlini/index.html

Post reply on HN