lpedrosa's comments

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.

Then you don't go "off the beaten path" and instead stick to the tourist friendly places.

Demanding the locals to accommodate your lazyness is basically shouting "I'm entitled".

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

The usual pip or pipx command should work fine. It's listed on PyPI: https://pypi.org/project/Bagels

I would only mention uv in the Development Setup section (https://github.com/EnhancedJax/Bagels?tab=readme-ov-file#dev...)

> This feature of web components encourages a design of composability.

I am not a React, Vue (and friends dev) at all. Heck, I haven't done front-end or full stack for a long time now.

However, taking React as an example, where does it not encourage composability?

I like Web Components. I even spent the last couple of weeks playing only with the vanilla APIs (no Lit, etc.) just to see what is like:

https://lpedrosa.github.io/blog/web-components-part-3/

https://github.com/lpedrosa/webcomponents-blog-examples

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

You are correct. You don't have to use the shadow DOM, when you create a new Custom Element.

The shadow DOM provides two things:

- style encapsulation (as well as `id` attributes)

- ability to use `<slot>` for templating

You should use it if you require one of the above or both.

What if doing dozens of REST calls is effectively the product?

I think there was something like a package manager.

Tbh, I wish we lived in an alternative reality where SML won over JS and we had it running on every major browser.

This is great. I wanted to create something like this for quite some time! I definitely try it.

Well done!

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

[0] - https://trio.readthedocs.io/en/stable/index.html

[1] - https://wiki.openjdk.java.net/display/loom/Main

(edit note: my phone messed up quoting)

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.

This is pretty cool. Any plans for releasing a blog post about building the game, or even the source?

Try turning on the mouselook. I think the key for that is '\' or something. Check the controls