8 ms·

I'd like a GC (no borrow checker) version of Rust. There's so many cool concepts in the language that I'd like to know how useful it is in different contexts. (

I'd like a GC (no borrow checker) version of Rust. There's so many cool concepts in the language that I'd like to know how useful it is in different contexts. (Compiled without a VM, option types, no nulls, easy error handling without exceptions...)

Zababa 5y ago
You could try OCaml (it does have exception but they're usually "opt in"), it's a really nice language and probably one of the closest to GC'd Rust. There's also Swift that inspired some features.
- awestroke 5y ago
  OCaml is often dropped due to its unpredictable performance
  - Zababa 5y ago
    I've heard the opposite about it, that its predictable performance is one of its strength. Do you have any sources?
    - awestroke 5y ago
      Darklang is being rewritten in .Net Flowtype has horrible performance, which in my opinion partially explains why it has lost so many users to Typescript, which has much more predicable and fast performance even though it's written in JS. The project is basically dead
      - octachron 5y ago
        None of this seems related to OCaml performance? Darklang is being rewritten to .Net because they were unsatisfied with the OCaml ecosystem. Horrible performance is generally more a question of algorithms and software architecture than a problem with a language, which only account for a flat percentage of performance.
      - Zababa 5y ago
        Here is the article about Darklang leaving OCaml, nothing here is about performance https://blog.darklang.com/leaving-ocaml/ https://blog.darklang.com/leaving-ocaml/. It's about ecosystem and dev experience. About Flow, I've never used it so I can't say, but Rescript (which is written in OCaml) compiles 10 to 100 times faster than Typescript.
      - tomp 5y ago
        I've never used neither Flow nor TypeScript, but there's an essential difference between the two - Flow is type inference engine, whereas TypeScript is a type checking engine. The latter is a fundamentally a much simpler problem (both semantically, and algorithmically) than the former. In addition, Flow picks a particularly nasty niche for type inference - OCaml itself uses type inference, it's fast (with quadratic blowup in edge cases) because OCaml's types are simple, whereas Flow IIRC tries to support both subtyping and some of JS's dynamicity, so I'm not surprised if it's slower.
  - spockz 5y ago
    Interesting. I’ve actually seen OCaml being chosen because of its predictable performance. But that was by people coming from Haskell.
    - awestroke 5y ago
      Well, almost everything has more predicable performance than Haskell. And I love Haskell.
  - choeger 5y ago
    Huh? OCaml is pretty obvious in its semantics and compilation strategy. Maybe flambda changed something, but before that I'd used the compiler source code as a reference on how one would compile an ML.
  - maattdd 5y ago
    I don't think I've ever heard that. Ocaml performance is surprisingly very predictable.
grandmczeb 5y ago
I think a scripting version of rust with a GC and gradual typing would be really nice. Especially one that allows incrementally converting a script into a compiled rust program.
densh 5y ago
You might want to check out Scala Native. It’s conceptually similar to Rust without borrow checking. The only issue is that it’s way less mature and community is much smaller.
skohan 5y ago
You just essentially described Swift
- gwbas1c 5y ago
  Swift is more like C# or Java than Rust. It's more like adapting C# to the objective C runtime than Rust. It's also not memory safe. It's very easy to crash the process.
  - uniqueid 5y ago
    Whether or not Swift succeeds at being memory-safe, in theory, it's supposed to be.
    - skohan 5y ago
      It's memory-safe in a single-threaded context. The actor model would theoretically bring multi-threaded memory safety (with a different set of tradeoffs than Rust).
      - uniqueid 5y ago
        Thanks for clarifying.
  - user-the-name 5y ago
    Absolutely not. Both Swift and Rust are actively taking inspiration from each other.
  - skohan 5y ago
    I just totally disagree. Swift might look a bit more like C#, but in terms of features it's way more similar to Rust for all the ADT-related features mentioned in the grandparent comment. Also, regarding memory safety, it's not as safe as Rust - it's basically only memory-safe in the single-threaded context, but it's still relatively safe compared to other languages. I don't really find it easier to crash than Rust - thanks to optionals you get the same guarantees against NPE's. You can choose not to take advantage of it, but you can also force-unwrap in Rust if you want.
mhh__ 5y ago
We use D a lot at work, we genuinely can only laugh at people who refuse to entertain the idea of a GC. The GC allows our code to exist without extensive memory book-keeping. When we want to avoid the GC we know how, when we want the productivity we use the GC and fuggedaboutit
- 0dyl 5y ago
  > we genuinely can only laugh at people That's perhaps not the best wording. Nonetheless, I do agree with you. D can be very flexible in that regard.
  - mhh__ 5y ago
    I don't know how else to word it. Every thread about D has people going on and on and on and on about the GC, and they aren't always wrong (there is always good information here) but fundamentally it doesn't matter. Many D programmers come from PHP rather than C++ - D isn't attractive to them because of systems programming but rather high level programming e.g. metaprogramming.
    - deleted 5y ago
      [deleted]
    - jhgb 5y ago
      There seems to be at least one reason to have a non-GC option: You want to write code that integrates with an environment that already has its own GC and you want that to decide things. For example you want to integrate existing libraries in C/C++/D/Go/Rust/whatever with a Lisp process, since there's lots of those libraries and they do useful things, and you don't have a Lisp library for that (yet). In that case having one point of deciding when to deallocate things seems to be better than having two of them.
- gwbas1c 5y ago
  Using GC basically locks you into a particular memory model or framework. Having spent 20 years mostly working in GC languages, it's totally worth it! However, writing portable libraries like SQLite or libpng are very difficult to do without bringing in unacceptable overhead for your consumers.

Zababa 5y ago

You could try OCaml (it does have exception but they're usually "opt in"), it's a really nice language and probably one of the closest to GC'd Rust. There's also Swift that inspired some features.

awestroke 5y ago
OCaml is often dropped due to its unpredictable performance
- Zababa 5y ago
  I've heard the opposite about it, that its predictable performance is one of its strength. Do you have any sources?
  - awestroke 5y ago
    Darklang is being rewritten in .Net Flowtype has horrible performance, which in my opinion partially explains why it has lost so many users to Typescript, which has much more predicable and fast performance even though it's written in JS. The project is basically dead
    - octachron 5y ago
      None of this seems related to OCaml performance? Darklang is being rewritten to .Net because they were unsatisfied with the OCaml ecosystem. Horrible performance is generally more a question of algorithms and software architecture than a problem with a language, which only account for a flat percentage of performance.
    - Zababa 5y ago
      Here is the article about Darklang leaving OCaml, nothing here is about performance https://blog.darklang.com/leaving-ocaml/ https://blog.darklang.com/leaving-ocaml/. It's about ecosystem and dev experience. About Flow, I've never used it so I can't say, but Rescript (which is written in OCaml) compiles 10 to 100 times faster than Typescript.
    - tomp 5y ago
      I've never used neither Flow nor TypeScript, but there's an essential difference between the two - Flow is type inference engine, whereas TypeScript is a type checking engine. The latter is a fundamentally a much simpler problem (both semantically, and algorithmically) than the former. In addition, Flow picks a particularly nasty niche for type inference - OCaml itself uses type inference, it's fast (with quadratic blowup in edge cases) because OCaml's types are simple, whereas Flow IIRC tries to support both subtyping and some of JS's dynamicity, so I'm not surprised if it's slower.
- spockz 5y ago
  Interesting. I’ve actually seen OCaml being chosen because of its predictable performance. But that was by people coming from Haskell.
  - awestroke 5y ago
    Well, almost everything has more predicable performance than Haskell. And I love Haskell.
- choeger 5y ago
  Huh? OCaml is pretty obvious in its semantics and compilation strategy. Maybe flambda changed something, but before that I'd used the compiler source code as a reference on how one would compile an ML.
- maattdd 5y ago
  I don't think I've ever heard that. Ocaml performance is surprisingly very predictable.

grandmczeb 5y ago

I think a scripting version of rust with a GC and gradual typing would be really nice. Especially one that allows incrementally converting a script into a compiled rust program.

densh 5y ago

You might want to check out Scala Native. It’s conceptually similar to Rust without borrow checking. The only issue is that it’s way less mature and community is much smaller.

skohan 5y ago

You just essentially described Swift

gwbas1c 5y ago
Swift is more like C# or Java than Rust. It's more like adapting C# to the objective C runtime than Rust. It's also not memory safe. It's very easy to crash the process.
- uniqueid 5y ago
  Whether or not Swift succeeds at being memory-safe, in theory, it's supposed to be.
  - skohan 5y ago
    It's memory-safe in a single-threaded context. The actor model would theoretically bring multi-threaded memory safety (with a different set of tradeoffs than Rust).
    - uniqueid 5y ago
      Thanks for clarifying.
- user-the-name 5y ago
  Absolutely not. Both Swift and Rust are actively taking inspiration from each other.
- skohan 5y ago
  I just totally disagree. Swift might look a bit more like C#, but in terms of features it's way more similar to Rust for all the ADT-related features mentioned in the grandparent comment. Also, regarding memory safety, it's not as safe as Rust - it's basically only memory-safe in the single-threaded context, but it's still relatively safe compared to other languages. I don't really find it easier to crash than Rust - thanks to optionals you get the same guarantees against NPE's. You can choose not to take advantage of it, but you can also force-unwrap in Rust if you want.

mhh__ 5y ago

We use D a lot at work, we genuinely can only laugh at people who refuse to entertain the idea of a GC. The GC allows our code to exist without extensive memory book-keeping. When we want to avoid the GC we know how, when we want the productivity we use the GC and fuggedaboutit

0dyl 5y ago
> we genuinely can only laugh at people That's perhaps not the best wording. Nonetheless, I do agree with you. D can be very flexible in that regard.
- mhh__ 5y ago
  I don't know how else to word it. Every thread about D has people going on and on and on and on about the GC, and they aren't always wrong (there is always good information here) but fundamentally it doesn't matter. Many D programmers come from PHP rather than C++ - D isn't attractive to them because of systems programming but rather high level programming e.g. metaprogramming.
  - deleted 5y ago
    [deleted]
  - jhgb 5y ago
    There seems to be at least one reason to have a non-GC option: You want to write code that integrates with an environment that already has its own GC and you want that to decide things. For example you want to integrate existing libraries in C/C++/D/Go/Rust/whatever with a Lisp process, since there's lots of those libraries and they do useful things, and you don't have a Lisp library for that (yet). In that case having one point of deciding when to deallocate things seems to be better than having two of them.
gwbas1c 5y ago
Using GC basically locks you into a particular memory model or framework. Having spent 20 years mostly working in GC languages, it's totally worth it! However, writing portable libraries like SQLite or libpng are very difficult to do without bringing in unacceptable overhead for your consumers.