rust VS carbon-lang

Not OP, but one thing that surprised me was if you are doing rust Simd in a library, and part of the code is marked #[inline] but others are not you might see catastrophic performance regressions. We saw an issue where the SIMD version was over 10x slower because we missed marking one function as inline. Essentially rustc converted it from an intrinsic to a regular function call.

https://github.com/rust-lang/rust/issues/107617#issuecomment...

I believe it's not stable because it gives std::boxed::Box special treatment in the language. They'd rather find a solution that could work equally well for smart pointers defined outside of std.

Box patterns are likely to be superseded by one of these:

https://github.com/rust-lang/rust/issues/42640

https://github.com/rust-lang/rust/issues/87121

Rust's stdlib's API is completely safe here. On Windows[1], it uses the GetEnvironmentVariable/SetEnvironmentVariable API, which as you noted doesn't have this problem. On Unix[2], it maintains its own RwLock to provide synchronisation. Additionally, Rust's API only gives out copies of the data, it never gives you a pointer to the original.

The problem comes when you do FFI on *nix systems, because those foreign functions may start making unsynchronised calls to getenv/setenv.

[1] https://github.com/rust-lang/rust/blob/master/library/std/sr...

[2] https://github.com/rust-lang/rust/blob/master/library/std/sr...

If you want to learn Svelte or Rust (Tauri) while building this project with us, send me an inbox!

IMO it would be good to familiarize yourself with the rust quirks/features (check out the rust book) and then poke at some of the embedded specific groups. Once you get a handle on the common types and patterns it's probably easier to find the information you're looking for, e.g.:

https://github.com/rust-lang/rust/issues/46213

In general Rust chases a "zero cost abstraction" ethos, so a lot of the type system niceties have no code or memory cost because the heavy lifting is done at compile time, not run time. For instance using specific traits for each GPIO pin ensures you won't accidentally apply some meaning meant for another pin, but the compiler will compile it right down to integers anyhow.

Things like options (how Rust deals with "null" values) are enums and usually incur a one byte penalty, but in some cases they can be compiled down to no overhead at all.

Here is one I know of: https://github.com/rust-lang/rust/pull/90346

I believe this is one as well: https://github.com/rust-lang/rust/pull/113535

> I still sometimes get lifetime errors that I don’t understand.

I'd like to remind people that errors you don't understand are bugs and I'd encourage you all to file a ticket when encountering any: https://github.com/rust-lang/rust/issues/new?assignees=&labe...

As far as I know, the proposal to add one was determined to need an RFC: https://github.com/rust-lang/rust/pull/65875

I've been trying to learn Rust for the better part of this year. My curiosity peaked a few years back when I learned the AWS-led Firecracker was developed with the language. And I've continued to want to learn it ever since. Fast-forward and I'm jumping both feet in. That's usually how I work. I must admit that right now, I'm the most noob of noobs, but that's not going to keep me from sharing what I'm up to and what I'm learning. For me, this blog is as much about sharing as it is about learning and communicating to those reading that it's OK to be where you are in your journey. There are no straight lines. Only periods of growth and plateaus. In this article, I'll walk you through consuming an SQS Event with Lambda and Rust.

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

The "Dart plan" vs "TypeScript plan" comparison is shown at 1:33:50 in the talk:

> "Dart plan" - Competitive/successor 10x improvement

> New creation

> Limited interop, relies on wrapping/marshaling/thunking...

> Competes with standard (e.g., different modules, different generic constraints)

> Evolves independently of standards committee - far fewer design constraints

> Needs to bootstrap a new ecosystem

> "Typescript plan" - Cooperative/compatible 10x improvement

> Every .js file is a valid .ts file, add 1 class and see benefit

> Lowers to standard .js, 100% seamless compat with all JS libraries

> Cooperates with the standards committee (ECMAScript)

> Brings evolution proposals to standards committee

> Leverages entire existing ecosystem - works with all JS implementations & tools

Carbon is an example of the "Dart plan". Some quotes from Carbon's "Interoperability philosophy and goals" page (my emphasis):

> The C++ interoperability layer of Carbon allows a subset of C++ APIs to be accessed from Carbon code, and similarly a subset of Carbon APIs to be accessed from C++ code.

> The result is that it will often be reasonable to directly expose a C++ data structure to Carbon without converting it to a "native" or "idiomatic" Carbon data structure. Although interfaces may differ, a trivial adapter wrapper should be sufficient.

> There should be support for most idiomatic usage of advanced C++ features. A few examples are templates, overload sets, attributes and ADL.

> Non-goals

> Never require bridge code

> Support for C++ exceptions without bridge code

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

1. Carbon

Another interesting C++ successor language:

https://github.com/carbon-language/carbon-lang

To put it even more plainly than the others: https://github.com/carbon-language/carbon-lang#project-statu...

> Carbon Language is currently an experimental project. There is no working compiler or toolchain. You can see the demo interpreter for Carbon on compiler-explorer.com.

You don't want to find yourself in the Ministry of Truth's Community Transparency Report. If Carbon shipped an implementation, people might commit some of their attention to that, but when discussion is all there is, you'd better believe that discussion will be audited to the letter.

cppfront, Carbon:

Carbon at least open sourced (https://github.com/carbon-language/carbon-lang) and can be tested on their experimental compiler w/o sign up. Their ethos and whole approach feels a lot less 'scammy' than Mojo does to me at the moment.