The choice between Rust and C-derived languages is not only about memory safety
bbuyukliev.blogspot.com
The choice between Rust and C-derived languages is not only about memory safety
1–10 of 20 posts
Re: The choice between Rust and C-derived languages is not only about memory safety
#2The problem is not that {language} does or does not do or have {thing}. The problem is managers expecting the work product of coders who only half know the language that they are working in to be productionizable.
Re: The choice between Rust and C-derived languages is not only about memory safety
#3I think this is weirdly resonated with me. I used moved to Rust from C for embedded programming, and realized that my whole paradigm shifted on how I write programs.
Rust is much more than safe(r) C, it is different approach of architecting apps to have safer relations between components. Now that I am looking at my old code, I see how it would benefit from this paradigm.
And it also a 'problem' with Rust - it requires one to think differently. You can write Rusty code in C, and indeed results are just better, but trying to write Rust in C style would lead to fighting compiler and suffering.
Other languages, like Zig or Go, they chose different approach - to decorate C with modern features, and that works too.
Re: The choice between Rust and C-derived languages is not only about memory safety
#4Forget safety. Using enums in Rust is sheer delight. The fact they can even contain associated data is the really powerful. That alone makes me love the language. Especially with bitfields.
It cannot be matched in in C, even with a lot of macro magic. Plus, C is way too lax with type strictness and enums.
Re: The choice between Rust and C-derived languages is not only about memory safety
#5I think this is weirdly resonated with me. I used moved to Rust from C for embedded programming, and realized that my whole paradigm shifted on how I write programs. Rust is much more than safe(r) C, it is different approach of architecting apps to have safer relations between components. Now that I am looking at my old code, I see how it would benefit from this paradigm. And it also a 'problem' with Rust - it requir…
"A language that doesn't affect the way you think about programming is not worth knowing." ― Alan J. Perlis
Learning Rust definitely made me a better C programmer.
Re: The choice between Rust and C-derived languages is not only about memory safety
#6>None of this means Rust is "bad" or that C is "better". It means they optimise for different values. Rust optimises for correctness and maintainability under heavy abstraction. C optimises for transparency and minimalism under extreme constraints.
>Sometimes you don't want a language that keeps you safe. Sometimes you want one that simply gets out of your way.
D lang is a wonderful Goldilocks in this regard between C and Rust. It has D-as-better-C [1]. There's no head scratching macro, excellent meta programming, bare metal programming and fast compile time and run time [2]. The programming syntax is very intuitive with UFCS [3].
[1] Better C:
https://dlang.org/spec/betterc.html
[2] Ask HN: Why do you use Rust, when D is available? (255 comments):
https://news.ycombinator.com/item?id=23494490
[3] Function:
Re: The choice between Rust and C-derived languages is not only about memory safety
#7Forget safety. Using enums in Rust is sheer delight. The fact they can even contain associated data is the really powerful. That alone makes me love the language. Especially with bitfields. It cannot be matched in in C, even with a lot of macro magic. Plus, C is way too lax with type strictness and enums.
That’s right. And forget about the existing rustc compiler implement. If you have something in Rust like
let a: HashMap = immutable_map.iter().map(…);
Re: The choice between Rust and C-derived languages is not only about memory safety
#8Forget safety. Using enums in Rust is sheer delight. The fact they can even contain associated data is the really powerful. That alone makes me love the language. Especially with bitfields. It cannot be matched in in C, even with a lot of macro magic. Plus, C is way too lax with type strictness and enums.
Rust has two parents; it got its looks from C, but much of its character was inherited from its other, less commonly mentioned parent -- ML. Rust has a variation of the Hindley-Milner type system, quite similar to ML (or Haskell). Rust's enum and struct are algebraic data types, also known as sum or product records or types. The type system and pattern matching enable declarative and functional styles of programming that are much less natural to express in C.
Re: The choice between Rust and C-derived languages is not only about memory safety
#9This looks like it was written by an LLM. Not complaining, because my major use of LLMs is rubber-ducking, not code-generation, and I very often get responses like this when doing repeated iterations and deep-diving into a review/comparison.
The concepts are probably the authors, but the text we are seeing is probably the LLMs.
Regardless of the LLM overtones, this is still decent content.
Re: The choice between Rust and C-derived languages is not only about memory safety
#10As someone who has written C and C++ for 35 years and Rust for a decade now, the last five years professionally, I don't see the point.
Even when I need what C does "well" from the author's pov I can just wrap my code in a big unsafe {} in Rust.
I still get a bunch of things from the language that are not safety- but ergonomics-related and that I would't want to miss anymore.