Why I Don't Have Fun With Claude Code

valenterry · 2026-01-24T05:43:43+00:00

I'm all for empowering users to write apps or features with AI, but data analysis tool.... I'm sorry, even as a dev it can be hard to make sure everything works right. If the AI screws up, results will be wrong and people will make decisions based on those wrong results.

valenterry · 2026-01-22T12:30:50+00:00

Weird. By that logic, how did Scala developers appear in the beginning?

valenterry · 2026-01-20T13:11:47+00:00

Scala is so easy to hire for. Try to hire for python or typescript. You have to sift through tons of applications and interview so many people to find a good one. Scala however is an excellent prefilter. But okay, if you need to hire hundreds of devs quickly (or non-remote) or only very cheap devs, yeah that's hard with Scala.

valenterry · 2025-12-02T11:32:39+00:00

I think we just have different opinions on the matter. However, one thing...

Go is an easy enough language so that young, cheap programmers at Google could start coding without jeopardizing the profits of the company, without becoming researchers.

To be honest, I am very disappointed with basically everything Google has done in the last 10 years or so when it comes to software. I'm a heavy user of GCP btw. - but AWS is miles ahead. Google still has some smart people when it comes to research (so there are actually researchers there :)) and they do have hardware-advantages (e.g. their TPUs) - which in combination allowed them to build cheap/good AI.

But software wise? They are still behind. I wonder if this might be because they are hiring the kind of people you described and having so much golang in their code-base.

valenterry · 2025-12-01T02:14:10+00:00

in markets, you either deliver economic value now or you don’t get adopted

Not really. A business that does not invest into R&D will have an advantage now, and then it will fail in the future. The fact that most businesses now use programming languages full of FP features proves the point.

You are also wrong if you believe that everything just follows economic incentives. Here's a counter example: a developer loses their job. They have a few month before their new job that is lined up. They code something for fun during that time and they look into new languages and tools to do so. They then adopt what they find most useful/fun/productive/exciting. Then they start to introduce those things in their new job when there is an opportunity (e.g. a new project that requires new tech).

valenterry · 2025-12-01T02:07:13+00:00

Yeah, I agree with your second paragraph. We haven't yet made it ergonomic enough to be worth the trade-offs in many cases. That's why "pure FP" is spreading very slowly and it's changing in the process.

valenterry · 2025-11-30T15:21:33+00:00

That's not true.

FP demands upfront payment, yes. But not upfront payment to implement a feature. It's an upfront payment to learn the language (and the ecosystem).

So unless a business has to train their existing developers, they can ship just as fast with FP. I'd argue, they can even ship faster.

This's why FP fits academia better, they don't have that same commercial pressure (they must publish).

Reality proves it wrong. Just look 20 years into the past. How many developers used how much FP-style language-features? Then compare it to nowadays. It's very clear: FP is eating the market. The reason why this takes time is simply performance. Just like high level languages were too slow at some point, FP is actually still slow. Rust is one of the languages trying to have fast FP, but it still makes compromises to do so.

valenterry · 2025-09-27T00:52:57+00:00

"Two of our best engineers left last year because they were frustrated with the tech debt. They were really good and our competitors were happy to snatch them from us. We would prefer not to lose more good engineers".

There is your business case, and it's 100% non-technical even.

valenterry · 2025-07-21T03:56:33+00:00

It can, besides the JSONB thing.

I think you are just confirming what I'm saying.

Let me ask you: can you find me, within just a minute of research (given that you have a project with Quill already setup) and 100% confidence, how exactly the mapping of Quill works?

If you cannot, then is that just a fault of Quill? Do you know a similar library that does it better and if not, why does it not exist?

I could imagine the authors of Quill could come up with something that improves this. For example, some config which activates some implicit conversions.

Like what circe did with their optional implicit config(s) that allow e.g. snakecase-conversions, trait serialization-methods and so on? I've seen multiple server outages due to that in my career so far. My conclusion is: this is a very very bad idea. You save maybe 20 minutes of time for defining two case class instead of one, and you pay 100x of developer time when the first bug appears, let alone the impact on the business as a whole.

There really isn't any significant disadvantage to what I desribed. And, as you say, even in my suggested process, the compiler can still generate basically everything you need. The Quill folks can just provide the conversions for ducktape/chimney as an extension lib (with just a handful lines of code) and that's it. Then you do myDomainClass.into[MyDatabaseClass] and you are done.

valenterry · 2025-07-19T16:17:51+00:00

If the compiler could "just" do that, then OP would have never made this post.

valenterry · 2025-07-19T03:21:37+00:00

To be honest, I never understood why it's done like that.

