Re:Memory Safety in a Modern System Programming Language Pt. 1
by rayiner on Wednesday June 22, 2022 @06:57PM
(#31842972)
Glad to see experimentation in this space, because I'm not quite sure Rust hits the optimal point in the design space. I think some of Rust's complexity is due to lacking what Cyclone calls regions and having to always deal with lifetimes, which can get complex: https://www.cs.umd.edu/~mwh/papers/cyclone-cuj.pdf.
Re:Memory Safety in a Modern System Programming Language Pt. 1
by 3a2d29 on Wednesday June 22, 2022 @02:37PM
(#31840001)
As much as I don’t want to complain about all the new low level languages (it’s really cool to see so much innovation!)
But I can’t help but feel a bit overwhelmed with options, and I know very few will ever catch on.
At least D seems to have some momentum, but I have fallen into the trap before of learning new languages that die.
I want to learn one of these, but I want it to last!
Re:Memory Safety in a Modern System Programming Language Pt. 1
by dukc on Wednesday June 22, 2022 @03:02PM
(#31840382)
D is pretty safe choice in that regard. It has been around 20 years already and still marches on. Also it has many companies using it that depend on it. So while there is no guarantee it will ever be among top-10 languages, it's unlikely to die off anytime soon either.
Re:Memory Safety in a Modern System Programming Language Pt. 1
by verdagon on Wednesday June 22, 2022 @03:03PM
(#31840390)
For sure. Most of those are pretty young and experimental, so I'm glad D is adding something solid!
Re:Memory Safety in a Modern System Programming Language Pt. 1
by acehreli on Thursday June 23, 2022 @04:43PM
(#31854901)
D is not popular but has a strong long-time following.
Re:Memory Safety in a Modern System Programming Language Pt. 1
by skyde on Wednesday June 22, 2022 @04:52PM
(#31841715)
what about Rust ?
Is rust not trying to be memory safe ?
Re:Memory Safety in a Modern System Programming Language Pt. 1
by verdagon on Wednesday June 22, 2022 @07:11PM
(#31843091)
Rust has a great approach to memory safety for plenty of use cases, but I personally believe that the future lies with languages that have a more seamless blend between shared mutability and static analysis. Going all-in on borrow-checked single ownership causes a bit too much complexity, in my opinion.
I would be very interested in any advances in the Rust realms that could address the added complexity! I haven't heard much coming from that direction. Polonius sounded like it would remove some edge cases from borrow checking, but it didn't seem like it would really help with the fundamental complexities from borrow checking.
A lot of languages are going this direction too:
* Cone is putting a full borrow checker on top of GC, RC, and single ownership: https://cone.jondgoodwin.com/
* Vale is putting opt-in "region borrow checking" on top of single ownership with generational references: https://verdagon.dev/blog/zero-cost-refs-regions
* Lobster is employing an automatic-borrow-checker-esque algorithm on top of RC for some brilliant speedups: https://www.strlen.com/lobster/
* Ante has some designs for lifetime inference, which I think will work really well: https://antelang.org/
* HVM is a runtime for Haskell that uses borrow checker semantics and falls back to clone. It's not shared mutability, but Haskell without GC is pretty cool! https://github.com/Kindelia/HVM
I particularly like D's approach because it's opt-in; we can use it in the areas of the program where we need performance the most, and prioritize flexibility and development velocity everywhere else, which I think is the right balance for most programs developed today.
It also means one can gradually ease into learning how to use static analysis and their more complex constructs (like return scope, mentioned in the article). One can be proficient in the basic language quickly, and then improve their craft gradually. In modern software engineering, this is a big win, in my opinion. Props to D for going this direction!