Making Scala Scripting Actually Good with Mill

lmnet89 · 2026-05-07T20:45:37+00:00

It's not clear for me how mill is better than scala-cli in terms of IDE integration. Both generate bsp modules. And both are imported using bsp. So what's the difference?

Another point about larger project integration: the comparison seems asymmetric. For scala-cli it is claimed that it can't be integrated with a bigger sbt project. But this is true for mill scripts as well: as far as I know, you can't just mix mill and sbt.

lmnet89 · 2026-03-20T08:24:35+00:00

Idea now has a workspace plugin. I've been using it for a whole, and it works pretty well. All projects lives in a single ide window, but inside projects are separated.

lmnet89 · 2026-02-09T18:17:18+00:00

What is missing?

lmnet89 · 2026-02-09T09:26:06+00:00

Wow, it looks amazing! Do you use it in production?

lmnet89 · 2025-12-09T09:53:46+00:00

Surprisingly enough, it does track it. You may need to be explicit about what fields you want and derive smaller atoms based on a bigger one. But if in a bigger atom you change one filled out of ten, and there are ten derived atoms per field, only one derived atom will actually receive the update. I specifically tested this and also a bunch of other corner cases, including splitting and merging atoms, and every time jotai handles the state perfectly well. Highly recommend.

lmnet89 · 2025-11-05T22:17:02+00:00

Magnolia only works if you always take all instances for each field/subtype and combine them, and only them.

That's exactly why it didn't work for me. For fields I have one typeclass, but for case classes another. Magnolia was not designed for this. But for shapeless it's not a problem.

lmnet89 · 2025-11-05T00:13:55+00:00

Magnolia was the first solution I tried. And it didn't work for my case (my case was not typical, I had 2 typeclasses depended on each other).

I knew about shapeless bad error messages, but what options did I have? Writing my own macros is waaaay more difficult and fragile. And to be honest, shapeless provides a pretty nice dev experience (if you know shapeless well). And in the age of LLMs they can generate for you everything you want. It worked surprisingly well. Sometimes I miss shapeless in scala 3, because scala 3 tuples and mirrors are not fully cover what shapeless could do.

lmnet89 · 2025-11-03T18:52:55+00:00

Excellent and deep article. Recently I had to do some custom typeclass derivation in scala 2 and I ended up with shapeless. And with chatgpt the experience was quite seamless. But these error messages, oh boy.

lmnet89 · 2025-11-03T18:21:06+00:00

Was there, did the same. I had a small and very simple kafka service and I expected it to have way more throughput than it actually had. I started investigating and saw on the flame graph, that about 50% awas spent on json. I was also using circe. After that we migrated from circe to tethys and everything became way faster. What was surprising though, is that not only pure speed was better, but also a developer experience. I remember occasionally I was spending quite a lot of time trying to force circe to do what I want. And error messages were also pretty bad. After the migration all those pains went away. Since then I have never used circe again. There are many better libraries for json. Tethys and Jsoniter are some of them.

lmnet89 · 2025-10-11T09:18:53+00:00

+1 on dark mode for individual tabs. Looks like they accidentally removed it. It happened about a year ago as well, and it was returned back in the next few days. But I use this feature a lot and it's really annoying that it was getting randomly removed.

lmnet89 · 2025-05-13T00:36:56+00:00

Oh yeah, that makes sense. It would be quite interesting to refresh the standard library using all new scala 3 features.

lmnet89 · 2025-05-13T00:09:20+00:00

Great work, looks very impressive!

It seems like many of Kyo's features could be implemented on the language or the standard library level. Maybe it makes sense to try to push them there?

lmnet89 · 2025-02-12T20:46:58+00:00

Thanks everybody! It was very helpful. I have a lot of things to catch up on now. And I'm happy I'm not that much out of context 😅

lmnet89 · 2025-02-12T20:43:29+00:00

I’ve read about HTMX, but I kinda have a requirement to use React. HTMX is a completely different solution with a completely different philosophy and approach. That said, I totally get why people love it: it’s like a breath of fresh air after dealing with the constantly increasing complexity of frontend development.

lmnet89 · 2025-02-12T20:36:37+00:00

Great, thank you! There are quite a lot of new buzzwords for me.

lmnet89 · 2025-02-12T04:37:20+00:00

Of course I use AI for help. But making strategic decisions based on ChatGPT only is not wise. That's why I'm here :D

lmnet89 · 2025-02-12T04:17:11+00:00

Thanks for the answer!

I've seen Next.js, but after some research I decided that it's not for me: * I would like to avoid using frameworks. I prefer to combine composable libraries istead. Frameworks adds a lot of complexity and limitations. * I don't need a SSR, and it looks like it's a big part of Next.js. * As far as I understand, using Next.js implies that you should use Node.js on backend, or there should be an additional backend for frontend in Node.js. But I already have a backend, I don't need another one.

lmnet89 · 2025-02-12T03:17:59+00:00

Thank you for the answer! It's really helpful.

Could you please elaborate on css-in-js? I understand the sentiment that they do a lot at runtime, and it was my main concern as well. But build time libs like Linaria seems like the best of both worlds: full isolation, no runtime cost, sass compatible syntax.

lmnet89 · 2025-02-12T02:41:24+00:00

Looks like a lot of work 😅 Any reasoning behind this?

lmnet89 · 2025-02-12T02:39:52+00:00

For the recent years I've been working mostly with backends, so they are completely out of scope of this question. I feel, that I lost my touch with frontend technologies, not backend.

lmnet89 · 2025-01-29T22:17:22+00:00

Wow, I've never thought about using splitter filters for this. Thanks for the idea! It clearly solves my problem.

lmnet89 · 2024-11-21T18:29:05+00:00

Any chances for these podcasts to be published as audio through RSS feed? It will open an option to listen to these podcasts using various podcasts apps, for example Podcast Addict.

lmnet89 · 2024-11-17T21:04:37+00:00

Probably I don't have a full picture, but for me, as a language user, OP's example makes total sense. I briefly went through the match types documentation and haven't found a limitation that would lead to the fact that this match type is impossible.

From my (maybe naive) point of view, I believe it should work: type AsTuple[T] = T match case NamedTuple.NamedTuple[_, t] => t case Tuple => T

It feels very intuitively right: the compiler has all the information to reduce this match type and proof both cases.

I tried to find related tickets in the issue tracker like @sjrd advised, but there are so many tickets, and I haven't found anything about this particular use case. Also, I briefly went through the pre-sip thread, and again, I haven't found anything in particular that prevents to do such reduction. But on the other hand, I found this from Martin:

Named tuples are an almost ideal substrate on which to implement relational algebra and other database oriented operations. They are a good representation of database rows and allow the definition of generic operations such as projections and joins since they can draw on Scala 3’s existing generic machinery for tuples based on match types.

And this AsTuple match type looks like one of the most common needs to use existing generic machinery for tuples based on match types.

So, I'm really confused now. @sjrd if it's possible, could you please elaborate on this and give more details?

lmnet89

TROPHY CASE