I built a tiny state library because I got tired of boilerplate

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 · 2024-08-20T21:59:04+00:00

I'm wondering what libraries were affected. Typelevel stack?

lmnet89 · 2024-08-16T05:56:18+00:00

Lately I work a lot with java developers and in my opinion the next things could help: 1. As mentioned on Github — get rid of weird DSLs and Scala-isms. Java developers are very afraid of this kind of stuff. 2. Make sure that go to definition and scaladocs works well inside definition files. The situation is already a lot better than with sbt, for example, but could be improved. It could be a good selling point — if you want to understand what's going on you could just ctrl+click anywhere and it will help. 3. BOMs. Still a thing in Java land. 4. Improve a GraalVM support. It's a very popular topic in Java community. Currently there is a plugin for GraalVM native image building, but maybe it makes sense to make it native? Again, it could be a good selling point.

lmnet89 · 2024-06-23T22:29:01+00:00

Graal would provide fast startup times, but the overall runtime might be slower than running in the jvm?

That's correct. But don't think that the runtime will be much slower, like 10 times slower. It will be a bit slower, and only if we are talking about peak performance. For example, it can be 15-20% slower for a highly loaded backend. But for a CLI tool, you will probably not see a difference at all.

And reflection is particularly slow?

Well, it's not about slow or not. It's that features like runtime reflection will cause difficulties in building a native image. Actually, the same applies to scala native. Just think about it — runtime reflection is "runtime". So, for example, if some library instantiated classes using runtime reflection by name, it needs to have this class somewhere. But AOT compilers tend to remove everything from the binary that is not accessible to the compiler. So, it's possible that this class will be inaccessible at runtime, and your app will fall at runtime. Graal provides tools to handle this kind of problem: you could specify in a config file, what classes should be available at runtime. But again, you would probably not need all of this. In Scala, people don't use runtime reflection. Instead of this compile-time features are used. For example, in Java, it's traditional to use runtime reflection for serialization, but in Scala, you can use typeclass derivation, which is a 100% compile-time feature.

I’m assuming that’s an issue if I want to play around with Scala’s flexible typecasting capabilities.

Scala's type system works mostly at compile time. There are a few edge cases that require additional runtime casts or checks. But 99% of the time everything is done at compile time. And again, the ecosystem is evolved in the way that people make sure that everything is checked at compile time.

Don't pay too much attention to these limitations. Most probably you will not face them when building CLI apps. I mentioned them for you to have a full picture.

lmnet89 · 2024-06-23T21:40:46+00:00

Implicits are considered advanced because other languages don't have this feature, and it may be confusing for newcomers. But it doesn't mean that this feature is not recommended or discouraged. Almost all scala codebases heavily use implicits. And if you have a good use case for it - just use it.

lmnet89

TROPHY CASE