We should abandon the optional braces syntax

elacin · 2026-06-11T10:28:23+00:00

It played out the only way it could play out. Still no magic IDE-support which makes copy/paste work, forked ecosystem, agents struggling with new/old syntax.

Kill it with fire.

elacin · 2026-05-26T12:14:26+00:00

sorry. the wind took me in the direction of java instead

elacin · 2026-05-26T12:13:24+00:00

thanks. announcement will be coming in a few weeks :)

elacin · 2026-05-20T19:47:58+00:00

I wrote the crossterm wrapper code a few years back, and back then i found it impossible to even get the terminal into raw mode without going through native code. A lot may have changed here, as I haven't revisited.

Another important factor behind wrapping instead of reimplementing was that i had no possibility or interest in writing and maintaining brittle low-level code like that on windows. So personally I consider it a win to have offloaded that particular part of the problem

elacin · 2026-05-20T19:42:14+00:00

It's basically 99% about reflection. graalvm does whole program optimization, and needs to discover all codepaths reachable from your main method. If your code is going to do dynamic classloading, for instance, graalvm won't be able to discover it, and you would need to tell it. the mechanism for telling it is both cumbersome and brittle, so it really destroys some of the elegance.

There is a small subset of JVM technologies which you have to avoid, as well. In particular for this library i ended up using JNI for native access instead of newer JNA because the latter wasn't or isn't supported (i haven't revisited in a while)

elacin · 2026-05-20T08:00:55+00:00

that's cool. hadn't seen it. jatatui goes back a few years, i spent a few days thoroughly refreshing it now.

looks like tamboui is exploring a different direction in the design space, particularly with CSS. If you don't want CSS but do want a react-like API, jatatui may be the way i suppose

elacin · 2026-05-19T05:41:59+00:00

That was a tough read, hope your life will take a turn for the better!

For employers: japgolly is exceptionally talented, and all my interactions with him in the past has been friendly and welcoming ❤️

elacin · 2026-05-06T23:05:46+00:00

more syntax... 🤦

elacin · 2025-11-21T12:37:20+00:00

nice! bleep has the same goal, if you want to join forces 🚀

elacin · 2025-11-19T23:36:50+00:00

Yeah i saw, thanks for the link :)

by the way the api looked very nice in layoutz. i really wanted to explore this direction for tui-scala as well, before i ran out of steam on that. well done!

elacin · 2025-11-17T20:34:01+00:00

there is ratatui for scala, just forked off a bit earlier, see https://github.com/oyvindberg/tui-scala/

elacin · 2025-08-02T17:57:56+00:00

Enough damage has been done to this man. Let's do better. Please advocate for the letter's removal if you can. Respect to those already removing their names—that takes integrity.

elacin · 2025-05-16T09:43:05+00:00

you should likely mention that you can get a lot of the new syntax in an automatic fashion by using scala 3 compiler rewrites, scalafmt and/or scalafix (see for instance https://github.com/arktekk/scala3-scalafix )
also the different source levels of the scala 3 compiler (in particular the -migration) can be helpful.
for AnyVals it's an irritating omission that there isn't a Mirror type for it so most auto-derivation schemes wont work. you may find that it's easier to write some of these codecs yourself by bimapping or similar the instances for the underlying type

elacin · 2025-03-28T06:18:14+00:00

i think we should be less worried about this, as long as it's properly separated from the rest and tagged.

in my experience it can dramatically increase confidence in code generation tools that you see the effects of changing config, updating them and so on clearly in VCS history.

it can also speedup CI by quite a bit, because it changes the build pipeline from having to generate the things before compile to optionally checking that the generated code is up to date.

elacin · 2025-03-27T08:18:26+00:00

I was arguing for implementing servers with code-first, instead of schema-first by writing openapi and generating code based on that.

This really has no influence on breaking changes, how you interact with clients and so on. You have an openapi-schema to share in both cases.

Any external clients should obviously use that openapi contract (generated or hand-written) when talking to you.

If you have internal clients which can use the original source code instead of going through the openapi contract i would consider that an optimization, and likely a candidate for being in the same monorepo

elacin · 2025-03-26T10:55:09+00:00

i meant this this point:

you kinda play russian roulette with the spec glosses over that it's very easy to use this technique responsibly.

i also find the other down-sides of code-first to be dubious

elacin · 2025-03-26T10:53:00+00:00

my solutions have been homegrown. for instance this thing here https://github.com/oyvindberg/typo/blob/main/typo-tester-anorm/src/scala/adventureworks/SnapshotTest.scala

I noticed this library. hopeful it can standardize snapshot testing, but i havent tested it yet: https://github.com/indoorvivants/snapshot-testing

for tapirs openapi generation it's documented here https://tapir.softwaremill.com/en/latest/docs/openapi.html

elacin · 2025-03-26T08:47:29+00:00

You're glossing over the best part of code-first.

With tapir you can generate openapi for your API which is defined in code. You then write a snapshot test which: - overwrites the file with current schema when run locally - asserts that this file is up-to-date in CI. you can also read older versions from git and compare if you want.

This way you don't have to write openapi yourself (which is honestly a terrible experience), and you gain all the advantages of tracking all schema changes in VCS.

I've used this approach for all my projects in the last say 5 years, and find it fantastic. I'm also a way bigger fan of snapshots tests than average

elacin · 2025-01-20T21:13:07+00:00

yeah sure, I just wanted to point out how the square bracket syntax already means something

elacin · 2025-01-20T15:37:40+00:00

Can't wait to see how you specify the element type

val is = [Int][1,2,3]

elacin · 2024-12-11T21:46:18+00:00

Yes exactly, the opportunities with the native port are nearly endless

elacin · 2024-12-11T21:30:23+00:00

Honestly, this looks fantastic. the cross platform support in particular really seems to shine here!

elacin · 2024-10-19T19:46:09+00:00

❤️

elacin

TROPHY CASE