For Zulip there are some public instances to look around if you don’t know it, like https://rust-lang.zulipchat.com/

There are some specialized tools if you only need video chat (like good old Jitsi but I think there are some more modern options now based on LiveKit) and there is one centered around a shared whiteboard / slide-sharing area (forgot the name). Or if you’re looking to just quickly do some collaborative editing there is CryptPad.

Also, check out the [email protected] community here if you still have questions.

New engineers shouldn’t just learn how to prompt. […] The signal that an agent is bullshitting you is a learnable skill, and right now we’re mostly learning it by accident.

No. Education should focus on basics that are likely to remain relevant. The biggest signal that something will remain relevant is that it has been relevant for more than a decade already. Laws of physics, the PID control loop, what is a register, what is a LRU cache, asymmetric cryptography. Failure mode effect analysis, stuff like that. LLM prompting is very new. Better learn about big-O notation first, or you’ll never realize that the LLM went off rails. They didn’t teach you the latest Javascript framework at University either.

A simulator for engineers. This is the one I haven’t seen anyone build, and I think there’s a real gap.

We are having big fun with those.

A simulator for engineers.

You haven’t played Factorio, have you? ;-)

[A simulator for] debugging unfamiliar production-like code, reasoning about state in a real system, recovering from a nasty incident without help. Someone should build that. (Hit me up if you already are. I would be very eager to try this.)

You probably have been building mostly new software, and not yet had the pleasure to maintain something that was built two decades ago by a team that isn’t around anymore to maintain it. There is a big market for the skill to work on high-value legacy systems without breaking them. This kind of work that you don’t see in the hyped blog posts. (Or if you do, it will have “post-mortem” in the title. In fact, you have succeeded if your work on those system never makes it to the news.)

(Edit: The problem is not building this simulator. The problem is finding both the budget and the cruelty to beat an engineer into analyzing a legacy system that is currently working as it should. At the end of the day they are frustrated not having done anything, and the company has spent money with no tangible result. I guess we really could learn something from aviation - this kind of “getting intimate with the system” for its own sake just isn’t valued.)

It’s cute how they think they can control every technology by controlling commercial sales. And this after 3D printing started as this huge RepRap movement where everybody and their friend built their 3D printer from online instructions and rollerblade bearings.

Up next: when buy a 3D printer kit, you have to agree to only flash the unmodified firmware on your Arduino, and not one of the forks from Github. And you are no longer allowed to create your own hardware at home, or tinker with electronics of any kind, or publish instruction how to make your own electronics. And after that, you now need to register yourself before you can use a debugger.

The authenticated encryption of HTTPS similarly protects the CDN-based web clock approach. This avoids situations where an attacker-in-the-middle tampers with insecure NTP responses, messing up your system’s clock.

Almost… there is this fun thing called a delay attack that works despite encryption! (I’ll admit that it’s probably not a practical concern.)

Anyway, the article talks about time measurements through an absurd amount of abstraction layers. Please don’t ever call this “simple” or even “cloud-native time” or the like.

If you start trying to improve this setup you’ll find so many face-palm moments. Like TCP retransmissions (which the article mentions, to be fair). You’d have to use WebRTC to avoid that, which I bet the CDN network doesn’t support. Or the fact that web browser timers have intentionally reduced precision to resist fingerprinting. (Granted, if you are still in the milliseconds range it is not a problem.)

Check out the “tyranny of the rocket equation”.

Or ask Randall Munroe How many model rocket engines would it take to launch a real rocket into space?

Reminds me of this Calvin and Hobbes comic about ethics :)

Do not go gentle into that good night,
Old age should burn and rave at close of day;
Rage, rage against the dying of the light.

Interstellar (2014) - Scene that quotes the poem. Now this is where you go for proper theatrical drama.

You don’t have to live with the developers. You don’t examine Google or Apple with that kind of scrutiny either, as a user. In fact you can’t, because Google and Apple developers have NDAs and PR to prevent any internal human drama from leaking to the public. Doesn’t mean there is less of it.

