4 ms·
> Aren’t abstractions supposed to make things easier to learn? Not always. Some abstractions are designed to make it easier to solve hard problems correctly (t
by jcrites 9y ago
> Aren’t abstractions supposed to make things easier to learn?
Not always. Some abstractions are designed to make it easier to solve hard problems correctly (than without the abstraction).
For example, consider Rust's memory model. Many people criticize that model as difficult to learn. By comparison, you might argue that C's memory model is simpler to learn. Yet, the C approach to allocating, using, and freeing memory is highly error-prone. C programs historically have frequently had mistakes such as use-after-free errors, or buffer under/overflow/reuse errors. The high-profile OpenSSL Heartbleed vulnerability was an example of a weakness in C's memory model and memory handling abstractions [1].
Rust's memory model may be more difficult to learn than C's, but once learned, they are abstractions that provide an advantage in building correct software, by ruling out certain classes of mistakes. (GC in languages like C# and Java and Go can also prevent these mistakes, but comes with a runtime cost. Rust aims to provide zero-cost abstractions.)
Building correct async IO programs using kernel abstractions is difficult for similar reasons as it's difficult to write correct programs with C's memory model. It's especially difficult if you want the async IO program to be portable across multiple OS/kernels. I have not used Tokio, but I would guess that its Rust-powered abstractions will make it difficult or impossible to leak memory or sockets, or to fail to handle error cases that might arise handling async IO.
[1] https://www.seancassidy.me/diagnosis-of-the-openssl-heartbleed-bug.html https://www.seancassidy.me/diagnosis-of-the-openssl-heartble...
- kindfellow92 9y agoI think you’re comparing apples and oranges here. Writing memory safe code without Rust is harder than using Rust’s abstractions to do the same task. If you agree with that then my comment stands.
- lurr 9y agoYeah, but I actually have a reasonable chance of accomplishing what I want in C++. vs Rust where I bash my head against it for 2 days then give up. I'm not smart enough for Rust, oh well.
- simplify 9y agoI wouldn't say you're "not smart enough", I would say the subject is not yet well-taught.
- hobofan 9y agoI am not trying to personally attack you here, but most times when people say something like this, what they are actually saying is: "I think I am accomplishing the same thing in C++, but by not facing (and solving) the problems, I am actually creating a program with nasty hidden bugs, that might or might not blow up in my face later".
- CJefferson 9y agoOn the other hand, a buggy C++ program is still better than no rust program.
- vvanders 9y agoHaving had to track down memory data races in a production C++ codebase I'm not sure that I completely agree with your assessment.
- baq 9y agoI've once spent quite a few hours debugging a dangling pointer that wasn't zeroed after delete and was written to which might or might not have corrupted a piece of lua interpreter's state. fixing that felt good. the preceding 24 hours, not so much.
- vvanders 9y agoYup. Data races are particularly nasty because any print statements or debug tracing can trigger a memory fence/reorder and make the problem disappear. Nothing more frustrating then adding a printf only to see the issue no longer manifest.
- 9y ago