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 :)

Going to give this one a try; I'm still partial to Atkinson hyper legible, but this one looks fun.

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

React Native Skia allegedly runs on Linux too

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

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

React Native Skia last commit is three years ago.

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?

> 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?

Correct. Any Clojure code which doesn't use interop will generally work with Clojure, ClojureScript, Clojure CLR, jank, etc. There are some exceptions, where different dialects don't fully implement a Clojure feature, but this is generally the case.

> Or do library authors have to do something explicit in their libraries to enable their use in specific platforms/dialects?

Clojure also supports reader macros to enable forms for specific dialects. This is basically like an #ifdef in the C world, where library devs can check if the code is currently being compiled for Clojure, ClojureScript, jank, and so on. This allows you to have a public function, for example, which internally just uses a reader conditional to do the correct thing. For example:

    (defn sleep [ms]
      #?(:clj (Thread/sleep ms)
         :jank (let [s (/ ms 1000)
                     ns (* (mod ms 1000) 1000000)
                     t (cpp/timespec. (cpp/long. s) (cpp/long. ns))]
                 (cpp/nanosleep (cpp/& t) cpp/nullptr))))

That's using the currently working C and C++ interop to call the POSIX C function. The same could be done for the C++ version. This function can now be used in both Clojure and jank with no difference to the consumer.

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

Each variant has its own file extension, e.g. .clj for JVM and .cljs for JS.

In case you're writing code that needs to work on multiple platforms, you put it in a .cljc file. Any of the code in these files that still needs to be different due to the platform choice is differentiated inline using a reader macro, which results in the different platform compilers getting a (slightly) different abstract syntax tree, so it is not too dissimilar from writing cross-platform code in other languages (just more convenient due to the Lisp style).

But it doesn’t confirm improving the speed of the compiler at all. Looks like the trend is flat.

This comment from Odersky also says that Dotty was not automatically faster than 2.12: https://news.ycombinator.com/item?id=16884317

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.

Go has proven that we still need the backing of large corporations for success in the tech world despite the fact that open-source powers most major tech companies today

Java needed Apple, Go needed Google, React needed Facebook, TypeScript needed Microsoft, etc

In this way Rust is actually a pretty unique success story in that there's no singular major tech firm pushing it

> Now even Java

Java is one of the few languages that does have it, besides Erlang, Haskell and Go. That "even" is absolutely not warranted.

> Now even Java has cheap threads

If by "cheap threads" you mean M:N threads a.k.a. fibers/green threads, Java had that on Solaris well before Go.

That's not even remotely the same thing as the current virtual threads, that automagically turn (many kind of) blocking IO into non-blocking.

If "automagically" means "the way Golang does it" then that's kinda the whole point of M:N threads/fibers.

My point was that green threads are not at all the same as virtual threads.

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).

>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.

I think that the jack of all trades space is already occupied by C#.

It's not a field that could be occupied by a single language.

> 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/ .

This isn't actually true - and I'm a mill enjoyer. Mill is roughly as fast as SBT in terms of compiling your project. See the mill x sbt comparison.

https://mill-build.org/mill/comparisons/sbt.html

SBT does suck for other reasons, however.