RVA23 is pretty nice. This is the first RISC-V profile that's really viable for desktop class CPUs. (But I still wouldn't buy a RISC-V chip expecting to run Linux on it until they have proper support for UEFI, ACPI, etc. and "unified discover" is specified, which won't be for probably 3-5 years.)

The documentation looks excellent!

I'm definitely going to try this for my next PCB project. I've tried basically all of the other free options (Designspark PCB, Eagle, Kicad, Geda, Horizon) and Horizon is the only one really worth using IMO (Designspark PCB is also decent).

Eagle and Geda are trash. Don't waste your time.

Kicad should be great, but they've made a number of insane UX decisions that make it really unusable in practice. Horizon is actually based on the pretty good Kicad engine but it fixes most of the UX mess.

bash scripting is not intended to perform all of your logic in the scripting language

Maybe not all, but it's definitely intended to do some, and it's really bad at it.

Since when are contractors lower pay? Companies waste fortunes on them.

They don't need to support Windows 10, they just need to not artificially block the installation of Windows 11 on old hardware.

I feel like they could ask way more interesting questions. Probably the only really interesting thing here is people's top complaints about Rust, which is to be fair a really great list.

I would really love to see something similar for other languages. Imagine if you could see ranked pros and cons for every language!

Git has four build systems?? Meson seems overkill if you already have CMake too. The only thing it really adds is that it's nicer to write (CMake is somewhere between Bash and PHP in sanity), but if you have to write CMake anyway...

Some suggestions:

1. Declare input in the loop. That limits scope which is basically always a good idea.
2. Trim the newline like

let input = input.trim();

This is better in several ways:

1. Simpler
2. Doesn't allocate a new string.
3. Removes all whitespace at the start and end.
4. It makes input immutable after that line.

Also attempts is never read - you should have got a compiler warning about that.

Otherwise, good work.

They seem exactly the same to me: when a variable is assigned a value, it’s equal to that value now.

Yeah it's confusing because in maths they are the same and use the same symbol but they are 100% not the same in programming, yet they confusingly used the same symbol. In fact they even used the mathematical equality symbol (=) for the thing that is least like equality (i.e. assignment).

To be fair not all languages made that mistake. There are a fair few where assignment is like

x := 20

Or

x <- 20

which is probably the most logical option because it really conveys the "store 20 in x" meaning.

Anyway on to your actual question... They definitely aren't the same in programming. Probably the simplest way to think of it is that assignment is a command: make these things equal! and equality is a question: are these things equal?

So for example equality will never mutate it's arguments. x == y will never change x or y because you're just asking "are they equal?". The value of that equality expression is a bool (true or false) so you can do something like:

a = (x == y)

x == y asks if they are equal and becomes a bool with the answer, and then the = stores that answer inside a.

In contrast = always mutates something. You can do this:

a = 3
a = 4
print(a)

And it will print 4. If you do this:

a = 3
a == 4
print(a)

It will (if the language doesn't complain at you for this mistake) print 3 because the == doesn't actually change a.

uv is a drop-in replacement for pip. There's no extra standard. It's pareto better. Honestly the Python community would do the world a favour if the deprecated pip and adopted uv as the official tool, but you can guess how likely that is...

What would you use instead?

I've been working on some OCaml code recently. It's a quite elegant language but it has two or three big flaws that really make me not want to write it.

1. OPAM is buggy as hell. There's one piece of OCaml software that we use at work and literally everyone that tried to build it had problems due to OPAM. One was that it couldn't find zip if you are in more than 32 groups!? I don't even want to think about the kind of code that could lead to that bug. And this is on Linux! Have you tried installing OCaml on Windows? Yeesh.

2. Global type inference means loads of types are inferred as generics, which means you give up a lot of the utility of static typing. Yes you can add explicit types, but the code I'm working on doesn't have them. Rust was 100% right to require explicit types on functions.

3. The syntax is pretty awful in my opinion. Yeah I guess it looks elegant and I'm sure whoever came up with it was very proud, but honestly maybe 40% of my time fighting OCaml has been spent figuring out where to place the damn brackets and semicolons. It's extremely unforgiving too. E.g. if you put an extra semicolon on a top level let where you weren't meant to it can sometimes be "valid" but it pulls the rest of the file into an inner scope, which means the compiler gives you a valid but wrong fix suggestion. Languages using curly brackets don't have this issue at all.

The lack of brackets for function calls can also make it difficult to work out what's going on because you have another operator precedence to remember. Have trouble remembering which is higher precedence out of & and ==? Well now we've thrown calling functions into the mix for you to forget too!

Finally the functional focus can lead to mega-expressions that are very hard to follow, especially when combined with the lack of brackets it can end up looking like word soup.

OCaml has a ton of really nice ideas but I'm glad it's just inspiration for better languages (e.g. Rust) rather than actually popular. I mean... it's still a million miles better than Python... But that's a low bar.