> HOWEVER, Rust is such an excellent language that we all want to use it to write applications ANYWAY.

Is this really the reason, or is it because people think they will get free performance wins by choosing the correct language? The plethora of articles detailing a developer's story trying to write X-style language in Rust shows that most are not approaching Rust with the correct mindset.

I have limited experience is Rust, but seems like most people are attracted by shiny new toys in the language. Many people have issues with OO languages, and the separation of data and function is attractive. But it lacks the run time most application developers have come to know, specifically GC and easy references.

I'm sure there's a bit of both. Many people talk about how they love the tooling, the type system, enums, traits... stuff unrelated to performance.

I can only speak for myself, obviously. But, I think it's obviously about more than performance. Otherwise, people have always had C, C++, LISP, and even Java and Go that will be generally faster than Python, PHP, and JavaScript.

I'd say there are three things that most people rave about with Rust:

* traits as type classes (even if they don't know the term "type class") * enums and pattern matching (not even as flexible as some other languages like MLs, but way more than is possible in most popular languages with only Swift coming close) * the Iterator trait. I might write a sonnet about how much I love Iterator in Rust. It's lazy iteration, but it's also optimized at compile time to basically just be turned into a for loop.

The problem with OCaml is not multicore. If it had an easier to use build system and a larger community (so more libraries), it could be great for server-side software. But dune is way harder to use than Cargo and you can often miss libraries. Here's an example of Dark moving away from OCaml to F# https://blog.darklang.com/leaving-ocaml/, which doesn't have as much this problem because you can use C# stuff. Scala also doesn't suffer as much from it, part of it because it was really popular at some point, and part of it because you can use Java anyways.

I hope at some point we'll have this "garbage collected Rust", but for now OCaml, Scala and F# all have a worse developer experience than Rust. I could add Haskell to that too.

I've been thinking for some time that something like Go but based on a ML would fill this "garbage collected Rust" niche quite well. Maybe something built over Rust itself to leverage all the ecosystem? You could write all of the glue code in this language, have access to a large ecosystem of libraries and have an option for high performance code. This would also complement Rust nicely: I know that OCaml has a really fast compiler, which would be a breath of fresh air for the community.

> I hope at some point we'll have this "garbage collected Rust", but for now OCaml, Scala and F# all have a worse developer experience than Rust. I could add Haskell to that too.

F# on Visual Studio + .NET ecosystem (which includes C++/CLI, C# and first class support for COM/UWP) is worse than Rust?!?

How many of those things work well on Linux/MacOS? Rust, Cargo, rust-analyzer, VSCode work on every major plateform. You also have access to the .NET ecosystem but it's not as easy as the Rust ecosystem since most of the packages are C#, not F#, and idiomatic C# and idiomatic F# are quite different. In terms of resources too, F# is quite poor compared to Rust.

Edit: another thing, compiling to native is not really a first class citizen on .NET. That makes it a bit worse to distribute tools compared to Rust, Go or OCaml. Scala also suffer from this.

F# can just use C#, that is the magic of CLR.

VScode F# plugin and Rider also have much more resources into them.

Then 20 years of production code to chose from.

You can use C# from F#, of course, but then you can run into issues with nulls and things like that. There's a reason every programming language has their own implementation of JSON/XML parsing, HTTP and things like that: offering an idiomatic API is important.

Last time I use the VSCode F# plugin (around a year ago), the experience was strictly worse than rust-analyzer. The compiler errors are also not as good. I've never used Rider so I can't comment on that.

You're right about the 20 years of production code for C#. NuGet lists 241418 packages compared to crates.io 61579 crates, and there's a good chance most of them are more mature than the Rust alternatives. However that's C#, not F#, and I doubt F# represents more than 10% of the packages. That's still better than doing it yourself if there's no package or writing bindings to C though.

I still think F# and Scala are solid choices if you want a functional language today, but it's not the "garbage collected Rust" ideal I wish we had.

I think you're talking about Swift. Alas it doesn't seem to have caught on outside of the Apple ecosystem, so library support isn't great there either.

I do agree that language built on top of the Rust ecosystem (kind of like how PHP exposes a lot of C libraries) could make a lot of sense.

I don't think I am talking about Swift. The compilation is slow because of LLVM and you still have to handle cyclic references because of ref counting. As you said too, library support isn't great. I don't know how exactly is the dev experience too, at least outside of XCode. Last time I played a bit with it, adding the language server to VSCode was a bit of a pain. Still, I think Swift is a step in the right direction.

I've heard good things about Nim too for this niche but never tried it. I think it'll suffer from the same problem of not being able to leverage an existing ecosystem though.

Nim compiles to C (through C?), so at least leveraging the C/C++ ecosystem is straightforward/first class.

It is certainly difficult to justify breaking away from the huge established multiple decade ecosystems and standard libraries seen with the JVM/.NET/Python platforms for instance.

https://nim-lang.org/docs/backends.html#interfacing

OCaml is also pretty good at leveraging the C ecosystem, but that's not what people are looking for in a "garbage collected Rust". If they want something close to C they'll just use Rust. What they're looking for is something easier to write that still looks like Rust and having all the developer experience that Rust has. For this, the Nim ecosystem is way too small and can't leverage an existing platform. The same do apply to OCaml and Swift so it's not a Nim specific problem, it's just that Nim doesn't bring much compared to OCaml.

For what it's worth, OCaml is a great under-appreciated language forever dented by ugly (in my opinion) syntax and oddities like different operators for floats and ints. There's a good reason the folks behind the Reason ML fork changed things up.

Swift is another great language - forever dented by being tied hand and foot to the Apple holy garden and Objective-C legacy and runtime with memory-related keywords such as 'weak' and 'unowned'.

Nim (and perhaps D) are the closest in my mind to the "garbage collected Rust" in that they are not only garbage collected, but they are procedural-oriented, can write highly generic code and macros, and come with near-C performance. Given the "Pythonic Rust" title, another edge Nim has is its semantic whitespace, very Python-esque syntax.

There are/were many less staunch languages that interoperated with Rust in a clean way.

    * https://gluon-lang.org/
    * https://github.com/PistonDevelopers/dyon

Rust is waiting for that interior language so that everyone doesn't need to subscribe to the same complexity budget.

I've looked a bit at Gluon before and it was a bit too much like Haskell for what I imagined. I don't think using monads for IO is a good idea if you want to keep the Rust approach of pragmatism first.

I don't know anything about dyon but a quick look tells me it's more meant for game development.

> I'd like to have a different recommendation for a "garbage collected Rust" but there really isn't anything that I think is good enough for the title.

D and Nim are both good candidates IMO.

Could you expand on that? They both seem like nice language, but why them over other proposed languages such as OCaml, Scala and F#?

Not the person you replied to, but OCaml, Scala, and F# all suffer from the potential drawback of being functional-first, and thus difficult for people to adapt to. If you are someone who is an OO programmer and are considering Rust for its potential performance and different model, it would be hard for me to recommend a language whose model is as different as OCaml's. Learning Rust entails learning the borrow checker and unlearning some of your OO habits; learning OCaml requires a sea change in your whole mentality & approach to programming if you've never experienced a functional lang before.

Meanwhile, both D and Nim have the benefits of being procedurally grounded, and hence more familiar to someone coming from (say) C# or Java.

Having said that, I think both of those languages may suffer from a lack of tooling/library breadth & depth. Nim in particular seems really cool, but it seems to be struggling to catch enough attention & interest to build a larger community -- probably in large part because it targets many of the same people who are currently high on Rust.

I don't really agree here, even if they're not used much by the community OCaml can be written as a regular procedural or OO language. There are a few thing that can look weird for people new to this (immutable by default, the type system) but they're precisely what people looking for a GC'd Rust want I think. Rust also takes a lot from functional languages, and idiomatic Rust code usually looks like functional code. I think the biggest shock coming from Rust to OCaml would be the compiler errors and the quantity of online resources. There's a world of difference between the two, and they matter a lot when learning. I think the same is true for Scala. I don't know if F# is the same but since it takes from OCaml it may still have the procedural capabilities, and it seems it still has the OO features of OCaml.

I do agree that D and Nim may be easier to approach from C# or Java, or even Python for Nim or C and C++ for D. These already represent a huge chunk of programmers, but not really what the typical person looking for a "garbage collected Rust" is, in my opinion. Especially since Java and C# programmers already have Scala and F#. While they're both different from what they're used to, they leverage the same plateform and can use the same libraries which is a huge plus.

I agree with your conclusion too, and I think OCaml suffers from this too. Scala and F# have at least the libraries part covered.

> I'd like to have a different recommendation for a "garbage collected Rust"

I have exactly the same problem. Rust is nearly perfect to me, due to its non-nullable type, traits, package manager. It's just that losing garbage collection is not justifiable in my use cases. I've researched several languages but nothing "clicks" unlike what Rust did to me several years ago. C# might be my best bet but it lacks statically compiled binary. Go is my next bet but it lacks a sophisticated typesystem. Kotlin is my third bet but the Java toolchains are slow and too "enterprise-y". Swift is too Apple-centric and has weird corner cases like you can't change the order of the keyword parameters, due to its Objective-C origin. Life is full of trade-offs, I guess!

Seems like c# is gaining lots of traction on AOT stuff very soon.