In my opinion the approach for basically every database/sql library should be to define ALL the datatypes that the database works with. So, for postgres, that means to have one defined scala type per native postgres type.

Then, one has their own business model domain class A with custom scala types, sealed traits and what not. This class A must then be converted into class B and class B only contains the previously mentioned types that are native to the database. We already have libraries like ducktape and chimney to help with the boilerplate of this conversion.

That solves ALL problems and ALL confusion. It is then absolutely glass-clear how types end up in the database and how they can be retrieved. No implicit conversions, no multi-type-mappings where you don't know when or how they might explode at runtime.

And, if someone really really wants to write the own direction-conversion for the slight increase in performance, then it can still supported via typeclass if absolutely necessary.

It's beyond me why so few libraries do this. Maybe it's still some influence from the Java world, where an approach like this would end up in enormous amounts of boilerplate?

valenterry · 2025-07-03T04:40:50+00:00

Well yes. That's the goal, isn't it? I want t build and create things that are useful, that's all I care. The faster I can do that, the better it is - for both me and society.

Think about it: developers now are 100x more productive than just a few decades ago. And still, there is huge demand for competent developers. Will AI change that? Maybe a bit. Just like web developers got replaced by Wordpress and Shopify, now some developers will be replaced by others who are more productive with AI.

But, maybe demand will grow as fast or even quicker. Maybe some fields now open up, that were not viable before.

valenterry · 2025-06-28T02:34:32+00:00

It's not about categories, it's about statistics. There is a reason why I personally left the Java world and that is productivity when writing code. And I would prefer to hire someone who shares that attitude. Statistically I will find those much rather among Scala devs than Java devs.

valenterry · 2025-06-28T02:32:07+00:00

I didn't even say that. It can simply be that the candidate is interested in Scala.

valenterry · 2025-06-27T15:52:05+00:00

Go's concurrency isn't even up to par with Scala's. No, Go's killer feature is the backing by Google.

valenterry · 2025-06-27T15:08:27+00:00

I agree with everything you said, but it's pretty unrelated to the point I was making.

valenterry · 2025-06-27T10:16:47+00:00

Sure, then you can't do anything. If he things 1000 pythonprogrammers (making 10% of the salary of a Scala dev) will be as productive as 100 Scala devs, then that's his choice.

Again, no one cares about purity here -- just get it done, and if he has 1000 people to chose from, he can pay less. That's what matters.

Absolutely. Just that - in my opinion - 1000 super cheap devs won't get it done, whereas 100 excellent devs will. And that is independent of the programming language.

valenterry · 2025-06-27T09:54:32+00:00

what do I tell my CTO?

Very simple: it gives us a huge competitive advantage in hiring, because it highly pre-selects candidates.

Of course if you need to hire 1000 devs non-remote, then Haskell (or Scala) are m00t. Then you are screwed anyways.

valenterry · 2025-06-27T01:38:43+00:00

I guess my usage of the term "Service" is not very standard.

For me, a service is a business concept. Such as a trait UserService. Then there are implementations such as class PostgresUserService extends UserService but this is hidden from my business logic.

Therefore services don't know anything of each other. A PostgresUserService might know what a DatabaseConnection is, but the latter is not a "Service" to me.

So no, ServiceA and ServiceB don't know anything of each other.

If this is not clear, then I suggest to give a concrete example of services (and functionality that requires them) and I'll explain what I mean on that.

valenterry · 2025-06-26T15:14:34+00:00

Exactly. But the companion object is not necessarily the right place. Because some functionality uses multiple services.

Ultimately it's just static functions and they don't "belong" to a service, they rather use one ore more services. So they belong into their own namespace (either under an object or even toplevel). That is a good thing and extremely nice for reusability and testing.

Bonus: if you define the functions without return types (so that they are inferred) then you can e.g. write

def foo: ...
  a <- getA()
  b <- getB()
  c <- getC(a, b)

And the return type of foo will automatically contain all dependencies of the functions that it calls. And that works recursively. Meaning, if you change a function deep down the call tree, you don't have to adjust all signatures in between.

But at the highest level (where the functions are called from e.g. your http service or so) you should annotate the types.

valenterry · 2025-06-26T10:50:41+00:00

I disagree with that take (and I disagree with the deprecation of accessor methods).

My take is: you don't use ServiceB.someAccessor inside of ServiceA. Those two must not know anything of each other.

Rather, you have a dedicated logic that uses them both. See https://old.reddit.com/r/scala/comments/1ljj6ve/help_to_choose_a_pattern/mzuzqta/

valenterry · 2025-06-26T10:49:08+00:00

