6 ms·

after spending the requisite time trudging through the lifetime swamp (I couldn't couldn't imagine running my whole life on the stack), and seeing all the nice

after spending the requisite time trudging through the lifetime swamp (I couldn't couldn't imagine running my whole life on the stack), and seeing all the nice things about rust, I couldn't help but thinking at the end 'this would be a really nice language if it were garbage collected'. of course you can't say that. this is nice

pjmlp 3y ago
That language is called OCaml.
- galangalalgol 3y ago
  OCaml doesn't have a borrow checker (yet). I'm sold on having a borrow checker, not just for memory, but for io of any sort. I'm not sure what adding GC to a borrow-checked language allows for other than catching self referencing but unreachable loops? I definitely think a language that has room for abstractions that aren't zero cost, while still having a borrow-checker makes sense. Using rust to make that language also makes sense. I think implementing a vm or interpreter entirely in safe rust would effectively force borrow checking on the resultant language wouldn't it? Ruby seems like a good place to start the experiment. I'd prefer it end up with something more like julia or python just for my own use cases.
  - pjmlp 3y ago
    OP was asking for a language like Rust, using a GC instead, duh! As for having both, I rather take Swift memory ownership or Linear Haskell approach, or even D/C#/Nim/Go. The productivity of automatic memory management, with the tooling to go low level C and C++ style, if and when it is really needed.
    - galangalalgol 3y ago
      I would have considered the borrow checker and zero cost abstractions to be rusts defining characteristics, so ocaml isn't anything like rust except some syntax and that they are both multi-paradigm. And then my point is that as the author points out, you don't really need a GC if you have a borrow checker. If you want a language with few costly abstractions, but with a GC, go or D come to mind I guess? But the borrow checker is such a big piece of rust I don't really consider those similar languages either. If the idea is for a safe but more ergonomic language at the cost of performance, I think you'd be focused on making clone and copy implicit when a move doesn't work, getting rid of explocit borrows/references, and perhaps figuring out mutability without needing to annotate it. The absolute type safety is probably the biggest speedbump I hit in daily usage though, not the borrow-checker. A strong but duck/dynamic type system might solve that?
      - pjmlp 3y ago
        Most people when they say like Rust, they mean ML syntax, as Rust is the very first experience with Hindley–Milner type systems. Borrow checker alone makes several algorithms and data structures quite hard to implement. Swift memory ownership model, Linear Haskell, Hylo (née Val), Chapel, Ada formal proofs, D's ownership model, are all examples where language designers decided borrow checker alone is too much to ask for.
        galangalalgol 3y ago
        Swift's proposal with copy on write is the sort of thing I was suggesting to make the borrow checker more ergonomic. It is going to be optional though, which I think takes some of the utility away. I want much stronger safety guarantees in the overall infrastructure than that would provide. Linear types in haskell would provide that, but speaking of some data structures being difficult, Haskell makes largely the same ones problematic. Ada has a borrow checker of sorts, but it makes unchecked_deallocate UB. As long as you don't free memory it doesn't have UB. That isn't a bad trade really, but it still isn't completely impossible to do bad things with access types and they aren't that ergonomic either. I don't know much about the others you mentioned. There is definitely a space for a friendlier enforcement of ownership that makes strong guarantees. But again, the borrow checker isn't my main pain point in rust, its the static strong typing with no duck typing for generics. It makes for nice error messages, but it makes other stuff hard.
        pjmlp 3y ago
        No need to call unchecked_deallocate directly, unless one isn't using controlled types, and even better SPARK features. No UB to worry about.
masklinn 3y ago
> of course you can't say that. Oh you can absolutely say that. It's just a dumb take. Because there are already languages which have a solid type system, a functional bent, and a GC. And you can probably bang out one yourself if you want. If that was what Rust was, it probably wouldn't have existed in the first place, Mozilla would not have been interested in it in the second place, and no community would have gelled around it in the third place. Hell, it was specifically dragged further downstack by the people who coalesced around its potential in that space.
- shpongled 3y ago
  It's not a dumb take at all. I have been using Rust for > 6 years now. A significant portion of my projects don't benefit strongly from the borrow checker (the other ones massively do). I use Rust primarily because it has a solid type system, functional bent, and - most importantly - phenomenal tooling (cargo, rust-analyzer), package ecosystem, and developer UX. If OCaml/StandardML/Haskell/etc had anything close to the ergonomics and convenience of cargo for testing, setting up projects, adding deps, deploying them to any OS/platform, I would probably write about 30-40% less Rust. I'm not saying we should add GC to Rust - but I think there is space for a Rust+GC language (or just improved ecosystem and tooling for other functional langs)
  - pjmlp 3y ago
    Like opam and stackage?
    - shpongled 3y ago
      I'm familiar with both - but not really the same order of magnitude. crates.io lists >120k packages. opam has ~4500, and stackage ~3000. And the package ecosystem is only part of it. Admittedly, I haven't written any OCaml or Haskell in the last year or so, but my experience of just getting a new library or executable up and running isn't comparable to cargo either. But also hard to separate my strong familiarity with Rust from the comparison.
echelon 3y ago
This post is a horrible intro to Rust. It's a fantastic work, but totally outside of what a normal everyday Rust program looks like. > requisite time trudging through the lifetime swamp Rust really isn't like that. It gets a bad rap. > I couldn't couldn't imagine running my whole life on the stack Most of the things you touch in Rust are heap allocated. > this would be a really nice language if it were garbage collected It is a nice language, and all of your complaints go away once you start using the language idiomatically.
speed_spread 3y ago
It's not taboo to say so, even within the Rust community. It's something that will happen eventually. You might be interested in reading https://without.boats/blog/revisiting-a-smaller-rust/ https://without.boats/blog/revisiting-a-smaller-rust/

