sideeffffect

The official VS Code extension from Oracle with an LSP server:

https://marketplace.visualstudio.com/items?itemName=Oracle.o...

If you're interested in this, then you should check out https://github.com/golemcloud/golem

Golem is a durable workflow platform and can run any wasm.

Or maybe you can solve it like I did -- by using a font that does the (IMHO) right thing with regards to ligatures

https://github.com/0xType/0xProto#4-ligatures-that-dont-defo...

I can't recommend 0xProto enough, the only thing I'm sorry about is that I didn't find it sooner :)

React Native Skia seems abandoned. But maybe this will make React Native on Linux viable

https://github.com/gtkx-org/gtkx

https://reactnative.dev/docs/out-of-tree-platforms says otherwise

React Native Skia allegedly runs on Linux too

If you'd like to see Bob Harper's take on programming languages, have a look at the short video series Practical Foundations for Programming Languages

https://www.youtube.com/playlist?list=PL0DsGHMPLUWVy9PjI9jOS...

How does programming with Clojure targeting multiple platforms (JVM, JS, CLR, LLVM, ...) work?

Are there Clojure libraries that don't use JVM(/JS/...)-specific stuff that works on any Clojure platform/dialect? Can such libraries be used on Jank out of the box? Or do library authors have to do something explicit in their libraries to enable their use in specific platforms/dialects?

I doubt it. For Capture Catching of Capabilities to work, you need some of the unique sauce practically only Scala has. E.g. Contextual functions or path-dependent types. Java almost certainly won't adopt these.

The first five points are fixed by using Mill

https://mill-build.org/mill/comparisons/why-mill.html#_perfo...

Go has proven that people want cheap threads. If it didn't have it, it wouldn't get anywhere.

Now even Java has cheap threads (Loom).

And Go even has generics. Just 20-ish years later than Java. And it's likely that more features that now Java has will trickle into Go. If Go wants to survive.

All this to say that there is no space in the market for another language which is a stupid simple Algol. Go already occupies that space. And even Go will have to add features developers want/need, if it doesn't want to get cornered out of the market.

It's not only Scala that must evolve.

All these languages may work very well for many people for the described use cases.

But one of Scala's strength is versatility. You could use it quite well for all the listed use cases too. With just one language. (Maybe with the exception of system programming -- Scala Native still requires a tracing GC.)

Also, it's worth noting that Scala is more popular/mainstream/supported/has bigger community than Julia, Zig and Elixir / gleam. And if Red Monk is to be trusted, even more than Rust https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2... That comes with many benefits.

> if you don’t need JVM / Java interop

OpenJDK is also very good, even if it's not a strict requirement to use it. Battle-tested, easily debugable, etc... AOT compilation is possible via GaalVM's native-image.

Or you can try Scala.js or Scala Native (which don't have anything to do with JVM).

> But something happened

Oracle started heavily investing into Java. And Google picked Kotlin as the language for Android.

But Scala hasn't stagnated since. And as the blog post suggest, plans on moving further still. For example, https://docs.scala-lang.org/scala3/reference/experimental/cc... may be one of the most impactful developments in the language's history.

> Compile times are crazy

This is also heavily influenced by the build too you use. Don't use sbt or Maven or Gradle. Use the good stuff. Use Mill.

https://mill-build.org/mill/comparisons/why-mill.html#_perfo...

Or Bleep, if you're feeling more experimental https://bleep.build/ .

I think the proprietary variant of GraalVM comes with more optimizations in the compiler.

But the AOT compilation (native-image) is available in the GPL community variant.

> Kotlin is also much more popular than Scala.

That's not what (at least some) numbers say. Both Scala and Kotlin are 14th.

https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2...

Kotlin may be more popular, but not much. It's nowhere near the mainstream languages like Java, Python, JavaScript, C# or PHP. Not even close to TypeScript.

Probably never. It's very slow to move.

Yes, Java has been getting a lot of features Scala has had since (more or less) always. But it's a continuing process, and not all such features are yet fully fleshed out and polished in Java.

Also, Java will probably never get many of important features Scala has (or will have). It may not be some esoteric things, like higher-kinded types. But things like meta-programming/macros. Or features which may be advanced from theoretical point of view, but are actually easy from user point of view (because they lead to a simpler code), like Capture Catching.

> > Another common request is to “stop implementing features”.

> Yes, it's a very common one shared by virtually all Scala 3 developers. Stop. At least for a couple of years.

I, for one, think Capture Catching can't arrive soon enough. It will allow us to write much simpler programs, getting an edge over modern Java & co. I'm very much looking forward to it.

Don't use experimental Scala features in production code. They may change or be removed. And they will likely lack support in IDEs. But that is a common sense.

> 1) The language is too unstable

Thankfully not anymore. They got their act together and have been maintaining compatibility since Scala 3.0.0 has been released in May 2021, which is almost 4 years and counting.

https://github.com/scala/scala3/releases/tag/3.0.0

Scala 3.x is to remain compatible for the whole 3.x series (think of semantic versioning). There's no Scala 4 (breaking with Scala 3) in sight.

Also, Scala 3 and Scala 2.13 JARs are also compatible with each other, which helped with the transition.

> 2) The tooling around it is not the best

sbt may not be good. But Mill is much better than either Maven or Gradle. Especially Gradle. Bleep is also promising.

Scalafmt is widely used and liked. Scalafix -- the linter/fixer -- is used a bit less, but still of a good quality.

* Immutable-first

* Immutable/persistent collections in standard library

* Machinery to "modify" immutable deeply nested case classes/sealed traits. You have the copy method, you have lens libraries. Very easy and comfortable to use.

* Expression oriented. if/try/etc expression can be bound to a variable

* less characters to write the same idea/program, while not losing readability

