5 ms·

Go, Pony and Haskell all have complex runtimes and a GC, which makes them unsuitable for embedding into other applications or exposing them as widely usable lib

Go, Pony and Haskell all have complex runtimes and a GC, which makes them unsuitable for embedding into other applications or exposing them as widely usable libraries. Rust, Zig, and to a certain extent D or Nim without GC, can easily expose a C API and have a minimal runtime. But the others do not provide the same guarantees as (safe) Rust with the borrow checker. All very cool languages in their own right, but memory safety in a no-GC environment is not one of their defining attributes. Note: a dependency on any of those compilers is still far from trivial for many projects.

nimmer 6y ago
Nim is not using GC anymore [1], is memory safe and support formal methods [2] It's also introducing isolation [3] to provide safe multithreading similar to Rust's sendable. [1] https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... [2] https://nim-lang.org/docs/drnim.html https://nim-lang.org/docs/drnim.html [3] https://github.com/nim-lang/RFCs/issues/244 https://github.com/nim-lang/RFCs/issues/244
- floatboth 6y ago
  From [1]: > ORC is Nim’s all-new cycle collector based on ARC. It can be considered a full-blown GC since it includes a local tracing phase (contrary to most other tracing GCs which do global tracing). ORC is what you should use when working with Nim’s async because it contains cycles that need to be dealt with. Sooooo unless you > disable the GC and do manual memory management, but then you lose access to most of the stdlib you still have to run a memory-managing runtime
  - nimmer 6y ago
    No. It's an inlined reference counter, not a runtime with dedicated thread and so on. Most people use "GC" to refer to the latter.
    - lzutao 6y ago
      like swift you say
whateveracct 6y ago
i just write all my projects in Haskell on any platform so the RTS is a given (or the RTS isn't present at execution time since the executable is generated from a Haskell eDSL) it's truly superior to any other programming language (5+ years of pro experience talking), so why waste my time with the manual labor of imperative programming?
- mrkeen 6y ago
  I write 90% of my stuff in Haskell. When I need speed, I used to use C, now I use Rust. > why waste my time with the manual labor of imperative programming Someone has to. https://github.com/ghc/ghc/tree/master/rts https://github.com/ghc/ghc/tree/master/rts
  - whateveracct 6y ago
    I'd say about the same. C has its place, and the GHC RTS is a great example.
WalterBright 6y ago
D now has a prototype borrow checker implemented.
- the_duke 6y ago
  That's very cool to hear! As the ceator of D, how do you see the place of borrow checking in the ecosystem long term? Would you imagine most D code to be written against the borrow checker in the future, with transparent convenience for GC types? Or would it remain a somewhat niche feature for domains that can benefit?
  - WalterBright 6y ago
    The borrow checker in D can be used incrementally, like functional programming, on a function-by-function basis. It can be used where it makes sense to use it. (If only the GC is being used, the borrow checker isn't needed.) Being incremental, it won't require redesigning the program to make use of it. I don't know how pervasive its use will become, but I expect its use will steadily increase.
    - mhh__ 6y ago
      One thing that I think we'll have to deal with at some point in the next two years or so is that although using the borrow checker will be incremental on (say) functions, the actual design of said borrow checker needs to be more integrated than incremental i.e. currently we can catch lifetime related bugs but you can't properly express (say) invalidating a pointer into a container by calling popFront.

nimmer 6y ago

Nim is not using GC anymore [1], is memory safe and support formal methods [2] It's also introducing isolation [3] to provide safe multithreading similar to Rust's sendable. [1] https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... [2] https://nim-lang.org/docs/drnim.html https://nim-lang.org/docs/drnim.html [3] https://github.com/nim-lang/RFCs/issues/244 https://github.com/nim-lang/RFCs/issues/244

floatboth 6y ago
From [1]: > ORC is Nim’s all-new cycle collector based on ARC. It can be considered a full-blown GC since it includes a local tracing phase (contrary to most other tracing GCs which do global tracing). ORC is what you should use when working with Nim’s async because it contains cycles that need to be dealt with. Sooooo unless you > disable the GC and do manual memory management, but then you lose access to most of the stdlib you still have to run a memory-managing runtime
- nimmer 6y ago
  No. It's an inlined reference counter, not a runtime with dedicated thread and so on. Most people use "GC" to refer to the latter.
  - lzutao 6y ago
    like swift you say

whateveracct 6y ago

i just write all my projects in Haskell on any platform so the RTS is a given (or the RTS isn't present at execution time since the executable is generated from a Haskell eDSL) it's truly superior to any other programming language (5+ years of pro experience talking), so why waste my time with the manual labor of imperative programming?

mrkeen 6y ago
I write 90% of my stuff in Haskell. When I need speed, I used to use C, now I use Rust. > why waste my time with the manual labor of imperative programming Someone has to. https://github.com/ghc/ghc/tree/master/rts https://github.com/ghc/ghc/tree/master/rts
- whateveracct 6y ago
  I'd say about the same. C has its place, and the GHC RTS is a great example.

WalterBright 6y ago

D now has a prototype borrow checker implemented.

the_duke 6y ago
That's very cool to hear! As the ceator of D, how do you see the place of borrow checking in the ecosystem long term? Would you imagine most D code to be written against the borrow checker in the future, with transparent convenience for GC types? Or would it remain a somewhat niche feature for domains that can benefit?
- WalterBright 6y ago
  The borrow checker in D can be used incrementally, like functional programming, on a function-by-function basis. It can be used where it makes sense to use it. (If only the GC is being used, the borrow checker isn't needed.) Being incremental, it won't require redesigning the program to make use of it. I don't know how pervasive its use will become, but I expect its use will steadily increase.
  - mhh__ 6y ago
    One thing that I think we'll have to deal with at some point in the next two years or so is that although using the borrow checker will be incremental on (say) functions, the actual design of said borrow checker needs to be more integrated than incremental i.e. currently we can catch lifetime related bugs but you can't properly express (say) invalidating a pointer into a container by calling popFront.