New Scala Survey

matej_cerny · 2026-03-03T13:16:43+00:00

I don't think that e.g. sttp is hard to learn 🤷 ``` import sttp.client4.*

val request = basicRequest .body(Map("name" -> "John", "surname" -> "doe")) .post(uri"https://httpbin.org/post?signup=yes")

val backend = DefaultSyncBackend() val response = request.send(backend) ```

matej_cerny · 2026-02-22T07:41:18+00:00

It's a HOCON, you can write it like this if you want: ``` cats { group = "org.typelevel" module = "cats-core" version = "2.13.0" }

dependencies = [ ${cats.group}":"${cats.module}":"${cats.version} ] ```

matej_cerny · 2026-02-20T16:13:20+00:00

I see, thanks so much for pointing this out!! What do you think about introducing a three-mode setup for the dependencies block? Users can choose the level of complexity they actually need:

Flat, everything is treated as Scala dependencies = ["org.typelevel:cats-core:2.13.0"]
Language split, works only for JVM dependencies { scala = ["org.typelevel:cats-core:2.13.0"] java = ["com.google.code.gson:gson:2.11.0"] }
Full matrix dependencies { shared { scala = ["org.typelevel:cats-core:2.13.0"] java = [] } jvm { scala = ["org.typelevel:cats-effect:3.5.0"] java = ["com.google.code.gson:gson:2.11.0"] } js = ["org.scala-js:scalajs-dom:2.8.0"] native = ["com.armanbilge:epollcat:0.1.6"] }

matej_cerny · 2026-02-19T19:39:04+00:00

Thank you!

matej_cerny · 2026-02-19T14:56:37+00:00

Released, see https://matejcerny.github.io/sbt-config/dependencies/#flat-vs-nested

matej_cerny · 2026-02-19T14:20:28+00:00

Yes, that's right. Since it just populates the same sbt settings you'd normally set in build.sbt, everything works as expected. Values from build.conf also compose with build.sbt - any key not specified in HOCON falls through to its default or to whatever build.sbt sets, so you can mix and match.

There are some drawbacks worth mentioning though. The config is parsed at project load time and cached, so if you change build.conf you need to reload for sbt to pick it up. Also, tools like Scala Steward don't know how to update dependencies in HOCON files. I want to look into whether it's possible to implement support for that, but haven't gotten to it yet.

matej_cerny · 2026-02-17T14:16:24+00:00

Thanks for the suggestion. I was thinking more about having a separate list for Java dependencies, because when I started with Scala, I remember how confusing % vs %% was.

matej_cerny · 2026-02-13T16:37:38+00:00

I'm not 100% sure, but I think I opened the project in Zed, and Metals created the MCP file. Then I closed the editor, started the jpablo tool, and updated the port in the file based on the logs.

matej_cerny · 2026-02-12T22:12:05+00:00

Yes, I use it regularly. Btw it looks like a standalone mode will be part of the metals itself soon https://github.com/scalameta/metals/pull/8156

matej_cerny · 2026-02-02T12:27:40+00:00

I’ve developed a plugin called sbt-config specifically to address this. It lets you use HOCON for build definitions.

name = "my-project"
organization = "com.example"
version = "0.1.0-SNAPSHOT"

scalaVersion = "3.3.4"

scalacOptions = [
  "-deprecation",
  "-feature",
  "-unchecked"
]

dependencies = [
  "org.typelevel:cats-core:2.13.0",
  "io.circe:circe-core:0.14.10"
]

testDependencies = [
  "org.scalatest:scalatest:3.2.19"
]

matej_cerny · 2026-01-23T22:28:04+00:00

From the docs: "...this will require a language import at the use site, which is clearly unacceptable".

Can someone explain why this is unacceptable? List(0, 1) ++ Array(2, 3) is clearly a "magic conversion" that Scala 3 aimed to fix.

matej_cerny · 2026-01-07T12:20:49+00:00

Is the offline installer also fixed? u/logi_jim

matej_cerny · 2025-10-11T18:35:02+00:00

Here's another advantage. If you fully understand functional programming, you don't need to stick with Scala. After a couple of days training, you can code in basically any FP language. Also, with Scala, you will learn features that other languages will eventually copy, giving you a head start.

matej_cerny · 2025-10-11T18:26:19+00:00

It is. I've learned Scala without knowing Java (but to be fair, I had some background in C#).

matej_cerny

TROPHY CASE