This is based on the assumption that switching between operators/providers is quick and straight-forward. The reality of switching is that it is extremely time-consuming and emotionally-draining. These corporate practices should not be a thing, but the providers know that this hurts their profit-margins, so they "choose" to make very difficult.
As someone who is a victim of never feeling he has done enough, I totally empathise with this blog post. The incentives which got me into tech were completely intrinsic and altruistic. Over time, I have felt them warp into something which can be best as "capitalist greed", everything is now about wanting more. The first and perhaps the easiest, thing to be sacrificed at the altar of wanting more, is mental health and relationships. Thankfully, I'm conscious of this now and is something I actively work on.
However, this is something I can only do at this point in my life, in my early 20s I was much more of a grind person and even if I could change things I wouldn't change that.
Most people in software misunderstand how physical goods work. When making machines you don't care about getting everything perfect all the time, you care about staying within tolerable limits all the time.
How bad do the folds in your laundry need to be for them to be no different then just being dumped in a pile? As long as we are above that point the robot is useful.
I think there is a stark contrast between the plus or minus micron level tolerances, and whatever is being churned out of LLM ('not getting it perfect all the time')
this is what excites me most about the probable AI future. househelp is cheaply and easily accessible for most people in the east, however being able to afford a cleaner or maid in the west is a luxury. i spent a ginormous amounts of time every week keeping my house in shape. i look forward to the day when i will be able to carve out that time and get it back for myself.
Househelp isn't cheaply and easily accessible for most people in the east, a large portion of people in the east is just poor but you don't consider them in 'most people'.
it seems absurd that they would reject a plain and simple name? i imagined company names would be available on first come, first serve basis. why is that not the case?
While I agree with your point in general, rewriting a big widely used project in a stricter language is always a good thing. It improves the dev-ex of people contributing to these projects and more importantly helps people seperate logic into silos. Python is inherently limited in which kinds of abstraction it can express.
In an open source tool, there is no value without community of contributors.
The value of the discussed project is exactly zero right now in the best-case scenario.
It's more likely to be negative: because there has been no contact with reality (no users have used it in production), the risk is higher than using the existing one.
IOW,
1. Only after some brave souls use this in production, will the value of this project rise to zero.
2. Only after a community (could even just be a single person) demonstrates commitment to this project will it have a non-zero positive value.
Since it was done primarily by someone who was never part of the original community, and they have yet to demonstrate a commitment to maintenance, there is no value to this project.
> While I agree with your point in general, rewriting a big widely used project in a stricter language is always a good thing.
Assuming everything else stays the same, sure. But everything else is not the same - there is no community, no commitment to maintenance, high risk and, worst of all, no human involvement. This project has negative value now due to the risk.
> It improves the dev-ex of people contributing to these projects
What contributors? There are none, and there are unlikely to be any for the majority of the new repos created like this.
Improving the devex of zero contributors improves exactly nothing.
> Python is inherently limited in which kinds of abstraction it can express.
Sure, but successful projects require committed humans. This has none.
> surely you aren't calling binary releases of binutils 'projects'? why would you call this thing a 'project' in the sense you're using?
Because you called it a good thing using my definition of project:
>>> It improves the dev-ex of people contributing to these projects
If this is supposed to be a "Product of the compilation process only", then sure, but if so, what devex of the contributors exist?
If you want to shift to regarding this as analogous to the binary releases of binutils, then the devex of contributors doesn't matter, because the contributors to binutils aren't binary-patching files.
> rewriting a big widely used project in a stricter language is always a good thing
Always might be a too strong word. Rust is, by design, a language with low development velocity.
So you risk:
1. ossification of the current architecture and deferment of important features; or
2. reliance on AI coding to recover velocity.
Maybe for some 2 does not look like a risk, but I think it's too early to call. We have yet to see the effects of extensively using these tools on large scale projects, for years and decades.
