Why is it that the derisive "oh you just disagree" statement usually speaks to a missing "...and therefore aren't serious"?
What are you actually saying constructively here, if anything at all? I, for one, happen to agree that fundamental reform is clearly necessary. What that looks like exactly is where I'm sure the problems lie.
Assuming my residence due to my nationality? Bad idea. Incredibly, in this day and age, people may be born in one country and live in another! Who would have thought, eh?
> That the vast majority of people that "want reform" actually just want a Supreme Court whose majority always sides with them.
That you immediately go here in response to what are universally understood these days as incorrectly decided cases (Plessy in particular) shows incredibly bad faith on your part. Good day to you sir.
When it is not the mandated option, under what circumstances is Windows the best choice for software dev? The only domain I can think of is gaming, and Valve is seemingly coming up fast to eat Microsoft's lunch in the next few years.
As mentioned: gaming, most of enterprise dev, graphics/gpu/cad, desktop, certain classes of embedded. Broadly speaking, outside of hacker/web/creative culture, the default is windows.
Regardless of how evil gigantic companies can be, or what the ideal world should look like: from a pure usability perspective, windows is top of the list.
If I got 5$ every time a linux/mac enthousiasts has to tell me they just cannot run something, and proposing a myriad of workarounds to stick to their ideology, I could buy an apple vision pro and let it collect dust in the corner of my basement.
No disagreements on things not working right on Mac/Linux, it's definitely a frustration!
I would argue against the idea that it's the default for most enterprise dev. What you refer to as creative/web culture I would refer to as a newer generation of enterprise dev written in (I know) JS, TS, Electron etc. There is a lot of cross platform stuff out there, at least for clients, and Linux has taken up a lot of ground in the server market as well.
With CAD and GPU programming you have a point - proprietary drivers written for Windows has more technical sticking power.
I guess my feeling is that, especially with all the headlines saying European countries will move away from American software giants, Windows seems less attractive as a long term target for investing my time. Not to mention it's buggy and slow these days.
True, I hate windows like most people. I just also hate being unrealistic about it. Good thing about AI is you no longer really have to care about really understanding the OS, unless you are an admin.
Valve is certainly increasing the viability of Linux as a platform for gaming, but I can't see developers targeting Wine or Linux for a major game over Windows directly. Not for a decade, if ever.
Wow. Only enough reserves to be measured in decades? Once it's gone it's gone. Genuine Carboniferous coal, one day a thousand years from now, might be a rare museum item!
I have a habit of thinking about history in very long terms, and that just does not sit right with me. That kind of thinking (oh we have enough for decades, let it rip!) happens, and the decades pass, and time inevitably is less kind to the descendants of such decision makers.
Also, this means that if we let MBAs destroy this civilization, there won’t be any future advanced civilizations as we will have consumed all the easily usable resources they will need to jumpstart their technology tree from zero again. Even if the knowledge survives it could be useless
growing up (in the 70s/80s), the first time I was shocked at the exponential destructiveness of human civilisation was when I learnt that we had polluted the oceans. the second was when I found out that ubiquitous natural resources like oil could be completely consumed. I feel like either one would have been unthinkable even as late as 1900.
(incidentally the latest such shock was sometime this decade when I learnt that an aquifer could not only be depleted, but that that depletion would compact the soil so that it would thereafter be unable to hold water, and thus never (at least on our timescales) be able to be replenished. I think I'm still not over that!)
There is an interesting passage in Moby Dick where they talk about whether whaling could make whales go extinct, but the concern is brushed away as human hubris. How could humans completely destroy something that God created?
From the point of view of energy. The conversion of solar energy into coal is very inefficient, tree need energy to reproduce, only a part of plant is converted into coal, other organisms consuming plant matter, etc.
I don't know, that just seems like a category error that breaks apart when you get closer to any individual project. Use-after-free is still possible in Rust with unsafe. Assuming nobody _can_ write memory safe C is a good assumption for things like security modelling, regardless of how unlikely those issues actually come up.
Securing code you/your org did not write and programming for yourself/your org are just fundamentally different jobs.
It is absolutely possible, but all of the data we currently have shows that reducing the amount of code that could possibly have the error has meaningful effects on the number of vulnerabilities. Mitigation may not be the same as elimination, but it is effective.
> Use-after-free is still possible in Rust with unsafe
Of course! But in practice all potential bugs are neatly wrapped in small and easy-to-audit "unsafe" blocks, rather than silently lurking all over your codebase.
You could indeed wrap your entire codebase into one giant unsafe statement and write it like C. But, as the actix-web discussion showed years ago, the Rust community very much prefers restricting unsafe to the absolute bare minimum possible. You wouldn't write, say, a mail server in mostly-unsafe Rust for the same reason that you wouldn't write it in mostly-inline-assembly: you gain nothing, and in return it'll probably blow up in your face sooner rather than later.
Rust has an escape hatch because we're all adults. The big difference is that its footgun has an explicit safety latch, so you have to deliberately opt in to blowing your own foot off.
This I think is a medium-term path/window only. Eventually the low hanging fruit of "whatever we can do a small release quickly to get $1M ARR" will be relatively picked clean. Sort of like how the App Store boom had things like flashlight apps make a large number of sales, when realistically it made the most sense for it to be a first-party application.
With AI tooling, I think things like "quickly generated dashboard" will fall under this category, which is unfortunate because the only way to tell a well-thought UI from a poorly thought out one is by using it a lot. I suspect we are going to see a wave (already seeing really) of people launching small companies with barely functional products, which will burn user trust (low bar for software already).
For startups, this means the AI-code gold rush may ebb and most users will flock to larger corporate products that "just work". In this way, it follows the VC's with the most money to burn will be able to stay competitive after a few years of drought.
What I'm really interested in that this time they'll need to compete not just with each other, but with other institutions (assuming the software engineer's market rate stabilizes). It's not the 1990's anymore, every business and government knows how valuable software is (even if they don't have experience making it). How will they adapt the lower barrier to entry allowed by AI tools?
On the one hand, sad day for the rest and vest crowd, as well as founders. On the other hand, wouldn't it be interesting to see university or government managed Linux distros?
Do you utilize RSS? I've been trying to find a good RSS reader that incorporates some of the ideas his advocates, but I prefer Linux. Right now I'm using Thunderbird for it, but I'd love a good recommendation!
This is unfortunately a feeling I share. It wasn't until LLMs have become nearly ubiquitous at this point, and there has been zero realistic technological response to the dangers they present. Not to mention I suspect there may be some psychological element to being exposed to interactions with AI models and their nonsense for hours a day. Not all of it is nonsense....but you won't ever know for sure.
Academically, is it a bad thing companies are selling phones preinstalled with grapheneos?
I mean in the long run, it should be a good thing to separate out the hardware phone market from the OS it comes with IMO. And for large scale adoption, it's extremely useful to have the most non-technical people using your OS, because they will complain and bugs will get reported (maybe not through the preferred channels, though).
No notes on the markup though. Infuriating there's no negotiating ability to say "you can't sell this OS on a cheap phone for 600% margins".
Most of the people I've encountered that use Java are working on enterprise codebases that are a couple decades old at this point. And I'm totally unfamiliar, but I thought Kotlin was vaguely "Java for Android" - other than existing packages, are there other reasons to choose languages focused on the JVM?
Modern Java is definitely pretty good. But indeed, Java has solidified a lot around "old" style code: making your 50 years old CTO start using collectors and typing `var` instead of MyObject object = new MyObject(); can be a difficult thing. Modern Java is truly quite pleasant.
Kotlin is a fully JVM compatible language. Java is catching up to it in some points (Project Loom has made multithreading in Java almost as pleasant as coroutines in Kotlin), but the experience in writing DSLs, code with lambdas, the brevity afforded by Kotlin makes it more pleasant than java. It's also the default recommended language for Spring/Spring Boot now, that is probably the largest JVM API backend project that ends up being used by default.
The benefits you get are:
* Probably the most stable platform you're ever going to get: the JVM is rock solid and does not require tuning honestly, unless you're trying to get a free few percents of performance. Your shitty SaaS startup doesn't need to do that.
* Probably the most performant JIT in the world. Python isn't nearly close, and Go is, well, not jitted, but offers similar-ish performance. Except that you get a good GC with the JVM. Or rather multiple GCs depending on what you really want: throughput/low pauses/etc.
* The packages are truly a massive thing. The APIs aren't always perfect, but behind python & js, it's probably the most fully fledged option.
* Publishing modules doesn't suck.
* Having to carry a jar around does suck a bit, but fat jars solve the problem, and if you're serious in your work, you can just GraalVM it and you have an AOT compiled executable that works great.
Negatives:
* It's java, man. It's still the same verbose beast. Doing low allocation work is a bit hard. Kotlin makes it better. Kotlin also has kotlin multiplatform with a large and growing API surface, and is probably one of the most pleasant multiplatform options, allowing you to delegate to any platform code you want.
* You're never getting a tiny 5MB executable. If startup time is an issue, work hard on GraalVM.
Interesting! I am curious to ask someone who has been working on no-code tools for so long: I've been reading about no code platforms from the 1990s, and how all of those ended up failing. The reason I've seen cited most is that the tools/platforms did not allow for enough variability to do the jobs that people wanted (without becoming a full programming language themselves). What do you think about that in the context of the past ten years, pre- and post-LLMs?
And what do you think about coding agents in the next few years? Will we see a variation in agent capabilities? E.g. a company makes and distributes a specialized coding agent for CSS, or even serving up a kind of library that's language-agnostic, since they seem to be best at translation rather than creation?
"company makes and distributes a specialized coding agent for CSS" - weird that you think this is a path because I think this is not as appreciated as it should be.
No-code has been in a poor state for many reasons. I agree that people want more generic software to be built and the platforms did not allow for enough variability. This is what being better enabled with LLMs.
I think coding agents, particularly Claude Code, makes people think that models are the key. Some people disagree. I disagree as well. I think small models with lots of deterministic code is the way. But this will not fill Anthropic's or OpenAI's pockets.
Using an LSP, for example is recent in coding agents. But if you think about it, we should have started with that. Most agents expect LLMs to know too broadly. I would instead create 40 (random number) agents - one for each language and part of the stack. This is why your CSS example is interesting. I create just an agent for the ORM related code in a Rust/Diesel based coding agent. It worked with a 4B parameter model!
People will fight over "worked" but basically what I did was create deterministic code generator for the ORM layer - schema, model and model accessor or mutator functions and then asked the tiny model to fill in the code with lots of code example straight from the official docs. It played well for many different kinds of prompts - all focused only on model related changes.
What if we create many layers of this - a higher level agent breaks human prompts into an intermediate language and then tech-stack focused agents write the code within deterministic tooling. Agents cannot read or write any file they want - they are specific to that part of the stack, linter, compiler, etc. kick in automatically.
What are you actually saying constructively here, if anything at all? I, for one, happen to agree that fundamental reform is clearly necessary. What that looks like exactly is where I'm sure the problems lie.
reply