twhitmore

Bjarne Stroustrup has been pushing Profiles, which would allow C++ code (or the majority of it) to become type-safe and memory safe.

Contracts are useful, but don't guaranteed anything if type safety & memory safety can be bypassed.

I think the ISO panel made the right call. The real world consider memory safety & execution integrity to be critical issues, and C++ no longer to be viable. Without some major improvements -- I would consider this view to be correct.

Contracts are useful, but don't guaranteed anything if type safety & memory safety can be bypassed.

I think the ISO panel made the right call. The real world consider memory safety & execution integrity to already be critical issues (and C++ no longer to be viable), and they are correct. The WG has its priorities wrong.

I tried it on a job I'm applying to, I like it!

Great work guys.

I liked Fable 5, as it didn't gabble like Opus did. It was good at clarity & conciseness.

Fable 5.1 -- to my early impressions -- seems to have gone backwards again.

Opus 4.8 was terrible for babbling self-invented jargon. (But still better than other options at the time for coding and logic.)

Good article, and I agree with the author's enthusiasm.

However his points that "cheap parts are a great enabler" and "shipping costs are high to Trinidad and Tobago", while true, don't actually counter the OP's points that "feature determination needs to be universal" and "the instruction set is poorly designed".

Others have said application authors will code to the specific platform, but that's not true of library authors -- they need portability.

Why can the RISC-V team not get basic stuff like feature determination right? No matter how stupid the rest of the instruction set is, I'm with OP that the responsible individuals should retire from the committee.

A typical place this distinction is useful is that it determines whether the test-suite runs to completion with multiple tests, or panics/terminates hard on the first failure.

Some of it is Conway's Law, much though seems purely "cargo cult engineering" or "FAANG cosplay".

Less-competent devs and CTOs hear that Amazon & Google use it, then decide their 12-person team needs to rewrite their product as 5 separate services. I have encountered companies with 50 services where they needed 5, spending 60% of their dev velocity on overhead.

If you're contemplating microservices & haven't already nailed your business transaction boundaries, reliability mechanisms, idempotence, deployment management/ versioning, observability, testability and the operational discipline to run distributed systems you should just stop -- you have no freaking clue and you're going the wrong way.

Or not. For simple to moderate requirements, plain HTML with a small templating helper is genuinely simpler than React.

React’s complexity isn’t just components — it’s effects, state‑management conventions, data‑loading patterns, and the surrounding build ecosystem. If your UI doesn’t need those abstractions, adopting them early is pure overhead.

For these kinds of projects, React usually carries a much larger total cost than vanilla HTML + JS.

The “vanilla becomes a bespoke framework” claim assumes the UI will inevitably grow until it needs framework‑level abstractions. Most UIs don’t. React front‑loads complexity even when the UI is small, while vanilla only adds what the actual requirements demand.

A few helpers aren’t “reinventing React” — they’re choosing a simpler design avoiding numerous unnecessary abstractions, and with lower costs & complexity for the moderate apps they're building. It's a very valid architectural choice.

Grid layout error in your CSS/ HTML, I think.

You've assigned `grid-area: main` to the content but the parent grid doesn’t define "main" in its grid-template-areas; the browser creates an implicit grid row/column to satisfy the placement, and this ends up being below the defined areas. Thus requiring 1 page blank space to scroll down.

You can investigate the `<div class="main-content">` in Dev Tools by toggling the 'grid-area' CSS attribute off; that fixes the display.

What an incompetence & embarrassment. This seems like a failure of product management, management & executives rather than actual software craftspeople.

Those responsible -- all of the people -- should be promoted to digging ditches.

Does the Zig language not have useful exceptions/stacktraces that can be propagated out?

At a high level, all non-trivial programming is composition. And (see principle of encapsulation) the vast majority of errors shouldn't be recovered and just need to be propagated out.

Then, to be useful, errors need enough information to be diagnosed or investigated. It seems like this should have been a straight-forward requirement in the language design.

Exception handling would be better than what we're seeing here.

The problem is that any non-trivial software is composition, and encapsulation means most errors aren't recoverable.

We just need easy ways to propagate exceptions out to the appropriate reliability boundary, ie. the transaction/ request/ config loading, and fail it sensibly, with an easily diagnosable message and without crashing the whole process.

