I fully agree with your sentiment, and it also drives me crazy sometimes.
I wonder if the main problem was all the min maxing interview patterns that rewarded algorithm problem solvers back in the 2010's onwards.
People applied for software engineering jobs because they wanted to play with tech, not because they wanted to solve product problems (which should have a direct correlation with revenue impact)
Then you have the ego boosting blog post era, where everyone wanted to explain how they used Kafka and DDD and functional programming to solve a problem. If you start reading some of those posts, you'll understand that the actual underlying problem was actually not well understood (especially the big picture).
This led the developer down a wild goose chase (willingly), where they end up spending tons of time burning through engineering time, which arguably could be better spent in understanding the domain.
This is not the case for everyone, but the examples are few.
It makes me wonder if the incentives are misaligned, and engineering contributing to revenue ends up not translating to hard cash, promos and bonuses.
In this new AI era, you can see the craftsman style devs going full luddite mode, IMO due to what I've mentioned above. As a craftsman style dev myself. I can only set up the same async job queue pattern that many times. I'm actually enjoying the rubber ducking with the AI more and more. Mostly for digging into the domain and potential approaches for simplification (or even product refinement).
Tbh, I much prefer ORY's API first approach. I looked into Keycloak when I was trying to have a multi-purpose auth server that allowed me to peek into the auth flows.
The sheer complexity of Keycloak's configuration and deployment vs. something like ORY's Hydra was night and day.
And the fact that I could intercept the auth flow through a callback and use their RESTful API to drive it was amazing. No more "package this JAR" and hope that it works. Hydra would run on its own and I don't have to touch it, except when I have to upgrade it.
I believe the difference between ICE degradation and EV degradation is that the EV one actually affects the car's range.
While it is true that your car might consume more oil, and some other component might need replacing, its range, assuming it has been serviced properly, should be similar to what you could get out of it new.
I do wonder if the sum of the costs of getting the ICE car back to mint condition will be the same as getting some cells replaced so you get full range again.
> Are there really enough benefits from uv to justify it as the only option?
The author probably really likes uv, thus the biased instructions.
I also think uv is great, but I wouldn't mention it in the user facing installation instructions. People are used to pip/pipx, thus asking them to install yet another tool might drive potential users away.
Like many other people have pointed out in this post, it is great that you can leverage the platform. All the things you will learn e.g. DOM APIs, native elements and events, etc., are things you can carry over to React and Vue.
However, I believe articles like this fail to acknowledge the contribution React and friends brought to developer experience.
Building complex desktop like UIs was no longer impossible to maintain. You can easily make components and compose them, customise them, etc.
The general complaint is more around "you don't need Next.js" to build a news/marketing/blog website. The pendulum is swinging, especially with things like HTMX gaining traction.
IMO, people do it because:
- It's easier to hire developers that know the framework du jour
- Custom Elements are very flexible, so it's hard to enforce a particular style
- There aren't enough examples of people using vanilla Web Components (and I mean vanilla, not Lit and friends), so why use a web component framework when I can use a react based one?
Write more about how we can combine things like Custom Elements and "traditional" server side templating.
Write more about how a native element reacts to changes to its attributes or how it communicates user interaction and how that helps building a good custom element.
Or how building a good custom element is similar to building a good React component, and where it differs.
Antagonising existing knowledge or even the status quo is not constructive, and leads to poor discussions e.g. "Web Components is a failed technology" or articles like OP
> So when I say that structured concurrency does not suffer from the colored function problem, what I am saying is that callers, and programmers, do not need to care what functions do underneath when they are called
Thanks for clarifying what you meant with your original comment in the article. I completely agree that this is a very big advantage, as opposed to not using structured concurrency.
However, it seems that you are conflating two things with this assertion. For example you say:
> The reason is that, in structured concurrency, when a function spawns a thread, you can expect that that thread is joined before the function returns
While structured concurrency gives you this guarantee, this is orthogonal to whether a function the thread runs is "red" or "blue".
"Red" functions exist in a language because you want blocking to happen on userland so it's cheap to unschedule the task that is blocking.
Structured concurrency doesn't remove "red" functions from a language. They do make the ergonomics of using such functions much easier on the caller e.g. python's trio library [0].
To actually "remove Red functions from the language" you can make the user think they're just using plain "blue" function techniques for blocking.
Go achieves this by only allowing use userland threading.
Java's project Loom [1] achieves this by making common suspension/yielding points (e.g. IO) compatible with both userland and OS threading.
To me, this is what solves the colouring problem i.e. you only have one colour and keep using and writing your code as you always have been.
Structured concurrency, much like you said, is the added bonus that helps reasoning about the lifecycle of tasks a function may or may not spawn.
I don't get the author's conclusion section, especially "structured concurrency does not suffer the colored function problem".
Structured concurrency has nothing to do with function colouring. It is how you organise and spawn tasks, so that you can have certain guarantees e.g. the group responds to cancellation as you'd expect, etc.
I don't see how async/await plays a part in this. You could have structured concurrency with a os threading model, as opposed to a userland threading model.
You can argue that the ergonomics of Zig's async story needs better documentation, especially if you're playing with function pointers. But please don't mislead readers that structured concurrency solves this.
Java as a language is becoming more and more like OCaml.
Once sealed types are introduced, we'll get closer and closer since you already have records and pattern matching.
Obviously, it'll never be the same. Java will always have it's ways of doing things, the community, etc.
I don't know who said it, but it was probably here in HN, where "if you squint very hard, you'll see what Brian et al are trying to accomplish". This was regarding the MLfication of Java.
> The use of TDD, DDD, CQRS and Event Sourcing gives me immense flexibility to be able to refactor a large codebase and then test it through its whole lifespan (with actual data).
What is your experience in applying those principles in a team? It would be very interesting to get some insight on it.