You often just want to go with what’s popular, since hardware vendors will only provide APIs for select languages.

Well, and depending on the field, you may need to get certifications for your toolchain and such, so then you have to use what’s popular.

In my corner of the embedded world, it feels like everyone is practically jumping to integrate Rust. In the sense that vendors which haven’t had to innovate for 10+ years will suddenly publish a Rust API out of the blue. And I’m saying “out of the blue”, but I do also regularly hear from other devs, that they’ve been pestering the vendors to provide a Rust API or even started writing own wrappers for their C APIs.

And while it’s certainly a factor that Rust is good, in my experience they generally just want to get away from C. Even our management is well aware that C is a liability.

I guess, I should add that while I say “jumping”, this is the embedded world where everything moves extremely slowly, so we’re talking about a multi-year jump. In our field, you need to get certifications for your toolchain and code quality, for example, so lots of work is necessary to formalize all of that.

Yeah, particularly the broadcasting really irks me.
That is an opinion you can hold for yourself and then make compromises as you encounter reality. I do expect programmers to hold strong opinions.

But when you broadcast it, you strip yourself of the option to make compromises. You’re just saying something which is going to be wrong in one way or another in most situations. I do expect programmers to be smarter than that.

The problem is that it sounds like a riddle. In a riddle, you’re traditionally supposed to work within the rules that you’ve been told. So, not thinking outside the box here is not an indication that the person isn’t capable of doing so.

Of course, if I encountered this problem in real life, I’d ask Carol from accounting to check the other room, while I flip the switches. But my instinctive answer was that it is not possible, because I assumed it to be a riddle and the provided rules did not allow a solution.

I mean, there is a reason why that is so pervasive. It makes you set up the dev environment and figure out how to run a program, which is a step that you cannot skip.

Of course, you should go for a slightly more complex project afterwards.

To be fair, you can also somewhat steer whether it will take off as a dev, by how you promote it and how much time you take to make it easily usable by others. Many devs really don’t care to have their passion projects take off, because it means you’ll likely spend less time doing your passion thing, more time doing user support.

I almost expected someone to learn that just from me posting. 😅

Basically, OpenOffice used to be organized by Sun Microsystems. Then Sun got bought by Oracle back in 2010.
Oracle does not have a good reputation at all, so the OpenOffice devs from back then figured they’d need to take things into their own hands and set up The Document Foundation to organize further development. But the OpenOffice trademark was owned by Sun/Oracle, so they had to rename and get a new homepage and everything. The name they chose is LibreOffice: https://www.libreoffice.org/

After the OpenOffice project was effectively dead, Oracle handed it and its trademark over to the Apache Foundation, where it’s seeing occasional bug fixes. But to my knowledge, they don’t even have the capacity to fix all the security problems.
All the actual feature development happens over on the LibreOffice side.

So, in practice, if you want OpenOffice, what you really want is LibreOffice.

Yeah, not great. You always hope that projects under a larger foundation, like GNOME, have a higher bus factor¹, but unless that foundation has dispensible income to pay someone, you’re ultimately still reliant on volunteers and not many people volunteer for maintenance.

What the foundation can do, though, which is also really important, is to hand over the keys to a new maintainer, should you disappear over night.
Like, yeah, forking is great, but some people will never learn of the fork. It happens about once a year that I find someone online who’s still using OpenOffice and that project has been practically dead since 2011.
So, I do hope we can get more open-source projects under some sort of umbrella. No idea how to actually do that, though. I also have open-source projects where I would not even know where to start to get them under some organization…

I really don’t agree with saving keypresses being a useful metric, since auto-completion is a thing and code is read significantly more often than it is written. I am also a staunch opponent of abbreviations being used for variable names.

But I will say that I don’t mind abbreviations in keywords, since well, you need to learn the meaning either way.
And yeah, I’ve come to somewhat like them being used for keywords, since it reduces visual noise where it really isn’t useful, and it distinguishes keywords from actual code.
Ultimately, keywords are just syntax where letters were used instead of a symbol. You do read them like a symbol, so if they don’t look like a real word, that seems to work quite well for my brain.

Well, you’d typically put the loops into a function and then do an explicit return to jump out of there. I believe, there’s some use-cases where this isn’t possible, which is why I’m cool with loop labels existing, but I’ve been coding Rust for seven years and have not needed them once…

I’m not sure, what you mean by “Chekhov’s footgun”, but well, it isn’t a footgun, so you won’t accidentally return a wrong value from the function, if that’s what you’re thinking.

It’s not a Rust invention, most functional programming languages have implicit returns, but basically think less of them as a function return and more just as the value that a scope evaluates to.

