rust VS carbon-lang

Rust

It seems to be more fussy about compiler optimizations, though: https://github.com/rust-lang/rust/issues/125543

apimock-rs is one of my projects on API mock Server generating HTTP/JSON responses to help to develop microservices and APIs, written in Rust.

Rust, the language itself depends on 220 packages: https://github.com/rust-lang/rust/blob/e8753914580fb42554a79...

If you trust nobody, it is hard to use anything.

But about your second note, (environment, mismatched dependencies), I would argue that Rust provides the best tooling to solve or identify issues on that area.

rustc source code

First look is into The Unstable Book. Well, it does not look informative but gives us some background from the rust-lang Github project-const-generics. It says:

Rust has been around for several years and works well as a system and general programming language. There are many fine introductions to the language, a good place to start is here: https://www.rust-lang.org/

‍For the rest of this post I’ll list off some more tactical examples of things that you can do towards this goal. Savvy readers will note that these are not novel ideas of my own, and in fact a lot of the things on this list are popular core features in modern languages such as Kotlin, Rust, and Clojure. Kotlin, in particular, has done an amazing job of emphasizing these best practices while still being an extremely practical and approachable language.

> There are online Rust compilers and interpreters already if you just want to rapid prototype and develop ideas in Rust

You are responding to one of the key developers of Rust early on[1], who's been working with the language for 14 years at that point.

[1] https://github.com/rust-lang/rust/graphs/contributors?from=2... and he's still #16 in commits overall today, despite almost no activity on the rust compiler since 2014.

If you haven't dipped your touch-typing fingers into Rust yet, you really owe it to yourself. Rust is a modern programming language with features that make it suitable not only for systems programming -- its original purpose, but just about any other environment, too; there are frameworks that let your build web services, web applications including user interfaces, software for embedded devices, machine learning solutions, and of course, command-line tools. Since a custom GitHub Action is essentially a command-line tool that interacts with the system through files and environment variables, Rust is perfectly suited for that as well.

Thanks for clarifying that point. It's worth pointing out that the safety strategy doc[0] mentions that

>A key subset of safety categories Carbon should address are:

>[...]

>Data race safety protects against racing memory access: when a thread accesses (read or write) a memory location concurrently with a different writing thread and without synchronizing

But then later in the doc it says

>It's possible to modify the Rust model several ways in order to reduce the burden on C++ developers:

>Don't offer safety guarantees for data races, eliminating RefCell.

>[...]

>Overall, Carbon is making a compromise around safety in order to give a path for C++ to evolve. [...]

One could read this as saying that guaranteed safety against data races is not a goal. Perhaps this doc could be reworded? Maybe something like "Carbon does not see guaranteed safety against data races as strictly necessary to achieve its security goals but still we still currently aim for a model that will prevent them."

[0] https://github.com/carbon-language/carbon-lang/blob/trunk/do...

It's even a core point for Carbon, their hopeful C++ replacement

Under language goals on their readme,

> We also have explicit non-goals for Carbon, notably including:

> * A stable application binary interface (ABI) for the entire language and library

> * Perfect backwards or forwards compatibility

There's also this blurb

> Our goals are focused on migration from one version of Carbon to the next rather than compatibility between them. This is rooted in our experience with evolving software over time more generally and a live-at-head model. Any transition, whether based on backward compatibility or a migration plan, will require some manual intervention despite our best efforts, due to Hyrum's Law, and so we should acknowledge that upgrades require active migrations.

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

The roadmap for Carbon [0] mentions wanting to have basic, non-trivial programs written in Carbon by the end of 2024. They're aiming for a v0.1 release in 2025. If it gains traction, they're aiming for a v1.0 beyond 2027.

I don't think anyone outside Google will seriously adopt this before it reaches v1.0. Even within Google, they may choose other options.

[0] - https://github.com/carbon-language/carbon-lang/blob/trunk/do...

Carbon was started by Chandler Carruth, at Google, but they wanted to move it to broader governance quickly. It's not under the Google GitHub today, but its own org.

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

What do you think about Carbon[1]? I am hopeful.

[1] https://github.com/carbon-language/carbon-lang

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

next year 0.1 will be usable, 1.0 is about 3 years away, sigh, back to my rust fight