cold take speculation: the architecture astronautics of the Java era probably destroyed a lot of the desire for better abstractions and thinking over copy-pasting, minimalism and open standards
hot take speculation: we base a lot of our work on open source software and libraries, but a lot of that software is cheaply made, or made for the needs of a company that happens to open-source it. the pull of the low-quality "standardized" open source foundations is preventing further progress.
Has anyone measured whether doing things with AI leads to any learning? One way to do this is to measure whether subsequent related tasks have improvements in time-to-functional-results with and without AI, as % improvement. Additionally two more datapoints can be taken: with-ai -> without-ai, and without-ai -> with-ai
Great article. Really advances the thinking on error handling. Rust already has a head start compared to most other languages with Result, expect and anyhow (well, color_eyre and tracing), but there was indeed a missing piece tying together error handling "actionability" with "better than stack trace" context for the programmer.
With regards to context for the programmer, I still think ultimately tracing and color_eyre (see https://docs.rs/color-eyre/latest/color_eyre/) form a good-enough pair for service style applications, with tracing providing the missing additional context. But its nice to see a simpler approach to actionability.
IMO you need both things: culture to make it happen, and technology to make it easy and reasonable looking. Rust lacks the former to some degree; Go lacks the later to some degree (see e.g. kustomize error formatting - everything ends up on a single line)
I don't think there is anything in Go (the language) that helps achieve this - its mostly cultural. (Go creators and community being very outspoken about handling errors).
In fact, the easiest thing to do in Go is to ignore the error; the next easiest is to early-return the same error with no additional context.
It does expect you to use `wrap_err` to get the benefits, though. Which is easier to do than what Go requires you to do for good contextual errors, and even easier if you want reasonable-looking formatting from the Go version.
I wonder if it would've felt more natural if the "part 2s" of the puzzles became separate days instead. (Still 12 days worth of puzzles, but spread out across 24 days, with maybe one extra, smaller, easier puzzle for the last day to relax)
I don't think thats contrary to the article's claim: the current tools are so bad and tedious to use for repetitive work that AI is helpful with a huge amount of it.
Is that the modern Java equivalent of the single-method interface in Go? I can see its an abstract class - what do you do if you want to implement both Reader and Writer?
- compiling to a single binary (I guess jpackage fixes this)
- saner / less elaborate / more ergonomic interfaces to implement and use e.g. compare `io.Reader` (https://go.dev/tour/methods/21) to the Java equivalent
I like the story, but I think people will notice pretty quickly as almost everyone reviews their photos right after taking them (so they can compare them with what they see in reality)
Can we amend the protocol to allow the exchange of various settings, such as "desired DPI / scaling"
edit: looks like it might already be provided via wl_output::scale [1] except you get the wrong effect that way. You want to tell the client what DPI they should render at, so that you can keep scaling at = 1
No, its not a programming problem, its a herding problem. That person will have to have the ability to get all 3 implementations to agree to read and write compositing configuration the same way, so users don't have to suffer.
YMMW but I find it fast enough to maintain focus on one task (if that's what you're going for given a particular problem