[wyatwerp]

Taking nothing away from the Rust community that has managed such a complex language so well so long, I have to say that there never was anything viable in the no-GC no-runtime niche (that is why it is a niche - otherwise why would anybody be using GC'd languages). We were/are just gritting and bearing C++.

If it is a typical program, i.e. not a device driver or OS kernel running on low-memory hardware, having a GC + runtime doesn't preclude performance, for a long-running program. Of course, for short-running programs, just malloc, don't free, is the fastest.

[jandrewrogers]

The use case for non-GC languages go significantly beyond low-level OS kernel type code. Most of our backend infrastructure software and servers (e.g. database engines) are also poor fits for a GC languages, and this is what Rust is targeting. For this type of software, a GC has a large negative performance impact, so it isn't really an option. Operational cost efficiency is often a key factor in platform selection -- being able to reduce hardware requirements by an integer factor is compelling.

To me, Rust is a cleaner and stricter but also more narrow systems programming language than C++, and can be used as a sensible replacement for many C++ code bases, particularly as Rust adds features. Rust still has some challenges. For example, the DMA-driven, schedule-based memory safety models that have become fashionable in high-performance database kernels are not compatible with Rust's memory model. You'd have to make most of the code "unsafe" (in a Rust sense, it is actually an alternative memory safety model designed around a different set of assumptions).

[wyatwerp]

Off-hand, Mirage OS comes to mind - it completely upends how you would "build" and "run" back-end services, and it is written solely in a GC'ed language - OCaml. And all GC'ed languages are not equal; see https://roscidus.com/blog about a Linux package manager ported from Python to OCaml for performance reasons (followed by an OCaml reimplementation of a component in a virtualized OS).

Some infrastructure, e.g. database engines, is ubiquitous, but all instances are of the same few software products written in C/C++/Java. Those ubiquitous instances have banged most bugs out of those codebases, so it is an uphill battle there to convince incumbents and upstarts alike, of the value of a new implementation. But Rust & Pony are marvelously positioned to march up that hill, especially if you throw in multi-threading.

My impression is that only a minority of widely-programmed back-end infrastructure that suits Rust is written in C/C++ (say, map-reduce kernels). The code-base size & the data flow complexity inside those components is pretty limited, and Rust should be tractable at that scale.

Most widely-programmed infrastructure software - in the back-end and on cell phone OS'es - have been merrily using Java/Python/Ruby/Erlang. OCaml is quoted as being used in the management component of VMware. These are much larger applications; is there any evidence or hint that Rust isn't onerous to develop larger systems in? Without that evidence, I feel (not think) that a disciplined GC'ed language (D? Pony?) has a better chance there.

[pimeys]

Having a GC also kind of makes it nasty to write libraries to other GC'd languages. In Rust all of this is very easy, and you can get the speed bump to your Ruby/Python/JavaScript libraries using a modern and safe language.

[wyatwerp]

Is the speed bump for other-language libraries or for other-language applications?

For speeding up other-language libraries, D has a -betterC mode, which prevents you from using the subset of the language and the libraries (standard & user-defined) that relies on GC. The remaining language is a very clean C that simply works on the other language's GC'd memory (using the other language's C interface), and can use stack allocation or any heap allocation strategy of your choice for its working set (reference counting ala C++ shared_ptr could be the obvious choice, but it is your party).

For other language applications, it is a valid option to speed up the entire application by writing it in D, as it has "all" the features of those other languages + all the convenience that is afforded by a GC + threads if you don't want a multi-process design. I quote "all" because I mean useful things like blocks/closures, generic data structures, etc. - of course, neither Rust nor D give you runtime devices like monkey-patching/meta-class hackery/prototype changes.

[pimeys]

We've been rewriting a big Scala code base to Rust now since January and the team is advancing in a nice pace.

Our plan was:

- Take one part of the system to rewrite over JNA

- Run a massive amount of Scala tests against the new code

- When green, take another part

- Meanwhile the other part of the team writes the user-facing code base, connecting it to the new Rust crates

- The test suit works also over an integration layer, so the other team can test their code and the backend with the same test suite

We're quite far already. Originally I was the only person with Rust experience. Now there's five of us.

[hopscotch]

Why are you migrating from Scala?

[pimeys]

The company wants much lower resource usage per node and easy integration with other languages.

[buckminster]

> Of course, for short-running programs, just malloc, don't free, is the fastest.

A custom malloc that knew free would never be called would be faster still. I wonder if any short-running utilities do this?

[pornel]

AFAIK the D compiler is basically this.

[wyatwerp]

And it is a short-running utility :-)