HackerTrans
TopNewTrendsCommentsPastAskShowJobs

twhitmore

286 karmajoined hace 7 años

comments

twhitmore
·hace 5 días·discuss
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.
twhitmore
·hace 5 días·discuss
[flagged]
twhitmore
·el mes pasado·discuss
[dead]
twhitmore
·hace 2 meses·discuss
[flagged]
twhitmore
·hace 2 meses·discuss
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.
twhitmore
·hace 2 meses·discuss
[flagged]
twhitmore
·hace 5 meses·discuss
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.
twhitmore
·hace 8 meses·discuss
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...
twhitmore
·hace 8 meses·discuss
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.