* better tooling: Scalafmt is ubiquitously used, supported in IntelliJ and is very good. Scalafix (a linter which can also fix some issues automatically) is used a little bit less, but is also good.

* build tools: while I don't like sbt, Mill is a so much better build tool than Maven or, even worse, Gradle. Then there is also scala-cli, which is not a build tool, but can work like it, if you have a simple, single-module project (i.e. no sub-projects/sub-modules).

I think it's actually used more to develop more or less ordinary backends. Or some tools/frameworks like Spark or Akka/Pekko.

But you can (and people mostly do) use Spark from Python. And Akka/Pekko from Java (but I'm not sure how that is common).

And the job market is there:

https://functional.works-hub.com/jobs/?remote=true&tags=scal...

https://scalajobs.com/locations/remote/

https://remoteok.com/remote-scala-jobs

https://betterremotejobs.com/search?title=scala

https://readytotouch.com/organizers/scala/vacancies?remote=1

https://www.levels.fyi/jobs?searchText=Scala&workArrangement...

https://www.linkedin.com/mwlite/search/jobs?keyword=Scala&lo...

https://discord.com/channels/629491597070827530/629546253381...

https://discord.com/channels/632277896739946517/840255868096...

> Clojurescript for frontend, Rust for portability

If Clojure and Rust work well for you, more power to you. But at least in theory, you could very well use just Scala for these purposes

Scala can compile to JS https://www.scala-js.org/ if you target frontend.

And if you want portability, you can compile a Scala program with GraalVM's native-image and statically link everything with musl libc https://www.graalvm.org/latest/reference-manual/native-image...

And if you want both frontend and portability everywhere, Scala will soon have a support for compiling to WASM (with WASI, etc) https://github.com/scala-wasm/scala-wasm/ (to be integrated into Scala.js after developed)

> Shapeless breaks everything so casually.

Thank goodness that Shapeless is not needed in Scala 3. The good parts have been integrated into the language itself and so it's reliable and faster.

> Jetbrains had completely abandoned Scala

Thankfully not at all. Gets regular releases, Scala 3 support is improving with each. They're also welcoming to PRs, if you have spotted a bug that needs fixing. (The codebase of the Scala plugin is in Scala, so that makes it easy for the community to contribute.)

Java has certainly improved. Kudos to its stewards.

But I think it still has many rough edges -- things that are awkward (or outright impossible) to do in Java and Scala is great. It doesn't have to be advanced features, like meta-programmig/macros. Here are some example that I think are not anything esoteric:

* Just the mere fact that Scala has immutable/persistent collections improves how and what programs people write.

* Scala also has good infrastructure to deal with "modifying" data model graphs in a persistent/immutable way. Think deeply nested case classes and sealed traits. You have the copy method, lens libraries, etc. Java does have records and sealed interfaces, but all the rest of the machinery to work with them is still missing.

* To generalize the points above, Scala is immutable-first language, with all the positives that come with it. Java, still not so much (even though they are moving in that direction, e.g. `record`s).

* Another weird thing in Java is how it deals with variance. In Scala, I find it easy to comprehend, in comparison.

* Scala is expression oriented. Ifs, trys, etc -- all of them are expression. You can bound the result of these expressions to a variable. Not the case in Java, which makes it annoying to work with. You have to fist make the variable null or something and then make sure it gets assigned within of the body of the if/try/... Just a bad experience :(

Than there is a matter of culture:

* Java libraries like to return (and expect to be passed) a `null`. Scala culture embraces `Option` from its standard library.

* While Java does have support for checked exceptions, which I think is a very good idea in theory, in practice its implementation is underwhelming (e.g. not possible to abstract over) and so libraries don't use it as much. With Scala you can return an `Either`. Or with new Scala 3, we may soon have powerful capability system to, among others, allow throwing "checked" exceptions. That's the Capture Checking https://docs.scala-lang.org/scala3/reference/experimental/cc... research.

* This may be even more personal opinion that others, but I find Java libraries more difficult to use that Scala ones. With Scala, you just follow the types and you create and work with the objects that the library gives you in an intuitive way. With Java, the types don't help you as much. You have to read the documentation thoroughly, to make sure you're calling the right methods on the right objects, in the right order. Because the types don't help you, you can't be sure you doing it correctly, because every other way compiles too.

Very interesting. Have you already investigated where is Mill's overhead spent? What can be optimized in Mill to get its time closer to just invoking the javac? Do you already have a plan?

Why is it

./mill common.compile

and

./mill clean common

but not

./mill common.clean

?

I see. But no hope is lost! You can always lean on Scala. It runs fine on any Java >= 8 and it's great. Unless you intentionally used is badly (but you could say that about any language).

> Java is generally fine enough, but it's a little annoying when I have to do whacky workarounds with wrapper classes to get something that would be done in three lines

This is a weird take, given that Java has had ADTs for years

Records https://en.wikipedia.org/wiki/Java_version_history#Java_16

Sealed classes https://en.wikipedia.org/wiki/Java_version_history#Java_17

And pattern matching for almost a year https://en.wikipedia.org/wiki/Java_version_history#Java_21

Otherwise big agree on how delightful to work with F# is.

People are already working on this

https://leandojo.org/

https://machine-learning-for-theorem-proving.github.io/

https://www.youtube.com/watch?v=P5ew0BrRm_I

https://paperswithcode.com/task/automated-theorem-proving

https://old.reddit.com/r/math/comments/11mb9lx/future_of_aut...

https://github.com/RiccardoBiosas/LeanGPT

I don't mean to be snarky in any way. I think this is actually great development.

But isn't this just good old inversion of control, modularity with maybe some inspiration from Functional Programming. Or even more generally, good Software architecture and engineering?

Anyway, I'm very happy to see this, the more code is architected this way, the better for all our industry.