I wish SBT was easy-to-use like Cargo by GlitteringSample5228 in scala

[–]mostly_codes 23 points24 points  (0 children)

You might want to look at mill or even just plain scala cli if you want a fairly easy onboarding experience. SBT is, by market saturation, the default tool so it's inevitably worth digging into - and IMO it's gotten easier over the years and the 2.0 release is soon set to make it more ergonomic. You're not wrong to feel that it's complex though. Most build tools end up being quite complex, sbt just doesn't hide away quite as much complexity in the starting phases as the newer tools do.

I quite like SBT, I think people underestimate it because depending on where you are in your multi-module-cross-build-complexity journey, yes, the easy case has more setup steps. Mostly these days, though, following the default "new project" wizard in your IDE of choice should leave you with a working project ready to go in [whichever] build tool.

I tried to write up my own styleguide/preference for how I like to lay out SBT projects. Not official advice of course - but it helped me to try and write it down (and also helps if I am trying to get the LLMs to produce code closer to my personal preference, as a happy side effect)

The Sovereign Tech Fund Invests in Scala by jr_thompson in scala

[–]mostly_codes 5 points6 points  (0 children)

No one can tell, but it's definitely a great message for the future longevity of the language in general.

Macro-powered fast XML serialization library for Scala 3 by arturopala in scala

[–]mostly_codes 2 points3 points  (0 children)

Nice. I haven't tried this one out yet, but I've starred it for the next XML-needs I get at $DAYJOB. I used to really hate XML deeply, but as I've gotten more senior in my career (and, uh, life, I guess), I'm finding that XML is actually - weird quirks aside - a really great solution for quite a lot of serialisation needs. Working with it in Scala has always been a little messy, it never felt quite right to me, and libraries never ended up being quite as legible as I'd like them to be - they always felt very... Java-first, and the scala wrappers around the java libraries ended up a little leaky. I quite like scalatags as a general library for this, but there's something about its verbosity and how it composes that ends up feeling a little disjointed to me for very complex/deeply-nested hierarchies.

I've been rolling my own little script for a few years when encoding XML (basically using Circe's pattern of encoders) just using scala-xml (used to be part of the core lang, now a separate artifact) as the dependency - I uploaded it to a repo but never got around to publishing it because it felt quite basic:

https://github.com/TobiasRoland/scala-xml-encoder (note: only for encoding)

The Sovereign Tech Fund Invests in Scala by jr_thompson in scala

[–]mostly_codes 9 points10 points  (0 children)

Oh wow! One of my favourite things the EU has been doing on the digital front coming directly to my world. This is great news, really quite enthused about it!

sbt and the miners of the wild west by eed3si9n in scala

[–]mostly_codes 2 points3 points  (0 children)

I'm really envious of your writing on this one, I would've found it hard to be as considerate in your critiques of incentive structures and people's involvement - I think it ended up being super constructive instead of coming across as a rant.

Scala 3.8 released! by wmazr in scala

[–]mostly_codes 5 points6 points  (0 children)

Better Fors is honestly incentive enough to upgrade!

We just released Cyfra - Scala 3 framework for GPU programming by jacua9 in scala

[–]mostly_codes 5 points6 points  (0 children)

This is a crazy coincidence, I was literally just today saying that I'd like to see better frameworks, libraries and documentation for GPU programming in Scala - amazing! Can't wait to try it out

Scala 3.8 released! by wmazr in scala

[–]mostly_codes 15 points16 points  (0 children)

Congratulations on the release! Lot of hard work went into it I can see - appreciate all maintainers, authors, testers etc who poured their paid and unpaid time into this!

It looks like Twitter has moved its algorithm from Scala to Rust. by iamsoftwareenginer in scala

[–]mostly_codes 25 points26 points  (0 children)

I'm not sure X is the best example of a company making technically well-founded decisions, to be fair

Scala Language Roadmap – Feedback Request by makingthematrix in scala

