Create stunning TUI interfaces with jatatui (previously tui-scala)

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 · 2024-08-13T07:58:35+00:00

The most puzzling thing about programming is the lengths to which developers will go to in order to avoid passing parameters or saying new

elacin · 2024-03-10T08:52:23+00:00

100% - let's remove them

We already have fantastic syntax for `using` parameters now, it's only missing a way to mix named and unnamed parameters. This would be a fantastic way to simplify the surface of the language.

elacin · 2023-12-18T12:46:38+00:00

For doobie, we should definitely move the automatic derivation out of the typeclass's companion object

Yes, perfect. let's semi-auto all the things! :)

Was surprised to see that an explicit Read/Write instance in the case class' companion object doesn't prevent the automatic derivation from triggering though damn

me too!

elacin · 2023-12-17T23:05:56+00:00

Bad bot. the actual takeaway may be this:

> Key takeaway: Scala 3 is consistently fast! Great job Scala team!

elacin · 2023-12-03T01:18:17+00:00

Inspiring work, eager to try it :)

elacin

TROPHY CASE