With community-driven open source projects, almost everything happens in public, so you can dig up all that, and drama gets amplified through social media. If you want the illusion of something free of imperfect humans, better stick to the corporate stuff, I guess.

Yes. Not going to happen. The next best thing would be to shorten copyright protection to 10 years. (Also not going to happen, but easier to convince people that we should try this.)

You obviously want WTFPL instead of MIT for that.

Maybe my LLM detector needs an update, but only the headline triggered it. The article did the opposite for me.

Anyway, the author checks out, old github profile etc. Works in high frequency trading, which I despise because I think it is make-do work, moving money around a millisecond before anyone else has a chance, a huge technical effort with zero benefit to society compared to slower trading. I’ll file it together with adtech and bitcoin. But. The article is not about that. And I know that working in high frequency trading sure makes you qualified to talk C++ or FPGAs or anything close-to-the-metal. So, author background checks out. Verdict: not slop.

I feel old now. I can almost hear the noise of the drive trying to chew on this one.

Anyway, have some on-theme music video: BAD SECTOR by unfa (youtube.com)

The title is clickbait, but the article is well written.

It is tearing apart some points made in a talk (which I didn’t watch). The talk seems to focus on C++26 features (given that you are using C++) while the article argues why you still shouldn’t use C++ in the first place, despite the improvements. Mainly because the memory safety features are opt-in. There is also discussion about the CrowdStrike incident, and how it was more of a cultural problem than a language problem.

Yes but despite the footguns, C (not C++) is a relatively small language, not too hard to learn. And it’s the glue between kernel, system libraries, and all other languages. You don’t want to write big applications in it any more, but it’s still useful to know when you interface with existing stuff.

Depends. I would flag it in a code review on our product, and same for most TODO comments. It’s bad practice to leave them for your team to deal with, or even for yourself two years later.

But for explorative coding (mostly just one person, things like game development or creative coding, or before finishing your branch) I think dead code warnings do more damage than they help. They make you look at things not worth looking at right now, until you figured out what you want to build. Like unused structs or imports just because you commented out some line to test something. I didn’t turn all annoyances off, but I feel I should. I have a hard time just ignoring them. I think it’s better to enable them later when the code is stabilizing, to clean up experiments that didn’t work out. When I just ignore them I also ignore a more important warnings, and waste time wondering why my stuff isn’t working while the compiler is actually telling me why.

Also, in Rust many clippy defaults are too pedantic IMO, so I turn them off for good. Here is what I currently use:

[lints.rust]  
dead_code = "allow"  

[lints.clippy]  
new_without_default = "allow"  
match_like_matches_macro = "allow"  
manual_range_patterns = "allow"  
comparison_chain = "allow"  
collapsible_if = "allow"  
collapsible_else_if = "allow"  
let_and_return = "allow"  
identity_op = "allow"  # I'll multiply by one whenever I like!  
# Just disable all style hints?  
# style = "allow"  

I found it interesting that key travel time was considered, often it isn’t.

A similarly interesting article: Measure and reduce keyboard input latency with QMK on the Kinesis Advantage (2021) (Basically, took an existing keyboard and replaced the controller.)

If you are here to learn something about Javascript, read the MDN article about the “Number” type instead.

Yes, I like it. It makes only one (big) mistake: a horizontal table-of-contents. Nobody does that. You can put it on the left, or above the text, but… not like that.

This is great fun, but maybe solar panels are too cheap for this now?

Concerning fun, check out the solar sinter project! (vimeo.com, 6min)

Uh, so far scientific predictions about the climate from even 20 years ago have been quite accurate, or a bit too optimistic. The scary predictions are for 50 to 200 years in the future and later. It’s just a very slow process (in human terms). Put CO2 into the atmosphere for a decade, not much happens. Put more CO2 in for another decade, it gets slightly warmer. Stop putting CO2 into the atmosphere, and the CO2 stays there for many hundred years, and the effects keep getting worse.

By the time you notice the bad stuff happening around you (desertification of farmland, floods, sea-level rise in coastal settlements), it’s too late to realize that you don’t have a technology to put the CO2 out again, and even if you did it would take another decade until you notice the effect.