rusty-TONC VS rust

If you are comparing hoops that library authors need to jump through in both languages, you can easily make the real-world comparison in the other direction, by comparing Rust's Option with C++'s std::optional (an exercise left for the reader): Rust std: https://github.com/rust-lang/rust/blob/master/library/core/src/option.rs libcxx: https://github.com/llvm-mirror/libcxx/blob/master/include/optional

finishing const generics, so that you can use them in const expressions in a natural way (including in associated constants)

I haven't considered that option yet. If you think it is worth exploring, it might be good to leave that idea in a comment on the tracking issue: https://github.com/rust-lang/rust/issues/99012

Typo: The "shipped as part of Rust 1.71" link should probably point to https://github.com/rust-lang/rust/issues/109999.

Here is the original GitHub issue on the question:

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

Intuitively, the bottom lifetime should the one that is uninhabited, which would be a lifetime with no extent rather than 'static.

Easy to compare:

Search the gnat bug tracker for stack overflow: 14 bugs https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=Ada%20s...

Rust: 243 (plus 830 closed) https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...

Choose by yourself which seems safer

He delved into the evolution of AWS Lambda's pricing strategy, transitioning from T2 instances to the innovative Firecracker microVMs for superior resource optimization. Vogels also advocated for exploring energy-efficient programming languages like Rust, showcasing AWS's adoption in Firecracker and a substantial segment of their S3 service, aiming for more efficient and cost-effective solutions. This blog is really helpful about Firecracker – Lightweight Virtualization for Serverless Computing

It's Christmas time and time for Advent of Code 2023 edition. Starting from today I will try to solve puzzles in Rust and publish a post a day in which I tell my solution. My goal is not to climb the leaderboard but to use the problems to practice writing Rust code and improve my language knowledge. Copilot yes or Copilot not? It's for learning so Copilot definitely not. The solutions will be available at the following git repository, as I don't have much time to write a template from scratch, I will use the starter template available here.

> I know it’s easy to change but the arguments for using glibc’s allocator are less clear to me:

You can find them at the original motivation for removing jemalloc, 7 years ago: https://github.com/rust-lang/rust/issues/36963

Also it's not "glibc's allocator", it's the system allocator. If you're unhappy with glibc's, get that replaced.

> 1. Reliability - how is an alternate allocator less reliable?

Jemalloc had to be disabled on various platforms and architectures, there is no reason to think mimalloc or tcmalloc are any different.

The system allocator, while shit, is always there and functional, the project does not have to curate its availability across platforms.

> 2. Compatibility - again sounds like a FUD argument. How is compatibility reduced by swapping out the allocator?

It makes interactions with anything which does use the system allocator worse, and almost certainly fails to interact correctly with some of the more specialised system facilities (e.g. malloc.conf) or tooling (in rust, jemalloc as shipped did not work with valgrind).

> Also, most people aren’t writing hello world applications

Most people aren't writing applications bound on allocation throughput either

> so the default should probably be for a good allocator.

Probably not, no.

> I’d also note that having a dependency of the std runtime on glibc in the first place likely bloats your binary more than the specific allocator selected.

That makes no sense whatsoever. The libc is the system's and dynamically linked. And changing allocator does not magically unlink it.

> 4. Maintenance burden - I don’t really buy this argument.

It doesn't matter that you don't buy it. Having to ship, resync, debug, and curate (cf (1)) an allocator is a maintenance burden. With a system allocator, all the project does is ensure it calls the system allocators correctly, the rest is out of its purview.