In my mind I think that doing an execution of an external program is fine in scritps, but for more robust programs you should use libraries. There are of course exceptions, I once used libsvn instead of just calling the svn binary (as you understand, this was a long time ago, when svn was till the way to version software). libsvn turned out to be the most horrible library, so for that it would have been better to call the binary instead. But, in general, avoid runtime dependencies and errors if possible, also libraries normally allows for much better error handling. So, I always use a library if available and not obviously horrible.

My use for rust at work have been to avoid C when using third party libraries. Rust bindgen is very nice to use. This way I get to use a modern language instead of C. Also replaced some java for a performance critical media monitor and xfer engine. On my spare time I have been doing some minor hacking for fun on Cosmic Term

I noticed that the Flatpak didn't work on Fedora 39, probably due to how they build the flatpak or something. I had no problem taking screenshots under Fedora 39 Wayland session using the Appimage.

If there just were some link, to some blog post or something, that would expand on the topic.... with a tl;dr for the really lazy people... well, that would have been nice....

I see this post as an advice to learn gradually, and to write sloppy but painless code initially. Then when you have the basics, you can add the more idiomatic and tricky parts.

Ok, I don't know what is more worrying, that a developer fails to find prettier on GitHub, or that a developer fails to Google it. But I guess that if you fail this, you were probably not the target audience for the challenge.

I must say I am a bit confused. They are open source, and some previous blog post said they are certifying upstream. Yet, they sell quality managed licenses. So, what are these licenses and why are they needed?

A reference &T holds a pointer, ie. the memory adress to the actual content of T

So, in the example x doesn't hold the value 42, it holds the memory adress to the memory there the integer value 42 is stored. So, to access the value, you need to dereference the reference. Which is why you need to use *x when you assign the value.

I see where you come from. I first turned to Go, but at the end of the day it was a nice language but it didn't tick my boxes. One of my main issues for backend servers, is for them to be robust. They should never fail in runtime. That means error handling is quite important, and as few runtime errors as possible. Go, fails this hard. The strictness of Rust, may be a pain while learning, and some syntax may be less than optimal, but the result will almost never fail in production. I have in fact never had a backend I wrote fail in production. The error handling also makes it easy to find any errors due to things out of my control. I switched a project from Java to Rust, and the log shrunk by a factor 10.

Note, I still use Go sometimes, but it is not my go to language. And on a second note, that you point to .unwrap() indicates that you never really used rust to write a backend, since use of .unwrap() will panik if you use that. You normally use .unwrap_or(...) or some other better construct. Also, complaining about unwrap() would indicate that you prefer a null pointer issue? Because, dropping null/nil is one of the great design choices, having null/nil is just a recepie for getting a runtime crash.

Great to see that this moves forward in a steady pace. And being able to compile Rust for Linux seems like a nice milestone, especially since many objections initially against rust in the kernel was about GCC support.

You are free to see this as an ad, but as Rust is targeting safety critical programming in general, I find it interesting to follow certification efforts like this to make rust available for really safety critical use cases. Now, the Ferrocene project is contributing back, but that fact or the license does not really affect the relevance for this community.

Even if it might be fun to see Elon lose money, remember that Starlink is very important to Ukraine to defend themselves against Russia.