So, here’s a simple example:

let sum = {
    let x = 5 + 9;
    3 * x
};

Obviously, this is an extremely contrived example, but yeah, as you can see, it does not even have to involve a function. The implicit return makes it so that sum is set to the result from 3 * x.
And the scope-braces are nice here, because you can do intermediate steps without having x in scope for the rest of your function.

In practice, if you see scope-braces and the line at the end does not have a semicolon, then that’s the value that the whole scope evaluates to. Those scope-braces can also be the braces of a function, but then you need to annotate what the function is going to return, too, so it’s practically impossible to return a wrong value.

Well, and I would actually argue that explicit returns are a footgun in comparison.
Because someone might introduce clean-up code at the end of the function and not realize that an explicit return skips that clean-up code, somewhere further up in the function.
The implicit return always has to be at the end of the scope, so it’s not possible to accidentally skip code.

That is, like, genuinely an advantage, though. At $ DAYJOB, we have a project that spans embedded, backend, web frontend and CLI, and for all of these, Rust is decent.

Like, I can see why a frontend dev would want to use HTML+CSS+JS/TS (rather than HTML+CSS+Rust), mainly because the massive ecosystem of JS components makes you more productive.

But you pretty much won’t ever develop a web frontend without an accompanying backend, and then being able to use the same language-expertise, libraries, utility functions and model types, that is also a big boost to productivity, especially if you won’t have a dedicated frontend dev anyways.

Realizing that also made me understand why people subject themselves to NodeJS for their backend, which has the same advantage, just with the big ecosystem in the frontend and the small ecosystem in the backend.

Very interesting, thanks! 🙂

Huh, did that emerge out of unrelated design decisions or did they just figure

I know some of my programs used to have lines with just x.unwrap().unwrap().unwrap() or whatever, which is not pretty.

That goes away with experience, though. At least, I can’t think of a reason why you’d nest three Results or Options. Normally, you would collate them right away.

The most you see in the wild is something like Result<Option<_>> to express that a check can fail, but even if it doesn’t, then a valid result can still be that there is nothing there.

If you don’t care that your program crashes (like .unwrap() does), then anyhow is the error handling library of choice. With it, you can just write a ? in place of an .unwrap() for practically any error type. And well, it automatically combines the errors, so you won’t be writing ??? either.

To be honest, I think, they both have their place. In Rust, you typically wouldn’t return just a bool, but rather the element that you removed, so like this:

fn getofmylawn(lawn: Lawn) -> Option<Teenager> {
    lawn.remove()
}

And then with such a more complex return-type, C-style means that you can’t see the function name right away:

Option<Teenager> getofmylawn(Lawn lawn) {
    return lawn.remove();
}

I also really don’t think, it’s a big deal to move your eyes to the ->…

Yeah, I was gonna say, error handling easily makes up 80+% of the code paths, and depending on whether you’re building a library or service or script etc., different strategies are most suitable for how to deal with those code paths.

In a script, you often just want it to crash. In a library, you want to make these code paths matchable, in case the user cares why something failed. And then you have the awkward in-between, which is that 99% of your application codebase will be used by your main-function like a library, but you don’t want to spend as much effort on error handling for that as a proper library does, in particular also because you know what all consumers of your application-library need to know.

So, it’s kind of multiple different problems, with overlap, and people are hoping for one easy solution to cover all these problems.

Yeah, like YAML, which’s name originally meant "Yet Another Markup Language*.

Then they redubbed it to mean “YAML Ain’t Markup Language”, because well, it isn’t actually a markup language. 🫠

https://en.wikipedia.org/wiki/YAML#History_and_name

I’m on NixOS for my personal laptop, too. I just tried it and well, #!/bin/bash apparently does not work, but #!/bin/sh does.

The file /bin/sh does also exist as a symlink for me:

> ls -l /bin/sh
lrwxrwxrwx 1 root root 73 14. Dez 19:50 /bin/sh -> /nix/store/35yc81pz0q5yba14lxhn5r3jx5yg6c3l-bash-interactive-5.3p3/bin/sh*

Does that point into the bash package for you, too?

Edit: And for #!/bin/bash, the output was:

> ./test
exec: Failed to execute process './test': The file specified the interpreter '/bin/bash', which is not an executable command.

That is definitely not right. That sounds like you don’t have a shebang or it isn’t defined correctly. The shebang has to be the very first thing in the script, with no whitespace before it. It gets read out by the kernel, which very dumbly checks the first few bytes.

And well, such a shebang should also work for Python or the like. If you copy the first script in this link into a file script.py, then run chmod +x script.py and finally run ./script.py, does that print Hello, World! ?