The Rust I used to know (2022) | Hacker News Reader

The Rust I used to know (2022)

despairlabs.com

42 pointstodsacerdoti27 comments

I know, let's invent a new language that is supposed to make software transformatively more reliable -- and name it after the universal avatar of intractable decay.

> TL;DR: Rust is named after a fungus that is robust, distributed, and parallel. And, Graydon is a biology nerd.

https://www.reddit.com/r/rust/comments/27jvdt/internet_archa...

it's not that singular, from that exchange it's named after a bunch of things, including the metallic part (and fungus), but it's not certain

Wow, that’s even worse.

Another way of looking at it... If you create something from iron oxide in the first place, it can't rust.

Make a pull request changing it to Stainless Steel

Or Silver

To be honest, these choices look witless. Show, don't tell

Not sure if this is a piece in favor or against Rust.

Rob says he had so much fun with Rust, but a significant number of his projects were abandoned or are still "work in progress".

> but a significant number of his projects were abandoned or are still "work in progress".

That sounds like Rust is at worst the same as any other language people program in.

Hot take: It's nice that Box, Arc, etc. are all just types and nothing special to the user, but it's not as nice that modern async code in particular ends up with Arc<T>, :Send+Sync+'static, Future<Output=T>, copied absolutely everywhere and often taking up half of each function signature.

As a general rule, anything that can be orthogonal should be, but also as a general rule, more syntax should only be needed for non-default cases so the default is minimal. With modern async treating these things as effectively the default, these rules end up in constant tension. C++ has the same problem and it's getting worse and worse, and I hope Rust doesn't continue down that direction.

Calling C++ a strongly typed language is just objectively wrong. It's very much statically weakly typed. Static-dynamic and strong-weak are orthogonal

I think the world of programmers have spent a bit too much time trying to avoid pointers, inventing a whole bunch of different languages, mechanisms and with them a horde of other problems and useless complexities. Instead of this utter wastage, why not just use C?

That’s kind of ridiculous, Rust deeply embraces pointers and that’s why people struggle with it. Rust is way better at pointers than C.

Because 'C', as fantastic as the language is, is prone to users making errors, and errors cost (sometimes incredible amounts of) money, and even peoples lives. See the Great 1990 Telephone Crash for the former.

I like 'C', but I'd never get in an aircraft where a 'C' compiler was used for anything other than the in-flight entertainment system.

There's a lot of C code in avionics op systems, both new and old.

There are multiple static analysis frameworks for verifying C code in aviation; Frama-C and Astrée just to name two.

https://frama-c.com/html/overview.html

https://www.astree.ens.fr/

If you've ever got in an aircraft it's too late, you've almost certainly been in one using C for flight control functions.

I've worked in automotive where literally everything except the infotainment systems are in C.

Almost all, if not all, firmware is in C.

Also, not to mention every operating system.

I really don't know where the "bugs are horrible" argument grounds itself on. I've worked on large C, rust, go, python and even Haskell codebases. Everyone of them had their share of super corner case bugs.

The systems which use the simplest concepts and tools tend to have the least bugs cause they are more readable and hence fixable.

With high integrity code quality certifications like MISRA-C, a quality level that most folks with cry if forced to work daily under such restrictions.

And since most companies keep failing at achieving the quality that random C coders say it is so easy on the Internets, provided one is a good C coder with discipline, now we have cybersecurity bills that in the long run will make any application making use of C or derived languages, be under similar control as MISRA and friends.

Alterantively, one can use a safer language and not be so strictly regulated, as per those cybersecurity guidelines.

OK but surely there's stuff that you wouldn't do in C. Maybe stuff that would require too much C code. Its features are pretty limited.

This is not my experience. I switched from C++ to C for all my programming. C certainly does not bring much out of the box, but with some data structures libraries ts a very good language for almost all purposes. A lot of bad press which is not really justified IMHO. There is certainly a lot of old bad C code around, but modern C written using modern tools can be quite good. For example, there is no need to do buffer management or string manipulation using open-coded pointer arithmetic, one can wrap this in safe APIs and then it is as safe as in any other language.

Now if the likes of Apple, Google and Microsoft could find those C devs to show them how their security departments are doing it all wrong.

Microsoft and Google mainly use C++.

And every single verification framework for C code is way more challenging to work with than systems for a more modern language because in C as soon as you smell an aliasing relationship you are largely fucked for soundness.

> I'd never get in an aircraft where a 'C' compiler was used

So I take it you've never been in an airliner?

> but I'd never get in an aircraft where a 'C' compiler was used for anything

Enjoy walking, I guess.

Majority of CVE's are memory corruption. It is not possible to move into the future without resolving this problem. If we don't fix it now you will be regulated to inferior solutions in the future. Software will be tied up in red tape just like building bridges.

It will be interesting to watch insurance and liability protection require devs to act professional and choose proper tools, not excuse poor engineering with "just use old things I know."

There are plenty of other bugs causing CVEs, but there are certainly a lot caused by memory issues. I personally believe that C needs a safe mode, but also with existing tools (static analysis, sanitizers, etc.) one can improve things a lot. It is a bit unfair to compare billions of lines of old C code to newly written code in other languages. It would be interesting to compare modern C with modern tools to other languages. And, of course, all those billions of lines of old C code will continue to exist even if some people start to use other languages. So I think we need to improve C instead of abandoning it.

There isn't "modern C". You have to completely change the language to approach modern understanding of memory safety. C is the way it is because it was ignorant of what we know now. Progression of knowledge is why we deprecate and remove older tools.

This is Rust marketing but not reality. There are tools that ensure memory safety in C. Just - unfortunately - not open-source tools.

Reply on news.ycombinator.com