You must log in or register to comment.
I like to talk of ‘correctness’ (as in the objective quality) and ‘rigidity’ (subjective; generally better for larger programs and programs that need to be correct, but potentially worse for prototyping and flexibility).
Ultimately, what I care about as a programmer is, if I write/refactor/tweak some code in this language, how many weird edge-cases are ruled out or handled for me? How many unit tests do I have to write, to ensure this myself?
Python is relatively bad at that, even though it’s technically memory-safe, as the post mentions. The dynamic typing, for example, means some refactoring mistakes will just not show, unless you’ve got close to 100% integration test coverage.
So, yeah, I feel like this whole “memory safety” buzzword is lost on pretty much everyone working in a garbage-collected language, even though many of them would be extremely glad about a more correct and/or more rigid language.
Ive never gotten to write rust professionally, but I have always kinda winder d if it was marketed wrong. My thought was always that it should be sold as “easy” though. Its easy to write code. It’s hard(er) to make mistakes.
I kinda figure there’s a bunch of systems programmers with their heads up their asses who would never be caught dead writing in an “easy” language though, so it couldn’t go that way.
(I got bored and started skimming halfway though this article, but it’s neat to hear about up and coming languages I’ll never use at the end)
But it’s not easy. Understanding how memory works isn’t easy, and satisfying the borrow checker is even harder. There are quite a few things that the borrow checker rejects that are completely fine, so you also may need to relearn some idioms.
Perhaps it would be better to market it as encouraging “sustainable” code. By that I mean:
- lower chance of introducing concurrency bugs if you stick to safe rust
- smother, safer refactors due to the type system and borrow checker
- better long term performance because memory related performance issues are more obvious
- strong nudge toward smaller structures because a lack of inheritance makes massive structures more of a pain to deal with
And so on. It encourages a more sustainable codebase, though you’ll pay for that upfront.
Ive never gotten to write rust professionally, but I have always kinda winder d if it was marketed wrong. My thought was always that it should be sold as “easy” though. Its easy to write code. It’s hard(er) to make mistakes.
I agree, but I don’t think the problem is marketing. The problem is how some elements of Rust’s community desperately try to upsell the language beyond the value it actually can provide, and once that fails they fall back to toxic behavior and basically just mindlessly shitting on anything that’s not Rust. It goes well beyond a cargo cult mentality, and it’s sad that a fine technology is dragged through the mud by those who were expected to show its value.
TL;DR Linkedin clickbait
I did read the article and it’s maybe it’s just me being a bitter, spiteful & petulant being, obnoxious to talk with but this article sucked. Every point ranged hollow.
It was really bad because the author in his 11y of writing Rust never once heard about the philosophy of Rust/Unsafe Rust.
The goal of MSLs is to reduce UB, and Rust want to do that but keep the speed and the productivity.
Of course, at some point you may need some C/C++ because it’s the cornerstone of modern programming but what you are calling with FFI are audited, open-source libraries so memory leaks/undefined behaviour is minimised.
- Rust is implemented in Rust so FFI is greatly minimised if we follow the logic of the blogger.
the author in his 11y of writing Rust never once heard about the philosophy of Rust/Unsafe Rust.
Are you…aware of who the author is? He literally co-wrote The Book, aka The Rust Programming Language.
deleted by creator
It was really bad because the author in his 11y of writing Rust never once heard about the philosophy of Rust/Unsafe Rust.
You’re talking about Steve Klabnik, a guy known for being one of the authors of The Rust Programming Language and the guy who literally ran the @rustlang Twitter account.
Doesn’t change the overall quality of the article ?
Doesn’t change the overall quality of the article ?
I’m sorry, but I’m afraid the article is quite good.
Why? I’m eager to learn.
Why?
If there just were some link, to some blog post or something, that would expand on the topic… with a tl;dr for the really lazy people… well, that would have been nice…
We’re on a platform, where most posts are links to some blog post or something. So yes, it’d be nice to provide some info other than a generic title and stupid sarcastic comments. You could be useful, but you decided that’d be too much for effort, eh?
TL;DR:
I think that a focus on memory safe languages (MSLs) versus non memory-safe languages is a bit of a red herring. The actual distinction is slightly bigger than that: languages which have defined behavior by default, with a superset where undefined behavior is possible, vs languages which allow for undefined behavior anywhere in your program. Memory safety is an important aspect of this, but it is neccesary, not sufficient. Rust’s marketing has historically focused on memory safety, and I don’t think that was a bad choice, but I do wonder sometimes. Finally, I wonder about the future of the C++ successor langauges in the face of coming legislation around MSLs for government procurement.
You are the least friendly person I have come across from beehaw. You haven’t engaged in good faith, probably haven’t even opened the link, and you have immediately launched into personal attacks.
I asked for details, but got an idiotic sarcastic reply instead. I haven’t signed to be friendly with every moron I meet. If you’re acting hostile, don’t complain that you’re getting the same treatment back.