C# or unchecked Java exceptions are actually fairly close to ideal for this.

The correct paradigm is "prefer throw to catch" -- requiring devs to check every ret-val just created thousands of opportunities for mistakes to be made.

By contrast, a reliable C# or Java version might have just 3 catch clauses and handle errors arising below sensibly without any developer effort.

https://literatejava.com/exceptions/ten-practices-for-perfec...

Interesting to see Rust error handling flunk out in practice.

It may be that forcing handling at every call tends to makes code verbose, and devs insensitized to bad practice. And the diagnostic Rust provided seems pretty garbage.

There is bad practice here too -- config failure manifesting as request failure, lack of failing to safe, unsafe rollout, lack of observability.

Back to language design & error handling. My informed view is that robustness is best when only major reliability boundaries need to be coded.

This the "throw, don't catch" principle with the addition of catches on key reliability boundaries -- typically high-level interactions where you can meaningfully answer a failure.

For example, this system could have a total of three catch clauses "Error Loading Config" which fails to safe, "Error Handling Request" which answers 5xx, and "Socket Error" which closes the HTTP connection.

Checked exceptions were a reasonable idea, but the Java library implementation & use of these was totally wrong.

Checked exceptions work well for occasional major "expectable" failures -- opening a file, making a network connection.

They work extremely poorly when required for ongoing access or use of IO/ network resources, since this forces failures which are rare & impossible to usefully recover from to be explicitly declared/ caught/ rethrown with great verbosity and negative value added.

All non-trivial software is composition, so the idea of calling code "recovering" from a failure is at odds with encapsulation. What we end up with is business logic which can fail anywhere, can't recover anything, yet all middle layers -- not just the outer transaction boundary -- are forced to catch or declare these exceptions.

Requiring these "technical exceptions" to be pervasively handled is thus not just substantially invalid & pointless, but actually leads to serious rates of faulty error-handling. Measured experience in at least a couple of large codebases is that about 5-10% of catch clauses have fucked implementations either losing the cause or (worse) continue execution with null or erroneous results.

https://literatejava.com/exceptions/checked-exceptions-javas...

The examples at the start seem confused & poor. A type that "can return either one result, many results or an error" is trying to fit two different cardinalities into a single API.

APIs should either be typed to be unary (possibly with optionality/ error), or plural (allowing 0..many).

I've dealt with similar woolly design before. Introducing clear distinction between cardinalities gave a major improvement in logical clarity.

Interesting. The corruption was in a math.pow() calculation, representing a compressed filesize prior to a file decompression step.

Compressing data, with the increased information density & greater number of CPU instructions involved, seems obviously to increase the exposure to corruption/ bitflips.

What I did wonder was why compress the filesize as an exponent? One would imagine that representing as a floating-point exponent would take lots of cycles, pretty much as many bits, and have nasty precision inaccuracies at larger sizes.

This article is very interesting. I have previously noticed the contrast between strict state representations, and the messier practicalities of user- and externally-sourced data.

I like the insight of splitting Intent and State. There's a lot to the article & I'm not sure I fully understand the latter half yet, but I'm filing this one away for further exploration.

I don't know, I've met a lot of devs who've found the "true religion" of strict data integrity and have been reluctant to allow for the messier practicalities of user- and externally-sourced data.

None of them called Stanley, but there's definitely a fairly common pattern I recognise.

Difficulty & cost evolving the interface between microservices can seriously hinder improving the actual product.

I've seen the misguided adoption of microservices affect a couple of companies & products.

Yes, there's this amazing thing called "documentation".

Confluence works well if you KISS - write just what the audience needs to know, in terms they can read & find.

Avoid writing grand tracts of wanna-be architecture, policy, theory or planning; just write useful actionable material on topics your audience needs. You will find this works.

Source: I led 400 devs and this was the only way that could scale.

http://literatejava.com/documentation/how-to-write-good-wiki...

Exactly this. At this point the obsession with categorising potentially useful & useable behaviour as UB should be widely acknowledged.

Greed, excess and short-term capitalism.

