by 0xbadcafebee
6 subcomments
- Lisp, Algol 68, Pascal, Smalltalk, ML, all had both memory safety and type safety. Nobody uses it today. Why? Because software isn't developed by rational beings choosing the best tool for the job. It's developed by humans who are influenced by their cultural norms and environment. You can give someone a perfect programming language that produces bug-free programs, and they'll reject it because it uses curly-braces or some shit. Write all the papers you want; as long as the inmates are running the asylum, there is no safety.
- If Rust is the language that finally overwhelms the resistance to memory safe languages, that's good.
I think it's also important not to centre Rust alone. In the larger picture, Rust has a combo of A) good timing, and B) the best evangelism. It stands on decades of memory safe language & runtime development, as well as the efforts of their many advocates.
- "Omniglot" is a rather dramatic title for something that's basically a way to call C from Rust with additional checking on the C side for type compatibility.
That said, it might be useful. The demo case is contrived, though.
Passing Rust async semantics into C code is inherently iffy.
I'd like to see something like OpenJPEG (a JPEG 2000 encoder written in C) safely encapsulated in this way.
by taping-memory
1 subcomments
- I'm reading the article and so far it's great.
I'm just wondering in the explanation of listing 2 you say:
> a discriminant value indicating the enum’s active variant (4 bytes)
As far as I can find, there's no guarantee for that, the only thing I can find is that it might be interpreted as an `isize` value but the compiler is permitted to use smaller values: https://doc.rust-lang.org/reference/items/enumerations.html#...
Is there any reason to say it should be 4 bytes?
It doesn't change any of the conclusions, I'm just curious
by djha-skin
1 subcomments
- Nope: ease of use is table stakes. Rust is not easy to use. It will never become mainstream because of this. For all its faults, C is comparatively simple.
- [dead]
- [flagged]
- I used to work on an old C project where everyone knew there were memory issues, but no one wanted to touch it. Rewriting was too expensive, so we just used tools to keep it running.
Now most new projects go with Rust. Memory safety feels like the default, but it's going to take time for the old stuff to catch up.
by marsven_422
0 subcomment
- [dead]
by userbinator
0 subcomment
- [flagged]
- Rust is starting to feel like those people calling about your car’s extended warranty.
- Oddly I see a lot of marketing for Rust. Not gonna make it a success, sorry. No one cares about Rust lol. It's specialized. It has a value and a place, but it isn't a mainstream thing unfortunately.
by timewizard
6 subcomments
- > if it compiles, then it’s correct … or at least, will not contain use-after-free or other memory safety errors
In a language with the `unsafe` construct and effectively no automated tooling to audit the uses of it. You have no guarantee of any significance. You've just slightly changed where the security boundary _might_ lie.
> There is a great amount of software already written in other languages.
Yea. And development of those languages is on going. C++ has improved the memory safety picture quite a bit of the past decade and shows no signs of slowing down. There is no "one size fits all" solution here.
Finally, if memory safety were truly "table stakes" then we would have been using the dozens of memory safe languages that already existed. It should be blindingly obvious that /performance/ is table stakes.
Hacker News