[andai]

In my experience, what's actually nice is the correctness. The low-levelness is not helpful for most of the software I write, and imposes a constant burden.

Rust, of course superbly achieves its goals within its niche! But it is a niche, is my meaning here.

What I actually want is code that's correct, but ergonomic to write. So my ideal language (as strange as it sounds) would be Rust with a GC.

I don't want to worry about what string type I'm using. I want it to just work. But I want it to work correctly.

Lisette looks like it's in this exact category! It seems to combine the best aspects of both Rust and Go, which is a very promising endeavour. I'll have to take a proper look :)

[mirekrusin]

MoonBit [0] is the best/future complete/active “rust with gc”.

[0] https://www.moonbitlang.com

[bearforcenine]

Did MoonBit add support for some kind of shared memory concurrency like threads? I remember discovering the language, being very excited about it, and then learning it is single-threaded, which makes it a poor replacement for Rust IMHO.

[mirekrusin]

I believe it's not as much moonbit's limitation as wasm-gc limitation – shared gc structs will have to be supported at low level in wasm-gc first and I don't think there are any concrete proposals for it yet?

They support native target (as well as js target) but wasm one was always the primary one.

Having said that they have (cooperative) async for native target only currently.

Personally I'm looking forward for them to self host it – not sure why they're still holding to ocaml compiler, the language seems sufficient to have moonbit written in moonbit. Together with it I'm waiting for proper open source – currently what the team is doing is a bit like what Meta sometimes does – internal development, no community development, they just dump updates as snapshots from time to time instead of normal, fully open development.

I'm also clinging on my last intel purchase (macbook pro) and unfortunatelly they don't provide intel builds for macOS just arm ones (even though they do for linux), which is a bit of a pain – but I think I'll just buy arm macbook before they'll support intel on macOS (and maybe they'll never do, which is fair). It's a small thing from moonbit perspective, but annoying and limiting a bit for me personally to work remotely only with it.

[akkad33]

You can use Ocaml today and achieve all the correctness

[IshKebab]

OCaml has a lot of other cons though that Rust doesn't have. I would definitely pick Rust over OCaml even for projects that can tolerate a runtime with GC pauses. (And clearly most people agree.)

[amelius]

What cons?

[jech]

The ecosystem. The language is lovely, but dune/opam is not up to the standard of the Go or Rust build systems, and the set of useful libraries is somewhat skewed. Whenever I write a program in Caml, I gain an hour thanks to the nice language, and then lose two fighting with dune/opam.

There's also the support for concurrency and parallelism, which has started to improve recently, but is still years behind what is available in Go (but still better in my opinion than what is available in Rust).

[zorobo]

For example, multicore OCaml is not free of race conditions. The GC, while super efficient (pauses are in the milliseconds), is not suitable for hard realtime.

Still, where absolute max performance or realtime are not required, I'd choose OCaml as it is elegant & a pleasure to code in (personal opinion, ymmv).

[IshKebab]

Poor windows support, confusing and buggy tooling (yeah really), mediocre documentation, global type inference, weird obsession with linked lists leading to performance gotchas, difficult syntax (yeah really), small community.

I can expand on any of those if you disagree with them.

[masklinn]

> all the correctness

When did OCaml get affine types? Or unique references?

[zozbot234]

https://oxcaml.org/

[gf000]

There are an endless number of modern MLs that do the same thing. That's not a novelty - Rust was novel in making it part of a low-level language.

[tux3]

I don't think being low level is the main innovation, really. There are several things Rust did right over traditional ML. Explicitly caring about learnability and the "weirdness budget". Having great error messages that don't require a course in category theory (many ML) or 800kB of scrollback buffer (C++) to understand.

Having great tools. Excellent documentation. Being friendly to new users.

Yes, it's also a systems language without a runtime. But that's not the novel part. You could write horrors in C++ that approximate ML even without language support. There are eldritch libraries where some kind of pattern matching is done via generic lambdas.

The main difference is developper UX. Good tools, good error messages, quality of life. The novelty is making ML not painful.

[masklinn]

> Yes, it's also a systems language without a runtime. But that's not the novel part.

Low level strong correctness was absolutely a novel part. In fact it’s exactly why many people glommed onto early rust, and why it was lowered on the stack.

Although learnability and weirdness budgets were also extremely novel in low level contexts which had been subsumed by C and C++.

> horrors in C++

Yes, horrors in C++. Half baked jerry-rigged and barely usable nonsense. Not an industrial strength langage with a reliable type system and a strong focus on safety through types.

[uecker]

Memory safety is not the same a scorrectness and more advanced type is also not the same thing as correctness.

[masklinn]

50 years of computing have proved pretty conclusively that less than that is wishful thinking at best. Large C++ programs, even with massive amounts of resources and tooling, can’t even get memory management correct.

[uecker]

That Rust gives you correctness is very misleading claim.

[gf000]

These are all great qualities of rust, but they would not have been enough to make a dent.

Being memory safe without being managed is what makes rust a truly novel and interesting language for which it rightfully gets the hype.