pjmlp 3y ago

That language is called OCaml.

galangalalgol 3y ago
OCaml doesn't have a borrow checker (yet). I'm sold on having a borrow checker, not just for memory, but for io of any sort. I'm not sure what adding GC to a borrow-checked language allows for other than catching self referencing but unreachable loops? I definitely think a language that has room for abstractions that aren't zero cost, while still having a borrow-checker makes sense. Using rust to make that language also makes sense. I think implementing a vm or interpreter entirely in safe rust would effectively force borrow checking on the resultant language wouldn't it? Ruby seems like a good place to start the experiment. I'd prefer it end up with something more like julia or python just for my own use cases.
- pjmlp 3y ago
  OP was asking for a language like Rust, using a GC instead, duh! As for having both, I rather take Swift memory ownership or Linear Haskell approach, or even D/C#/Nim/Go. The productivity of automatic memory management, with the tooling to go low level C and C++ style, if and when it is really needed.
  - galangalalgol 3y ago
    I would have considered the borrow checker and zero cost abstractions to be rusts defining characteristics, so ocaml isn't anything like rust except some syntax and that they are both multi-paradigm. And then my point is that as the author points out, you don't really need a GC if you have a borrow checker. If you want a language with few costly abstractions, but with a GC, go or D come to mind I guess? But the borrow checker is such a big piece of rust I don't really consider those similar languages either. If the idea is for a safe but more ergonomic language at the cost of performance, I think you'd be focused on making clone and copy implicit when a move doesn't work, getting rid of explocit borrows/references, and perhaps figuring out mutability without needing to annotate it. The absolute type safety is probably the biggest speedbump I hit in daily usage though, not the borrow-checker. A strong but duck/dynamic type system might solve that?
    - pjmlp 3y ago
      Most people when they say like Rust, they mean ML syntax, as Rust is the very first experience with Hindley–Milner type systems. Borrow checker alone makes several algorithms and data structures quite hard to implement. Swift memory ownership model, Linear Haskell, Hylo (née Val), Chapel, Ada formal proofs, D's ownership model, are all examples where language designers decided borrow checker alone is too much to ask for.
      - galangalalgol 3y ago
        Swift's proposal with copy on write is the sort of thing I was suggesting to make the borrow checker more ergonomic. It is going to be optional though, which I think takes some of the utility away. I want much stronger safety guarantees in the overall infrastructure than that would provide. Linear types in haskell would provide that, but speaking of some data structures being difficult, Haskell makes largely the same ones problematic. Ada has a borrow checker of sorts, but it makes unchecked_deallocate UB. As long as you don't free memory it doesn't have UB. That isn't a bad trade really, but it still isn't completely impossible to do bad things with access types and they aren't that ergonomic either. I don't know much about the others you mentioned. There is definitely a space for a friendlier enforcement of ownership that makes strong guarantees. But again, the borrow checker isn't my main pain point in rust, its the static strong typing with no duck typing for generics. It makes for nice error messages, but it makes other stuff hard.
        pjmlp 3y ago
        No need to call unchecked_deallocate directly, unless one isn't using controlled types, and even better SPARK features. No UB to worry about.

masklinn 3y ago

> of course you can't say that. Oh you can absolutely say that. It's just a dumb take. Because there are already languages which have a solid type system, a functional bent, and a GC. And you can probably bang out one yourself if you want. If that was what Rust was, it probably wouldn't have existed in the first place, Mozilla would not have been interested in it in the second place, and no community would have gelled around it in the third place. Hell, it was specifically dragged further downstack by the people who coalesced around its potential in that space.

shpongled 3y ago
It's not a dumb take at all. I have been using Rust for > 6 years now. A significant portion of my projects don't benefit strongly from the borrow checker (the other ones massively do). I use Rust primarily because it has a solid type system, functional bent, and - most importantly - phenomenal tooling (cargo, rust-analyzer), package ecosystem, and developer UX. If OCaml/StandardML/Haskell/etc had anything close to the ergonomics and convenience of cargo for testing, setting up projects, adding deps, deploying them to any OS/platform, I would probably write about 30-40% less Rust. I'm not saying we should add GC to Rust - but I think there is space for a Rust+GC language (or just improved ecosystem and tooling for other functional langs)
- pjmlp 3y ago
  Like opam and stackage?
  - shpongled 3y ago
    I'm familiar with both - but not really the same order of magnitude. crates.io lists >120k packages. opam has ~4500, and stackage ~3000. And the package ecosystem is only part of it. Admittedly, I haven't written any OCaml or Haskell in the last year or so, but my experience of just getting a new library or executable up and running isn't comparable to cargo either. But also hard to separate my strong familiarity with Rust from the comparison.

echelon 3y ago

This post is a horrible intro to Rust. It's a fantastic work, but totally outside of what a normal everyday Rust program looks like. > requisite time trudging through the lifetime swamp Rust really isn't like that. It gets a bad rap. > I couldn't couldn't imagine running my whole life on the stack Most of the things you touch in Rust are heap allocated. > this would be a really nice language if it were garbage collected It is a nice language, and all of your complaints go away once you start using the language idiomatically.

speed_spread 3y ago

It's not taboo to say so, even within the Rust community. It's something that will happen eventually. You might be interested in reading https://without.boats/blog/revisiting-a-smaller-rust/ https://without.boats/blog/revisiting-a-smaller-rust/