There's an age-old struggle between devs and distro packagers. Devs want nice tools to make their lives easy, understandably. Packagers want everything to be the same to make their lives easy, also understandable.
IMO Rust doesn't really replace Java, Go does - and by that I mean it's an approachable language for problems where you're ok with having a GC running in the background. I'm NOT saying that Go has Java's problems, because it really doesn't, it's a pretty nice language overall.
Rust more replaces C++ than anything IMO.
By "grow" I mean new projects emerging that are written in it.
> The Europeans said it needs to have one of these things, but they never said it needed to work. And since we've never met a European who was familiar with the concept of work in general, we just assumed they wouldn't know the difference.
> Yeah, it's got that disease where last week's code doesn't work this week.
That's called idiots using the nightly compiler because Consume Feature And Get Excited For Next Feature.
My oldest Rust code is from 2021 and I do get deprecation warnings on some feature used in some library I forked, but I've never had to change Rust code because of a compiler upgrade.
The situation in C is actually somewhat worse, because every new version the GCC developers roll out some clever new warning. Normally this shouldn't matter, but in reality -Werror does trickle into codebases and then GCC makes an update and code stops compiling.
The other thing GCC devs like to do is invent clever new optimizations which turn undefined behavior that works into undefined behavior that crashes. Insert obligatory smuggy_just_write_valid_c.png, but since All Non-Trivial Code Has Bugs, this does end up being a language change (also, people with bosses and deadlines HATE smuggy_just_write_valid_c.png).
Anyway, I'm not really a language-warrior, I've invested a lot of time in learning Rust so I'm definitely talking my book, but really what I'm trying to say is I think Rust will continue to grow and C will not.
Here's a closer look at what's going on with the modems, there's a 7 port USB hub stuck to the ceiling with sticky-pads, and each modem has a USB-serial cable connected to it's internal UART. When I get a new device, I take it apart and add the USB serial, then I tie a knot in the usb-serial cable so it can't get out, cut a small hole in the case for the cord to run through, and re-assemble the modem. The USB-serial stays with the modem basically forever. This is my tmux shell on Master Of Modems (mommy.cjdns.fr). It can connect to and power cycle any modem.
I've got 4 modems and 3 power wires. I have space and power for up to 16 modems.
To the far left there's a fuse panel connected to a relay block. I'm using the normally-closed terminal so I power a relay to turn a modem OFF, which makes sense because it's meant for a hard reboot.
I severely underestimated the amount of wire I would need, so I only ran 3 lines off of the relay block - I'll clean up those wires when I have all 16 run.
White twist-ties are also temporary until I get another batch of zip ties.
The fuse block has only a single 14 AWG positive going in, but has 18 3 amp fuses. A 14 gauge wire can only carry (max) 20 amps, not 54. I'm not going to pull 3 amps per line, but 2 amps is realistic and that's 36 amps, which is also the max output of the power supply. My main positive and negative lines are 3x 14 gauge wire each, so no problem there, but the fuse block is the Achilles Heel.
The modems are slid into a dish rack, it just happens to be exactly the width of a typical modem...
I agree with you about the COBOL thing, though a big question is what will happen when AI progresses a little more.
> You won't see Rust is embedded
What do you mean by embedded? OpenWRT? It's there because of the python-cryptography dependency. In the kernel, it's optional for now, but as soon as someone starts upstreaming some faster versions of things, it's going to become defacto mandatory.
If you're talking about like 8 bit microcontrollers, sure, but that type of thing doesn't really have much of a future either. Nobody wants to run some special circuit with a vendor SDK based on a patched gcc when they can just use a slightly more complex RISCV circuit and standard tooling.
> almost always inherently memory unsafe
Same argument could be made about the Linux kernel, but it's not, because when everything is dangerous you care even more about tools to help prove correctness.
What's important is that ABI-wise, Rust is basically C. You don't have a VM or a GC or anything sneaking around behind your back and touching things you can't touch, so low level is actually possible.
I spend 50% of my time writing C and 50% writing Rust.
Rust is gonna win.
What's gonna happen is someone will contribute some fast and loose memory management logic that breaks every single rule of safe design, but, uses a pile of Rust type system shenanigans to make the compiler (eventually) prove it correct... And for an extra 5% page fault performance, no one's gonna care that they need rustc to compile the kernel.
After that it's all a big downhill slide...
Hopefully someone will make the compiler faster though.
I've recently had the need to do a little bit of soldering and what I found worked is to: 1. Warm up the pin, but don't try to get it hot enough to melt solder 2. Touch the solder to the iron to create a ball (looks like what you have) 3. Melt the ball and poke it down to try to get it to catch surface tension on the board and switch into a Hershey's Kiss shape
Not claiming to be an expert by any means, just sharing what I recently learned since it's still fresh in my mind.