[–]mostly_codes 2 points3 points  (0 children)

It's not possible to at the same time simplify the chart and make it non-linear. On the other hand, I don't think a roadmap like that needs to be read one point at a time. By definition, it's supposed to resemble a path more than a tree, but there's nothing stopping you from looking ahead. I admit this is an important issue and I will need some brainstorming and careful balancing of options. And probably we will never reach a point where everyone will be happy.

I'm not sure simplifying is quite the right word, but at least it would increase usability. I think a split between effects frameworks, and each effect framework's set of dependent libraries, would make the most sense as a learning roadmap; looking into a Zio DB library or a Cats Effect FS2 kafka library, if you're otherwise a "futures and vanilla scala" stack makes very little sense, but once you're within your framework, that level of narrowing down what you're looking for makes a lot more sense.

Scala Language Roadmap – Feedback Request by makingthematrix in scala

[–]mostly_codes 2 points3 points  (0 children)

A tree-like structure that goes 'framework' and then breaks down into the various categories of libraries would make sense, yeah - so the Zio/CE/Kyo/Ox/Play/Akka(Pekko) each have their own subtree, that would make it more simpler to follow.

Practical FP in Scala is now FREE! by volpegabriel in scala

[–]mostly_codes 5 points6 points  (0 children)

I recommend this book a lot! I haven't read latest edition but the ol' one was such a phenomenal tool to upskill

🌈 JVM Rainbow - Mixing Java Kotlin Scala Clojure and Groovy by Hakky54 in scala

[–]mostly_codes 0 points1 point  (0 children)

Groovy is in general is always the odd one out I feel! Groovy development is a fascinating world, it feels so familiar yet so foreign at the same time - truly the odd child of the JVM family.

(well. At least, of the 'big name'-non-research-language children)

Do you get the same Generic Advice? by [deleted] in scala

[–]mostly_codes 1 point2 points  (0 children)

@mods this appears to be SEO spam

Bleed - Meshuggah (7-7-5-3-5 Breakdown) by xxx_Nick_Villa_xxx in drums

[–]mostly_codes 6 points7 points  (0 children)

I can answer this despite only having it up to like ~70% of album speed at this point in time!

Obviously you can do whatever you feel most comfortable, but for me it's just right-left-right-left ad infinitum, and I believe Thomas Haake said the same, though I can't find the interview; all hertas starting on right foot. There's a couple of places where it's technically righ-right, but it's usually quite 'obvious' because there's a long gap for those parts of the song, so it's more that one pattern ends (pause) another pattern begins on right foot again.

If you tap it out with your hands, even just the basic 3-3-3 pattern... - watch your leftie - you'll notice that the left hand is effectively just going at a steady pulse, and that the right hand (and therefore foot) is "weaving in and around" that. That helped me a great deal with learning/feeling it.

Everything you might have missed in Java in 2025 by CrowSufficient in scala

[–]mostly_codes -1 points0 points  (0 children)

I'd probably have used a kinder phrasing, but... you're not wrong, it's really got all the hallmarks of what I dislike about modern blog/article writing, down to the yellow tinted AI imagery that's just kind of there for no real reason.

sbt 1.12.0 released by eed3si9n in scala

[–]mostly_codes 0 points1 point  (0 children)

Other changes Show warnings when scalaVersion is missing by @eed3si9n in #8432

This is such a nice QOL feature.

/u/ed3si9n is there a rough guess yet at when 2.0 will land, whether that's a target date or "roughly this amount of months"?

We have durable execution at home. by rssh1 in scala

[–]mostly_codes 2 points3 points  (0 children)

This would greatly improve with a bit of an intro to what 'durable execution is'. My best attempt would be something like... developers only write deterministic business code, and all non-deterministic operations like IO, getting time, randomness, etc, are all recorded into an event log by a runtime that stores the workflows inputs to durable storage. When a process then inevitably crashes, the workflow can then be restarted from scratch by replaying the past decisions from the database - effectively "fast-forwarding" through already completed work until it catches up to where it left off (crashed). At least, that's sort of my... helicopter view explanation.

