[zelly]

> built-in library support for logging, http, zip, gzip, json, yaml, template rendering, RFC3339 datetime reading/writing

There is a Boost library for each of those things.

> An opinionated, modern packaging and dependency story (like go modules, Rust crates)

> the dream: compliant compilers must be able to compile down to static binaries, cross compiling built-in.

You can use Conan or vcpkg. LLVM basically solves the cross-compiling issue since you can take the IR to any platform that has a LLVM target.

Neither of these are feasible to include in the International Standard because C++ runs on more than amd64 and would make a lot of obscure platforms no longer compliant with the standard. Rust crates are nice, but people building medical devices with C++ shouldn't need to worry about supporting an npm-like monstrosity in their builds.

[steveklabnik]

LLVM IR is not platform independent.

Rust compiles on far more platforms than amd64, and Cargo works just fine.

Nothing forces you to depend on any packages you don’t want to.

[zelly]

> Nothing forces you to depend on any packages you don’t want to.

Nothing stops you, either, which is a problem for everyone in the future who uses your code. The first reaction to any problem in JavaScript/webdev is to google for a library to import to solve the problem. This is acceptable behavior because the existence of a web browser implies powerful enough resources to accommodate bloat. But this mentality isn't acceptable on other systems and has even infected some basic functionality:

https://crates.io/crates/rand

The random number generator for Rust has 6 dependencies. In C++, it's only lib[std]c++. In Java, it's java.base.

[pornel]

Random number generation has trade-offs for speed, security, and thread safety.

Most other langues with a "simple" built-in are unfit in some of these aspects, so you may end up with a footgun and still have to find a replacement.

In Rust you can choose which algorithms are used and how. And because it's a regular package, it can be improved without breaking the language.

Note that number of dependencies doesn't mean anything. Some crates are split into tiny deps for each feature, so that you can reduce binary size and compile time if you disable optional features.

[zelly]

That's true for libc's naive rand() which is used by Python, JS, Ruby, PHP, etc.

But stock C++ has many options for the random number generation algorithm:

https://en.cppreference.com/w/cpp/header/random

As does Java and .NET. Without any dependencies and guaranteed to be portable.

> Note that number of dependencies doesn't mean anything. Some crates are split into tiny deps for each feature, so that you can reduce binary size and compile time if you disable optional features.

In theory I agree. It just seems like one of the persistent unsolved problems in software is dependency hell (spawning the whole containerization movement), so I'd like to avoid it if I could.