One specific example I encountered was ndarray. I couldn't figure out how to make a function take an array and an arrayslice without rewriting the function for both types. This could be because I'm novice with the language, but it didn't seem obvious. I ended up giving up after trying to dig through the docs for a few hours and went back to C++.

Maybe for your use cases that's OK, but there are many situations where the size and ease of upgrading provided by shared libraries is worthwhile. For example it would suck to need to push a 40+ GB binary to a fleet of systems with a poor or unreliable internet connection. You could try to mitigate this sort of thing by splitting the application up into microservices, but that adds complexity, and isn't always a viable tradeoff if maximizing compute efficiency is also a concern.

In my understanding, you can't interface with the C abi without using an unsafe block.

The main issue I have with rust is the lack of a rust abi for shared libraries, which makes big dependencies shitty to work with. Another is a lot of the big, nearly ubiquitous libraries don't have great documentation, what's getting put up on crates.io is insufficient to quickly get an understanding of the library. It'd also be nice if the error messages coming out of rust analyzer were as verbose as what the compiler will give you. Other than that it's a really interesting language with a lot of great ideas. The iterator paradigm is really convenient, and the way enums work leads to really expressive code.

This is basically just a way nicer, more flexible cron syntax being dressed up as something ridiculous. There are legitimate reasons for wanting something like this, like running some sort of resource heavy disk optimization the first Friday evening of every month or something.

Hopefully articles like this get more companies contributing to steamos/proton

Tbf, does anyone actually "like" C++?

Pretty crazy to reccomend Java as a secure alternative.

Now it'll go to some private equity vampire who will really ruin it

They can't, even suggesting they'd think of making such a move would've ruined them. No one in their right mind would do business with a company that's willing to even entertain retroactive changes to payment structure. Just an insane risk to take.

If your cloud provider decides to screw you you're gonna have to put physical infrastructure together no matter what license their software is distributed under.

I don't understand why you'd be fixing unit tests he broke during his pr. It seems like he might be bullying you? Maybe discuss with your manager.