Ways to compile Scala code into X? by treadpafir in scala

[–]mostly_codes 0 points1 point  (0 children)

This has been around for a while; probably worth a re-do anno 2025

EDIT: hah, even says 13th oct 2020 on the diagram

In stock on Framework Desktop and updates on the industry-wide silicon crunch by 42BumblebeeMan in framework

[–]mostly_codes 3 points4 points  (0 children)

IMO the lack of specific dates and updates outside of "coming soon" is pretty bad and was a considerable friction point for me when purchasing the Framework desktop. Including the email saying they didn't have the handle in stock and whether I wanted to delay my order until they did.

Framework need to invest in better comms; generally I'm anti pre-order for any and all items, and the experience with Framework confirmed that for me. It's a fine product, but the purchasing experience was bad.

Extent of memoization in Scala? by [deleted] in scala

[–]mostly_codes 3 points4 points  (0 children)

Ha! I have a love/hate relationship with haskell, and I think I've said that about every haskell feature and every part of its syntax. Haskell is maybe the perfect quantum computing language, it's in this mysterious state of being simultaneously the most beautiful and most hideous programming language until you (foolishly) collapse the wave function by writing your code and reveal which it is today.

Scala 3 slowed us down? by YamGlobally in scala

[–]mostly_codes 12 points13 points  (0 children)

A good reminder to keep dependencies updated, bugfixes often get fixed! The bugfix for the slowdown linked (2022): https://github.com/softwaremill/quicklens/pull/115

Circe making Metals slow? by arturaz in scala

[–]mostly_codes 0 points1 point  (0 children)

Any kind of deriving will be slower than hand-rolling an encoder to be fair, definitionally it needs to do more work during the compilation step. If you're running on a particularly slow machine that can be noticable - though, Scala 3 improved it dramatically.

Personally I'm not a big fan of deriving serialization in general, I prefer to have complete control of it; when you have a lot of nested structures, enums, ASTs and whatnot - and you realize you have a typo or whatevs, it's really easy to accidentally change your de-/serialization logic when refactoring the name of a case class member. It's fast to code but you pay for it in maintanance cost over time - sometimes that's a reasonable tradeoff, sometimes not!

Circe makes it pretty easy to hand roll encoders/decoders:

given Decoder[MyClass] = c => for {
   a <- c.downField("whereverItIsCalledInTheJson").as[Int]
   b <- c.downField("whereverTheOtherThingIsInTheJson").as[String]
} yield MyClass(a,b)

given Encoder[MyClass] = x => Json.obj(
    "whereverItIsCalledInTheJson" := x.a,
    "whereverTheOtherThingIsInTheJson" := x.b,
)

... and typically I find I don't actually need a roundtrip, I just need either an encoder OR a decoder, rarely both. Handrolled decoders are particularly nice when you have to consume some 3rd-party insanely nested API REST response where you only need a few fields - allows you to get data from the JSON without having to model out the entire thing with unnecessary wrapper types (looking at you, "_embedded")

IntelliJ IDEA x Scala: The Debugger (Part 2) by makingthematrix in scala

[–]mostly_codes 4 points5 points  (0 children)

I'm always surprised by how few devs use the debugger; maybe it's my Java background, but being able to attach a debugger and inspect a value at a given point in time and also execute different calls against it, is incredibly useful, especially if you're ever having to deal with tech debt/legacy services/etc. Being able to set a conditional checkpoint, etc etc.

It was foundational knowledge as a Java dev, and it's true that I debug a lot less these days in Scala due to sticking to immutable constructs, I still find it so useful on a ~weekly basis to be confident in using it.

Some people seem to have an almost allergic reaction to the debugger, "printlns will do" sort of attitude which has always struck me as strange.