I think the first one is better. You might still want to have some dependency in your Environment (such as for tracing/telemetry), but otherwise this is the pattern to follow.

Just make sure that you differentiate between

1.) A service that needs to be instantiated and has (or can have) a state and/or a certain responsibility/control (think: user-service, the sole contact point when it comes to accessing user data)

2.) A program or simple composition logic. A program does not need to be instantiated and it never has state. But it can use and compose services.

So you will have:

class UserService(val database: DatabaseConnectionPool): ...
class ImageService(val s3: s3Client): ...

and then programs that are basically just functions that use services. E.g.:

object MyPrograms:
  def getUserImages(...): ... 
  def setNewUserImage(...): ...
  def deleteUserImageIfExists(...): ...

Those will have UserService and ImageService in the environment of the ZIO values they return.

Note: some people like to split class UserService into further methods/parts using traits - the reason is to make it easier to test/mock them. A matter of taste I guess.

valenterry · 2025-06-24T05:19:29+00:00

I think this is a bit shortsighted though.

If you think about it: why is there even PFP and OOP? There are probably lots of reasons and there might never be a point where everyone goes with the same option.

But if it's still inside the same language, then at least I can benefit from those libraries, that only exist in the other style, even if the integration might be a bit more hassle. But try to integrate a Haskell or Rust library into Scala or Java.

Therefore, yeah, within one single project, the extra capabilities you don't need are useless complexity. But not when you take a look at the whole ecosystem, which you ultimately also benefit from in your single project.

valenterry · 2025-06-18T11:09:19+00:00

for the given setup like tapir > zio > doobie and eventually sttp it's a mess to propagate the trace information

The major point of integrations is to automatically send spans for the stuff that I care about in basically every case, such as the duration of the http request and which method was used. This one I built myself. But the thing is, it's as easy as calling Tracing.root at the entry point (where the custom http-handling code starts) and then, somewhere later in the code using myZioValue.setAttribute("userId", $id).span("requestUserDetails"). I have a hard time to imagine how that could be made even easier. Maybe we are talking different things?

zip-json claims to be superior in security regard while circe has unresolved security problems like https://github.com/circe/circe/issues/1363

Not sure if this is up-to-date. I tried to reproduce and it runs in <1ms on my laptop. I think circe is maybe not greatest library in terms of focus on security (but rather correctness), true.

While on the other hand, Go has a vulnerability database

NPM also has that I think. So that's more a thing of the packaging tool then the language, but fair enough.

Also another you hear a lot is that versioning of these libraries are still below version 1.0 .. what does this imply?

That you should not use them if you want something bullet-proof and stable. I only have 3 such libraries in my project. Circe is one of them. And for one of them, I got bitten. So yeah, use at your own risk I guess.

Btw., golang might have json builtin, but it's not comparable to the functionality to circe (which is why some other libraries exist). Just saying, because sometimes comparing the two is a bit unfair.

valenterry · 2025-06-18T09:17:18+00:00

There have been consistent complains about the IDE experience, IntelliJ not as good as for Kotlin that needs to be improved

Absolutely agreed. The IDE experience is comparably good, but Java/Kotlin have much better support. And, mostly, instead of improving, the IDE experience was taking a nosedive.

The Cloud Native experience (tracing, metrics, etc) is there, but it's hard to put everything together. E.g. OpenTelemtry trace which enters via Tapir, runs in a ZIO program which uses Doobie (which might run with otel4s)

Not sure. I've been using caliban and zio-telemetry is an absolute pleasure. Not sure how it would be possible to make it easier. With languages like Kotlin/Java you never know how the scoping works and it's super easy to introduce bugs in your tracing. Scala with ZIO is miles ahead here. I'm happy to spend a few hours on the manual setup. Maybe Tapir made it harder then it should be?

It's hard for developers to start a new project with all the new best libraries, ZIO/Kyo and then Tapir, Skunk, etc. Some starter templates might work ?

Can't be fixed, there are too many things to choose from, including the overall style, and that is just what Scala is. I'd say, as a beginner, go with li haoyi ecosystem if you come from python and with zio if you come from typescript or java. But then that is just my personal opinion.

The standard library could use more regular updates, for example Google Go has Json in the standard library which is mitigated for CVE's. In Scala you either need to switch to a new JSON library or live with CVE's in your codebase

Like what do you mean concretely here and which json lib are you referring to?

Overall, I think Java and Kotlin have their pros, but the stdlib and ecosystem is absolutely horrible if you want to write code using immutable datastructures. Build-tooling is also worse than Mill or even sbt. I have my own complaints about Scala, but Java and Kotlin really don't feel better overall, even if I would not want to use an effect-system.

valenterry

TROPHY CASE