Nowhere does it call out Rust by name.
Go / Zig / Pony / Haskell are all valid contenders.
Go / Zig / Pony / Haskell are all valid contenders.
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.
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?
I don't know how pervasive its use will become, but I expect its use will steadily increase.
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?
> why waste my time with the manual labor of imperative programming
Someone has to. https://github.com/ghc/ghc/tree/master/rts
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...
> 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
Although I find it interesting that Common Lisp gets left off these lists. It's memory-safe (with GC of course), has great integration with existing C libraries via CFFI, has a formal spec, has a solid library ecosystem, supports a "mostly-functional-but-imperative-if-you-need-it" programming style, has optional/gradual compile-time type checking, and at least one open/libre implementation generates fast native code (SBCL).
Might as well throw OCaml in the mix too, since it has all of the above minus the formal spec.
I remember a recent HN comment said that if you create a website for your new programming language, you should always ensure there's a meaningful example right there on the landing page. A pity that Pony's page fails to do this. Here's one of their example programs. [1]
[1] https://github.com/ponylang/ponyc/blob/main/examples/timers/...
It seems like it's best grouped together with Go, Erlang, Elixir, and Crystal.
But I have always used Pascal for that. It has memory safe strings and arrays with refcounting, so long as one avoids using other features like pointers, classes, inline assembly, it is perfect.
Edit: here's the link, interesting idea. https://github.com/google/wuffs
The memory-safe languages can still panic or have integer overflows, Wuffs should prevent even that
* Languages with significant runtimes are going to be rejected by project maintainers; nobody is going to rube-goldberg a GC into an existing project just to replace a risky component when the option not to do that exists.
* Languages with insignificant adoption are going to be rejected by project maintainers because why take a flyer on an unknown quantity (not just technically but in terms of where the community will be 5 years from now) on a project you've been maintaining for decades? Say what you will about the Rust community and its long-term financial viability but the industry is pretty much already committed to it.
I'm fine with Rust but, like, not it's biggest fan (strongly prefer Go) but Rust pretty clearly hits the sweet spot being targeted here. I think you can assume safely that most of this work will be done in Rust.