My particular beef is disposable/ short-lived goods -- the impact on the Earth of a product that lasts for 30 years is far less than one designed to need replacement after 5.

Yet weenie product managers & vulturous MBAs are constantly engineering things weaker & less repairable.

Sometimes to make the unit cost 0.5 cents cheaper, but perhaps more often to force earlier replacement and another revenue opportunity.

Chinese hackers intent on collecting intelligence on the United States gained access to government email accounts, Microsoft disclosed on Tuesday night.

Microsoft said that in all, about 25 organizations, including government agencies, had been compromised by the hacking group, which used forged authentication tokens to get access to individual email accounts.

Perhaps I can share my personal experience. I have always felt tired/ crashed after having sugary foods. Sugary cakes & chocolate can leave me feeling pretty unpleasant. It might have been workable if eating more restored my mental state, but it didn't.

I figured this out in my twenties, stopped eating convenience food with sugar (cookies, sweet crackers, instant noodles, breakfast cereals), and instantly felt better.

I eat a high-protein breakfast of multigrain toast, avocado, cottage cheese, red onion and ham.

When you eat decent food with protein and vegetables you won't have cravings any more for sugary rubbish.

I snack on roast nuts (no peanuts), eat slightly more often and, for a pick-me-up in the afternoon, eat a small sandwich/ piece of sushi/ etc.

I am occasional only with desserts, cakes and ice-cream; typically only after dinner. Quality makes a big difference; quality cakes for example are mainly eggs, butter, chocolate and a bit of sugar whereas cheap cakes are sugar sugar sugar, refined flour and artificial flavours. Protein and fat seem to help stabilize the effects of dietary sugar on my blood sugar levels and mood.

My personal experience, YMMV.

Haven't read the full paper, but several aspects of this sound less than fully reliable.

It reminds me specifically of 90's multi-client LAN database systems (dBase, Clipper) where clients coordinated via file locks. Unreliability & hangs became a big problem for us.

In the summarized RDMA database, I'd be pretty concerned about reliability & integrity:

1) Crashed servers will leave records locked, and the system will hang. 2) Question whether lock timeouts can be adjudicated reliably. 3) Any errors in server behaviour can easily & widely corrupt data across any other nodes. 4) Overall the RDMA coordination makes me cautious. Can we really replace Paxos with RDMA reliably? If not, problems squeeze out elsewhere. 5) Proposed single-threaded recovery procedure sounds a hazardous operational bottleneck. 6) I'm also cautious about coordination requirements around recovery/ or to transact knowing that recovery is not in process, unless we can show that can be reliable & not add cost to the protocol.

Yes. The Archive version seems fine though.

https://web.archive.org/web/20230327033150/https://www.wired...

Behaviour is what needs to despatched, and behaviour is what benefits from applying eg. strategy pattern, delegation, orchestration.

Extracting important business behaviour into objects allows applying OO (ie, powerful despatch rules) where it is valuable.

Subtyping your model to achieve many of these possible usecases would give poor design results.

For example, if payment processing were in Payment.process() the Payment entity would need to be subtyped or composed for any of 1) a different payment gateway, 2) a sales tax in a new jurisdiction, 3) a new confirmation, or 4 a new payment flow. Having all that in your model entity is probably wrong.

Simple behaviour is fine in the model, major business TN usually not.

Limited in size as URLs encounter size limits:

https://stackoverflow.com/a/417184/768795

I wouldn't consider state in the URL fully general, as data can easily exceed that for many apps; but it's a useable technique where it fits.

Meaningful individual parameters are preferable, but similar size limits apply either way.

Cliff Click & John Rose on the JVM's subtype check -- achieving complete subtype checks in only 3 instructions and 1 memory reference, essentially all of the time.

Nice paper for those interested in language implementation & optimization.

My understanding is that radioactive waste volumes & activity differ based on reactor type. Light-water reactors (PWR/ BWR) only burn 3% of the fuel energy hence leaving large energies as mid- and high-level radioactive waste.

Heavy-water reactors such as CANDU can achieve greater burn-up, can avoid enrichment, and even reportedly burn waste from PWRs as fuel. There are downsides but to my mind they seem small.

https://en.m.wikipedia.org/wiki/CANDU_reactor#Fuel_cycle