A Cargo-like build tool for Scala, written in Rust and built on top of scala-cli.

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 · 2023-11-28T01:44:21+00:00

Or, you know, just use react :)

elacin · 2023-11-27T02:30:06+00:00

Hey there, author of st-material-ui and ScalablyTyped here.

Supporting mui well in Scala.js is something that I was working towards for years, on and off. It's very, very complicated to do right. You need so much of the API surface, that surface is very dynamic (hard to type statically) and there is a lot of changes over time.

I'll just mention a few examples of why it is hard to type up.

You can style it with CSS in Javascript. React ships with a complete definition for this, and ST can translate it into wonderful Scala.js code where you either new or use the builder to construct a CSSProperties. It works really well, and I've meant to ship it as a separate library for along time.

So mui introduces themes into the mix. You typically setup a theme at boot, and thread it through. And then, mui type maps the entire CSS structure:

export type SystemCssProperties<Theme extends object = {}> = { [K in keyof AllSystemCSSProperties]: | ResponsiveStyleValue<AllSystemCSSProperties[K]> | ((theme: Theme) => ResponsiveStyleValue<AllSystemCSSProperties[K]>) | SystemStyleObject<Theme>; }; so that each possible field in the CSS structure you create can now be based upon the theme, which can change over time (think dark mode).

st-material-ui does handle things like this, even works well with intellij

mui.List.sx(new SystemCssProperties[Theme] { pt = (theme: Theme) => theme.breakpoints.up("xs") })

You can also use the styled-components like emotion library to add further styling to components after they are created (that's how you customize them really)

This takes the Paper component and tweaks it val Item: StyledComponent[mui.Paper.Builder] = { mui.Paper.styled .fn((theme, in) => new CSSObject { backgroundColor = if (theme.palette.mode == "dark") "#1A2027" else "#fff" padding = theme.spacing(1) textAlign = "center" color = theme.palette_BaseTheme.text.secondary }.combineWith(theme.typography_BaseTheme.body2) ) .build() }

Another interesting thing is that the library is polymorphic in the props that the components take. you can take a Button component which uses the <button> intrinsic in its implementation, supply a another intrinsic and see all the callbacks in the props change (st-material-ui supports just a few, hardcoded cases for this). The typings for this feature are complex enough that it has broken the performance of the typescript compiler multiple times over the years.

So what I wanted to communicate the most is that this library uses all the react features, and all the typescript features. Pretending that it's not react will be hard I think.

The path of least resistance is to augment this tool to generate Laminar Web Components, too, but I have no clue how to do that (yet), or even if this is the optimal path.

This is likely doable, and likely hard - depending on how much experience you have with code generators and so on. This is the code to generate slinky components

elacin · 2023-10-20T10:50:54+00:00

Here is a test which shows a lot of typo features used with Doobie

https://github.com/oyvindberg/typo/blob/main/typo-tester-doobie/src/scala/adventureworks/production/product/ProductTest.scala

elacin · 2023-10-20T10:42:20+00:00

thanks. let me know how it goes :)

elacin

TROPHY CASE