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

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.

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...

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 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...

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.

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.

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.

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

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

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...

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.

Comments URL: https://news.ycombinator.com/item?id=36719412

Points: 4

# Comments: 1

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.

Comments URL: https://news.ycombinator.com/item?id=36692494

Points: 4

# Comments: 3

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.

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.

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

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.