>Also, zero-cost abstraction is likely the biggest bullshit I've ever heard, there is a lot of cost and there's also a lot of waiting for compiler if you're using cargo packages.

"(...) there are two factors that make something a proper zero cost abstraction:

No global costs: A zero cost abstraction ought not to negatively impact the performance of programs that don’t use it. For example, it can’t require every program carry a heavy language runtime to benefit the only programs that use the feature.

Optimal performance: A zero cost abstractoin ought to compile to the best implementation of the solution that someone would have written with the lower level primitives. It can’t introduce additional costs that could be avoided without the abstraction."

https://boats.gitlab.io/blog/post/zero-cost-abstractions/

It's not about compile time...

> you can't initialize some const x: SomeStruct with a function call.

You can if it's a `const fn`. The set of features you can use in `const` is small but growing.

> Also, zero-cost abstraction is likely the biggest bullshit I've ever heard, there is a lot of cost and there's also a lot of waiting for compiler if you're using cargo packages.

While someone else is right that "zero-cost" refers to runtime cost rather than compilation cost, dependencies are the biggest problem.

The program `spotifyd` takes over an hour to compile on my X200 laptop. This is, for reference, the same amount of time that the Linux Kernel and GCC takes to compile (Actually, I think GCC takes less time...). Most of the compilation time is on the 300+ dependencies, that simply wrap C (and in some places, replicate) libraries that I already have installed on my system!

I've also heard that Rust compilation is slow, so I put off learning it for a while. I finally dug in deep recently and, to be honest, I don't understand the issue. Rust compilation is quite fast in my experience.

Your comment was the first I've heard of spotifyd, so I downloaded it from github and ran "cargo build". I spent 3 minutes figuring out that I needed to install the "libasound2-dev" package, then I spent less than 2 minutes compiling. I watched the clock to be sure, but after only 2 minutes, Cargo produced a target/debug/spotifyd executable. Maybe you're referring to --release compilation?

I don't have the fastest PC, it's just an 8 year old desktop with a 6 core Intel i7 980x running Ubuntu 18.04. Rust compilation maxes out all the cores, which is really nice.

With the RustEnhanced package added to Sublime Text, editing Rust code is a very interactive experience with practically instant feedback. Running tests is fast too.

I wish I understood why some people are apparently having a very different experience. Maybe it's slow on some operating systems.

> Maybe you're referring to --release compilation?

Indeed.

Ok, well, "cargo build --release" took 3 minutes and 55 seconds, which I would consider reasonably fast for compiling and optimizing 300+ libraries. I guess your laptop has only 2 cores in an older processor, which would explain the difference. Kudos to you for keeping good hardware alive.

sometimes it takes 100x more without any apparent reason - it's probably because of memory or something, what takes minute to compile on my MBA, sometimes never finishes on raspi3 (swap is off)

I currently compile on raspi4 and scp the results there to check.

An X200 is also an ancient machine. Do you value your own time so little? Clearly you are annoyed by the compile times?

You can get a $200 CPU that will blast through a kernel compile in 3 minutes.

> An X200 is also an ancient machine. Do you value your own time so little? Clearly you are annoyed by the compile times?

I value my security first and foremost. My X200 has zero binary blobs running on the machine, it also has several other properties that I appreciate.

> You can get a $200 CPU that will blast through a kernel compile in 3 minutes.

That assumes that I even have the money to afford that. Not all of us live in silicon valley.

I hear you. I'm really hoping that Swift improves over the next few years. It seems to be in a great sweet spot with many of the modern language features of Rust (optional / result types, parametric enums, try, generics, static compilation, etc). But it also has the ergonomics of a language like Go thats explicitly designed for writing practical code and just getting work done.

Swift is still missing decent async / await support, generators and promises. Some of this stuff can be written by library authors, but doing so fragments the ecosystem. Its also still harder than it should be to write & run swift code on non-mac platforms. And its also not as fast as it could be. I've heard some reports of swift programs spending 60% of their time incrementing and decrementing reference counts. Apparently optimizations are coming. I can't wait - its my favorite of the current crop of new languages. I think it strikes a nice balance between being fancy and being easy of use. But it really needs some more love before its quite ready for me to use it as a daily workhorse for http servers and games.

Another PITA is the lack of safe static variables.

Rust does have safe static variables. You just need a) to use interior mutability (`static mut` is a very strange feature that should probably never have existed) and b) to ensure that its type is `Sync` (since multiple threads can obtain references to it).

For example, use an atomic integer: https://play.rust-lang.org/?version=stable&mode=debug&editio...

You can also use types built on std::sync::Once and UnsafeCell, like once_cell::Lazy<std::sync::RwLock<T>>. This will get even easier as we get `const fn` constructors for locks in the future.

Interesting but this seems so unergonomic that I will still be virtually forced to not use static variables and thus loose their expressive power.

Try https://docs.rs/once_cell/

> Also, zero-cost abstraction is likely the biggest bullshit I've ever heard, there is a lot of cost and there's also a lot of waiting for compiler if you're using cargo packages.

Zero cost refers to runtime cost, not compilation cost. Zero cost abstraction is not bullshit.

Yes, I know, and all those crates trying to wrap unsafe C libs are really not free - I've tried.

Maybe just dig into some sources and see what macros are expanded to to see the overhead.