16 ms·

Can you be specific about which languages you include in the category of "fast and SAFE"?

by dikaiosune 9y ago

bandook_raja 9y ago
D? GC is optional so don't even :D
- dikaiosune 9y ago
  How much of the standard library works without GC enabled? How many community libraries do? D has a lot of great things (I am incredibly jealous of their metaprogramming facilities sometimes), but it doesn't seem like many people are successfully using it in the "fast and SAFE" sense as GP defined it.
  - bandook_raja 9y ago
    > How much of the standard library works without GC enabled? How many community libraries do? Enough to be usable on virtually all platforms that rust is going to target in next 2 years. I hope I'll get proven wrong but that's it for now. And maybe along the time we'll see some decoupling of stdlib from GC too. OTOH some people like GC too :)
    - qznc 9y ago
      > along the time we'll see some decoupling of stdlib from GC That is already happening. There is no measure, though. How should it be measured? Related, a few days another blog post in the No-GC series was published: https://dlang.org/blog/2017/07/07/go-your-own-way-part-one-the-stack/ https://dlang.org/blog/2017/07/07/go-your-own-way-part-one-t...
wbl 9y ago
Ada. Algol-60. The much maligned Pascal.
rbehrends 9y ago
Rather than answering this question directly, let me perhaps explain why Rust is getting so much pushback. With the exception of dynamic memory, virtually all high-level languages that aren't called C/C++ are memory-safe. Memory-safety is not a new feature. Inherent memory-unsafety was a "feature" introduced by C and its immediate ancestors (and later perpetuated by C++) in order to deal with the performance limitations of 8/16-bit architectures and optimizers that were far more limited than they are now. For many of the older of us – before C/C++ took over much of the world – safe languages were the norm (with the exception of dynamic memory for languages without automatic memory management). So, in our experience, Rust doesn't really offer us much except an alternative to automatic memory management that imposes a significant cognitive burden. That tradeoff is not always attractive. It presupposes that any and all forms of automatic memory management are not an option. Not a modern incremental, generational garbage collector, not Swift-style ARC (where unnecessary RC updates are optimized away), not some of the various and sundry automatic memory management techniques that researchers have come with over the years (such as MLKit's regions). If you have this kind of programming background, the tradeoffs that Rust offers are not at all attractive. Not only are the use cases where you need exactly Rust's value proposition relatively rare, the ongoing and often aggressive evangelism sucks up oxygen in the open source commons, so to speak, that could go towards alternative efforts.
- ameliaquining 9y ago
  That dynamic memory exception is big enough to drive a truck through. Dynamic memory is so pervasive in today's programs that (I would argue) a language that's "memory-safe except for dynamic memory" has no business advertising itself as memory-safe at all. Maybe it was different in the past. That said, plenty of applications can easily afford to pay the runtime cost of a tracing garbage collector and don't need to be using Rust. (You might want to anyway, if you're writing such an application—the language is designed pervasively to eliminate as many sources of program incorrectness as is practical, and this comes through in more areas than just memory safety—but it's not the same kind of critical advantage that memory safety is.) In general I tend to think of Rust as a better replacement for C++, and useful for approximately the same use cases. I'm not sure how I feel about Swift's ARC; it seems like a bit of a hack compared to Rust's lifetimes and I worry that it makes memory leaks too easy, but I haven't worked with it. I don't think I count techniques that aren't available in any language less obscure than Cyclone.
rurban 9y ago
There are so many: Pony, ATS, Sing#, Spec#, Felix, Gordon, Æminium, DPJ (Deterministic Parallel Java), Kilim, Haller and Odersky. A lot of more linear type languages, like PRFJ or OIGJ. See e.g. http://www.doc.ic.ac.uk/~scd/fast-cheap.pdf http://www.doc.ic.ac.uk/~scd/fast-cheap.pdf I'm not sure about Factor yet, but it looks good and beats Rust in performance and features also.
- vertex-four 9y ago
  So which of those don't depend on an unsafe runtime?

Can you be specific about which languages you include in the category of "fast and SAFE"?

bandook_raja 9y ago

D? GC is optional so don't even :D

dikaiosune 9y ago
How much of the standard library works without GC enabled? How many community libraries do? D has a lot of great things (I am incredibly jealous of their metaprogramming facilities sometimes), but it doesn't seem like many people are successfully using it in the "fast and SAFE" sense as GP defined it.
- bandook_raja 9y ago
  > How much of the standard library works without GC enabled? How many community libraries do? Enough to be usable on virtually all platforms that rust is going to target in next 2 years. I hope I'll get proven wrong but that's it for now. And maybe along the time we'll see some decoupling of stdlib from GC too. OTOH some people like GC too :)
  - qznc 9y ago
    > along the time we'll see some decoupling of stdlib from GC That is already happening. There is no measure, though. How should it be measured? Related, a few days another blog post in the No-GC series was published: https://dlang.org/blog/2017/07/07/go-your-own-way-part-one-the-stack/ https://dlang.org/blog/2017/07/07/go-your-own-way-part-one-t...

wbl 9y ago

Ada. Algol-60. The much maligned Pascal.

rbehrends 9y ago

Rather than answering this question directly, let me perhaps explain why Rust is getting so much pushback. With the exception of dynamic memory, virtually all high-level languages that aren't called C/C++ are memory-safe. Memory-safety is not a new feature. Inherent memory-unsafety was a "feature" introduced by C and its immediate ancestors (and later perpetuated by C++) in order to deal with the performance limitations of 8/16-bit architectures and optimizers that were far more limited than they are now. For many of the older of us – before C/C++ took over much of the world – safe languages were the norm (with the exception of dynamic memory for languages without automatic memory management). So, in our experience, Rust doesn't really offer us much except an alternative to automatic memory management that imposes a significant cognitive burden. That tradeoff is not always attractive. It presupposes that any and all forms of automatic memory management are not an option. Not a modern incremental, generational garbage collector, not Swift-style ARC (where unnecessary RC updates are optimized away), not some of the various and sundry automatic memory management techniques that researchers have come with over the years (such as MLKit's regions). If you have this kind of programming background, the tradeoffs that Rust offers are not at all attractive. Not only are the use cases where you need exactly Rust's value proposition relatively rare, the ongoing and often aggressive evangelism sucks up oxygen in the open source commons, so to speak, that could go towards alternative efforts.

ameliaquining 9y ago
That dynamic memory exception is big enough to drive a truck through. Dynamic memory is so pervasive in today's programs that (I would argue) a language that's "memory-safe except for dynamic memory" has no business advertising itself as memory-safe at all. Maybe it was different in the past. That said, plenty of applications can easily afford to pay the runtime cost of a tracing garbage collector and don't need to be using Rust. (You might want to anyway, if you're writing such an application—the language is designed pervasively to eliminate as many sources of program incorrectness as is practical, and this comes through in more areas than just memory safety—but it's not the same kind of critical advantage that memory safety is.) In general I tend to think of Rust as a better replacement for C++, and useful for approximately the same use cases. I'm not sure how I feel about Swift's ARC; it seems like a bit of a hack compared to Rust's lifetimes and I worry that it makes memory leaks too easy, but I haven't worked with it. I don't think I count techniques that aren't available in any language less obscure than Cyclone.

rurban 9y ago

There are so many: Pony, ATS, Sing#, Spec#, Felix, Gordon, Æminium, DPJ (Deterministic Parallel Java), Kilim, Haller and Odersky. A lot of more linear type languages, like PRFJ or OIGJ. See e.g. http://www.doc.ic.ac.uk/~scd/fast-cheap.pdf http://www.doc.ic.ac.uk/~scd/fast-cheap.pdf I'm not sure about Factor yet, but it looks good and beats Rust in performance and features also.

vertex-four 9y ago
So which of those don't depend on an unsafe runtime?