5 ms·

Yes, Rust as a language wasn't originally intended for much of what it's used for now. Many of the applications written in Rust would probably be fine without

by Athas 4y ago

Yes, Rust as a language wasn't originally intended for much of what it's used for now. Many of the applications written in Rust would probably be fine without the borrow checker, and instead paying a performance overhead to have GC. I think Rust is succeeding on the strength of its tooling and the overall relative modernity of the language (e.g. proper sum types and sane metaprogramming). Of course, Haskell has these things too, although some of the incarnations may be a bit more crufty (Rust macros seem a lot more accepted than Template Haskell does).

runevault 4y ago
One thing that can really mess with people as well is how much of Haskell is (or was last I played with it) lazy by default. Some things like infinite lists where you only take a subset obviously have to be lazy, but in other cases the way it messed with memory usage could be incredibly confusing. I wonder if a less lazy by default version of Haskell might have had any more success in the wider world. I know in the .NET world I've been burned more than a few times by the way Linq is lazy unless expressly realized (via methods like ToArray() and ToList())
- Athas 4y ago
  Yes, the next Haskell will be strict; that's generally although not universally accepted. I have however noticed that while much Haskell code doesn't make very fancy use of laziness, it is widely used for very local control flow. E.g. a pattern I see relatively often is `fromMaybe (error "...some message")`, which would be problematic in a strict language (because `error` would always be evaluated). Even without partial functions, laziness can also simplify code structure when you can just 'let' bind any value that will possibly be used on any control flow path, without worrying about unnecessary computation. These conveniences are not deal-breakers - I get by without them just fine in SML - but they do serve to make the language a bit nicer.
  - runevault 4y ago
    Perhaps there could exist a middle ground for cases where it does not risk significant "random" memory bloat and similar issues. I 100% think there are edge cases where laziness has value. Although in your fromMaybe case couldn't you just have it generate short circuiting code under the hood instead of always evaluating? That isn't necessarily quite the same thing as laziness.
    - mibsl 4y ago
      Short circuiting is a special case of laziness. It's local only, so no thunks are required. The beauty of functions like fromMaybe is they're only that - just plain, regular functions. No special casing under the hood required.
  - massysett 4y ago
    > Yes, the next Haskell will be strict; that's generally although not universally accepted. The essence of Haskell is non-strictness. It is the very reason Haskell was created. There are already strict functional languages, like OCaml. What value comes from stripping Haskell of the soul of its existence?
steveklabnik 4y ago
Rust was absolutely intended for systems programming from the start, it’s just that the “you can drop the GC but still have memory safety” bit wasn’t there at the beginning. Safe systems programming was the goal from the beginning. http://venge.net/graydon/talks/intro-talk-2.pdf http://venge.net/graydon/talks/intro-talk-2.pdf
- Athas 4y ago
  I am aware. My post was about Rust not originally being intended for much of the non-concurrent and performance-agnostic application programming it is currently being used for (e.g. the enormous amount of CLI utilities cropping up). Its popularity in this domain is due to qualities that were not part of (or at least orthogonal to) the original vision.
  - steveklabnik 4y ago
    Ah, I see, my bad. I misunderstood. (I think part of it is also like, what even is "systems" is confusing; I think many folks would think of those CLI apps as being bread and butter systems stuff, but you can slice it both ways really.) Hopefully someone finds the presentation interesting if they haven't seen it before :)

by Athas 4y ago

runevault 4y ago

One thing that can really mess with people as well is how much of Haskell is (or was last I played with it) lazy by default. Some things like infinite lists where you only take a subset obviously have to be lazy, but in other cases the way it messed with memory usage could be incredibly confusing. I wonder if a less lazy by default version of Haskell might have had any more success in the wider world. I know in the .NET world I've been burned more than a few times by the way Linq is lazy unless expressly realized (via methods like ToArray() and ToList())

Athas 4y ago
Yes, the next Haskell will be strict; that's generally although not universally accepted. I have however noticed that while much Haskell code doesn't make very fancy use of laziness, it is widely used for very local control flow. E.g. a pattern I see relatively often is `fromMaybe (error "...some message")`, which would be problematic in a strict language (because `error` would always be evaluated). Even without partial functions, laziness can also simplify code structure when you can just 'let' bind any value that will possibly be used on any control flow path, without worrying about unnecessary computation. These conveniences are not deal-breakers - I get by without them just fine in SML - but they do serve to make the language a bit nicer.
- runevault 4y ago
  Perhaps there could exist a middle ground for cases where it does not risk significant "random" memory bloat and similar issues. I 100% think there are edge cases where laziness has value. Although in your fromMaybe case couldn't you just have it generate short circuiting code under the hood instead of always evaluating? That isn't necessarily quite the same thing as laziness.
  - mibsl 4y ago
    Short circuiting is a special case of laziness. It's local only, so no thunks are required. The beauty of functions like fromMaybe is they're only that - just plain, regular functions. No special casing under the hood required.
- massysett 4y ago
  > Yes, the next Haskell will be strict; that's generally although not universally accepted. The essence of Haskell is non-strictness. It is the very reason Haskell was created. There are already strict functional languages, like OCaml. What value comes from stripping Haskell of the soul of its existence?

steveklabnik 4y ago

Rust was absolutely intended for systems programming from the start, it’s just that the “you can drop the GC but still have memory safety” bit wasn’t there at the beginning. Safe systems programming was the goal from the beginning. http://venge.net/graydon/talks/intro-talk-2.pdf http://venge.net/graydon/talks/intro-talk-2.pdf

Athas 4y ago
I am aware. My post was about Rust not originally being intended for much of the non-concurrent and performance-agnostic application programming it is currently being used for (e.g. the enormous amount of CLI utilities cropping up). Its popularity in this domain is due to qualities that were not part of (or at least orthogonal to) the original vision.
- steveklabnik 4y ago
  Ah, I see, my bad. I misunderstood. (I think part of it is also like, what even is "systems" is confusing; I think many folks would think of those CLI apps as being bread and butter systems stuff, but you can slice it both ways really.) Hopefully someone finds the presentation interesting if they haven't seen it before :)