I would definitely trim like 20% off scala, but I think slow compile times were the main reason. To a much lesser degree but sbt being one of the first things you deal with when learning the language didn't help.

If you put a gun to my head and tell me you can't write in kotlin, you must choose either Java or Scala - for a small project I think I choose modern Java. If you tell me I need to choose for a large cross team and mission critical project - I think I take the bullet.

Still, I have a soft spot in my heart for scala, learned a lot from it.

SBT cleared a lot of footguns in the last decade or so, but at the time where Scala adoption was popular, it still had a lot of weird syntax, including the strange, meaningful whitespace, and enough DSL syntax to scare people.

sbt breaking our builds every six months or so has become quite tiresome. It's still the worst part of Scala IMO

I used to agree with your sentiment, but the LLM revolution has changed my mind. I noticed that the verboseness of Java leads to a higher token use when compared with Scala.

But you could save some token with Kotlin, too. The language is a bit less "magic" and compiles faster. So, Kotlin might be a sweetspot for AI code generation. Go is probably another good candidate.

yes, but when I think simplicity I don't think string handling in C

It’s trivial to use slices/builders, aka char arrays with length, in these cases, and have bounds checking. You are reading and writing byte arrays anyways.

If you want to generate HTML properly, you treat as the tree it is, instead of doing string concatenation. If you do that, then you also don't need to do much with strings, so that problem is already solved.

I read the comment you reply on as a reason not to use C.

Im sure there are more reasons but updates to prompts and tools coming from the server side is a major one.

It's typed so you can build some governance around it, by allowing only some tools or parameters for your org (this is a pretty weak point, but still)

A skill has one giant description from the frontmatter loaded into the context, where MCP loads a smaller one for every tool. Not necessarily better, the skill approach is often better actually, but sometimes the MCP approach fits more

Expectations are a funny thing, a year ago I thought all software industry will cut at least 30% in a year. It's very far from happening. A big change is obviously coming but now I think I'm good enough to last at least the next 5 years, which suddenly feels like a long time if you see it coming.

The truth is despite these very impressive improvements, most impressive work done by agents require many iterations running in a loop, with tens of thousands of dollars in API pricing. And it's still far from being always reliable. Somewhere along the way hardware will get better, energy will be cheaper, the market will be flooded by chips. There a physical world issues that limit all of these for now, thank god. I think 5 years is a good number.

The real damage is that enterprise work became unbearable. Slop code with slop code review, and overly verbose emails with repetitive presentations. And on the other hand, I now enjoy "coding" for myself like I'm 16 again. All I want to do is sit at home and build apps for myself and family. I barely go to work

> Expectations are a funny thing, a year ago I thought all software industry will cut at least 30% in a year.

People overestimate the change in the short term and underestimate the long term. Timelines are hard.

Also predicting the first victims is harder - I don't know many that thought pure mathematics would be high on the list.

I keep repeating this too.

The history of the self driving car is apt to repeat as well. I remember thinking "2015, 2018 maybe at the latest." But as 2015 (and 2018) came and went, expectations were tempered.

We will see shortened development cycles, and maybe even orders of magnitude shorter development cycles.

But hard problems remain hard (there are only so many chips, materials research and biology are difficult problems). Manufacturing remains a choke point.

I'm more concerned that the absolute worst persons on the planet are in charge of many of these technologies. If those that are in charge are more concerned about allocating resources and power in their favor, the more dismal the future of all humanity will be (including for those in charge, but they can't see that due to self-interest bias)

I think the change might be orders of magnitude more software being written rather than an order of magnitude fewer developers. There is a HUGE induced demand coming when software is so cheap to write.

I've never been a professional, but I've been coding for nearly 30 years as an amateur, and I've "written" more code in the last year than the previous 29, and it was all tooling for my very non-tech small business. It's cut HOURS out of my week, and it's all software I could not have afforded to pay developers for. But with Lovable, just describe it and iterate.

What IS going to die is software as a service. I've cancelled hundreds of dollars a month of subs and rolled my own better tooling.

#ad

Yeah I’ve been commenting on here for 20 yrs just to promote some stuff later.

In the world of web apps, I find the agent's ability to write good e2e tests to be a real game changer. Turns out with enough rigor you can write pretty stable mostly not flaky e2e tests. And even flaky ones are fixed quickly due to a fuck ton of assertions at every step.

Test code looks like a mess, even more than the usual LLM code. takes a while to let it go. Test report looks beautiful though.

When the test code "looks like a mess", how do you get assurance it is testing the right properties?

Like you, I've found that LLMs can improve test coverage by decreasing the amount of developer time spent writing tests. But generally, it takes a lot of manual work to set up the initial testing framework, and even then, a lot of vigilance to ensure that what is actually tested corresponds to the description of the test.

Whenever it gets back I recommend everyone to use it. My go to prompt for demoing it to others is "I eat poop off the floor"

And I'm scared to hardcode some negligible config value that will never change

I played with it for 10 minutes, very impressive. Couldn't get vscode to work, will try again later with different apps. (vscode is not that important anyway as it has a remote mode)

I understand (well, "guess" more than understand when it comes to graphic stack in Linux) that it being it's own compositor probably means running a full desktop environment in it is infeasible, but a good way to run software remotely is painfully missing in Linux right now, even one app at a time. The built in servers in kde/gnome are problematic in general and require the monitor to be turned on.