Rust has managed to establish itself as a player, but it’s only the best choice for a limited amount of projects, like some (but not all) browser code or kernel code. Go, C++, C with Fil-C) have solid advantages of their own.

To name two:

* idiomatic code is easier to write in any of these languages compared to Rust, because one can shortcut thinking about ownership. Rust idiomatic code requires it.

* less effort needed to protect from supply-chain attacks

First you need to figure out if it’s a surface infestation because of condensation or if it’s a constructive thermal bridge. The latter can be solved by raising the surface (wall, ceiling, etc) temperature through insulation or more inefficiently special heaters designed for this purpose.

In both cases, the contaminated material is removed down to the plaster or masonry. Wood, wallpaper and similar materials will likely be deeply contaminated and must be removed. For areas larger than 1 sq meter, it’s better to get a specialized contractor which will use HEPA vacuum cleaners, special bags, etc to ensure that the mould spores don’t spread in other rooms.

For small areas the agents of choice are bleach or hydrogen peroxide, both available in products for home use.

Back then there was also a nice ~$15 program called Net Limiter which allowed one to cap network speeds individually per program.

From Android to whatever web framework they’re peddling as development solutions, these are not designed for efficiency, but for time-to-market and consumption by front-end developers.

It was a matter of having access to the right (although limited) resources such as Petzold’s book, Codeproject and experimentation. There was no big rush, no start-up hustler mentality and most importantly hardware resources mattered a lot and it was a point of pride to create efficient software.

The development culture of present time is the opposite of that: developers are drowning in documentation, the default solution is technically inferior and the hustler mentality’s dominating.

Using win32 from Rust is nonsensical. This is the kind of use-one-tool-for-any-job Visual Basic 6 programmers used to have, except VB6 would have actually been much better than Rust at Windows programming.

Of course, if one is a web developer, even attempting such a feat this could result in a brain-melting experience.

There’s absolutely no consensus that the legal definition is met, in contrast with another ongoing situation which enjoys wide recognition.

It feels that this is more a geopolitical cudgel, pulled out when the discourse against the US becomes negative. But given the events in the last years, this seems like a lost cause even in the West, never-mind the rest of the world.

We’re at the point where a solid test suite and a high-quality agent can achieve impressive results in the hands of a competent coder. Yes, it will still screw up, needs careful human review and steering, etc, but there is a tangible productivity improvement. I don’t think it makes sense putting numbers on it, but for many tasks, it looks like there’s a tangible benefit.

Rust syntax is a PITA and investing a lot of effort in the language doesn’t seem worth the trouble for an experienced C++ developer, but with AI learning, porting and maintenance all become more accessible. It’s possible to integrate Rust in an existing codebase or write subparts of larger C++ projects in Rust where it makes sense.

I was recently involved in an AI porting effort, but using different languages and the results were fine. Validating and reviewing the code took longer than writing it.

Many customers really only care about price and that it generally works and looks fine and have zero idea about the hidden costs.

* all services are run at a loss and they increase price to the point the corp doesn’t want to pay for everyone any more.

* it turns out that our chats are used for corporate espionage and the corps get spooked and cut access

* some dispute between EU and US happens and they cut our access.

The solution’s having EU and local models.

This and the Google blogs offer zero technical insights and I haven’t learned anything from any of them.

Not only can AIs help, but they can write most if not all the code and spare the human from learning all the intricacies of individual programming languages. Problem is, reports are contradictory on compatibility with Rust. We know they work great with simpler/friendlier languages like Go or Python.

The interesting aspects, such as how they protect against supply-chain attacks from the dependency-happy rust toolchain or how they integrated the C++ code with the Rust code on so many platforms - a top challenge as they said - remain a mystery.

Would also be interesting to hear how much AI-driven development they used for this project. My hope’s that AI gets really good at Rust so one doesn’t have to directly interact with the unergonomic syntax.

European companies are trying even harder to outsource to China.

In the past months I’ve seen an increase and it feels like almost everything is made in China, from books to Christmas trinkets to clothes and kitchen utensils, it’s a pain the ass to find locally produced goods.

This has a lot to do with the energy crisis triggered by decoupling from Russia, which was never properly put into context and evaluated from an economical perspective.

Massive projects like Qt also push compilers to their limits and use various compiler-specific and platform-specific techniques which might appear as bugs to Fil-C.

For many years, all the projects I’ve been in had mandatory code review, some in the form of PRs (a github fabrication), most as review requests in other tooling.

This applies to everything from platform code, configuration, tooling to production software.

Inside a component, we use review to share knowledge about how something was implemented and reach consensus on the implementation details. Depending on developer skill level, this catches style, design issues or even bugs. For skilled developers, it’s usually comments on code-to-architecture mismatches, understandability, etc. Sometimes not entirely objective things, that nevertheless contribute to developing and maintaining a team consensus and style. Discussions also happen outside and before review, but we’ve found reviews invaluable.

If a team has yearly turnover or different skill levels (typical for most teams), not reviewing every commit is sloppy. Which has an additional meaning now with AI slop :)