- None of us are experts in Rust, and we're all solid at Python.
- Rust felt like an under-correction for what we wanted (get all friction in front of the LLM out of the way).
- Our high-performance stuff is not being migrated at this time (Scarf Gateway), so we're just talking about basic CRUD backends here. Basically any language will work.
Whereas Python just interprets and gets off to the races.
Feels like we had this discussion years ago as humans..the false promise of dynamic languages.
it's a shame scarf is struggling so much they are pinching pennies :/
you don't need to be, you can learn Rust or whatever way-better-than Python language as you use it with an LLM! it's an amazing process.
On the contrary, for a small rust project, I had to clean out 180gb of cargo nonsense from the last ~3 days worth of compiles on a single, narrowly focused topic branch.
The library situation might be funky, but I'm also learning Lean 4 by hand. The tooling & lsp integration is lovely.
I also went through quite a process to select a language to work with LLMs[1] before settling on OCaml.
I am not unhappy with the choice and find it works quite well, with relevant skills loaded, but I am always interested in others’ experience and understanding what they’ve discovered works well.
I have a pretty elaborate harness setup, I use my own spec DSL to plan and execute code. So what works for me may not totally apply to others.
I haven't used the frontier models in a few months, so I can't speak at all to this latest batch. When I switched over from frontier I found that what I lost in training data, I more than made up for with Pi harness.
Your process seems more thorough than mine. Mine was literally "I like camels". Switching over to OCaml I found wonderful - I had not worked with FP before and I found it delightful, it kind of cured my programming burnout a bit. I hand built a CRUD app in OCaml/Dream but still feel like a rank beginner, especially when it comes to actually writing code, lol. But I'm getting much better at reading it.
I think the typing and structure of OCaml is a great fit for LLMs, but also the proximity to other things like DSLs, formal proofs, and algebraic structures has tons of untapped potential.
I'm having an absolute blast with it. I like programming again.
I read the second paragraph of linked article as saying close to the opposite of that, particularly,
"the model can often avoid the mistake before the compiler ever sees the code. And as the models get better, the relative value of catching every possible issue at compile time changes."
In other words, LLMs are much less likely than humans to make dumb, fat-finger mistakes, and, when they do, are able to catch and fix them more quickly, ergo the value of type checking has fallen.
Everything in the prior sentence is, obviously, highly debatable. But it felt like part of the premise.
All of these I run in a cli that has automatic LSP in it so that's a huge factor too. The agent is automatically told when there would be compile time errors as well as linter issues.
I would also add Kotlin, Clojure and F#.
Scala not really as the compilation is not much better, and since the Scala 3 reboot, the ecosystem doesn't seem to be doing that well.
The market opportunity for Haskell on the JVM is gone, although they are doing cool stuff with capabilities.
IMHO there are a bunch of reasons
* Scala 3 was a Python 3-esque disruptive event
* Perception as an overly-complex kitchen-sink inclusive language
* Kotlin took up the "better Java" mantle
* Rust became attractive to devs not committed to the JVM
* Go became less sucky
* SBT is disliked and Metals was buggy and unstable (and still slow)
* Suffers from the "we won't be able to find devs" problem where Kotlin, Rust and Go don't
* A bunch of community drama drove some devs away to Rust
I say this as someone using Scala 3 with ZIO effects system and Mill build tool and thinks it is fantastic.
In the past it was lot of selling points that business could see:
- 'better java' - more velocity over java without loosing anything
- 'type safety / FP' - less errors that cost money in production (backed by 'Typesafe/Lightbend' company)
- 'akka' - platform for distributed/concurrency applications (in pre kubernetes era was big demand for it)
- 'spark' - initially Scala was only way to use it fully
- 'twitter' - startup success story
- and few more
But now nothing from this list has any real meaning for peoples making decisions currently.
Kotlin actually suffer from this too as 'better java' not that big deal when java constantly improving.
There were other breaking changes as well.
https://docs.scala-lang.org/scala3/guides/migration/compatib...
This naturally broke all the tooling.
Then you have Metals for VSCode InteliJ plugins, while the Eclipse plugin was dropped.
InteliJ plugin is much further than Metals, however there is the conflict of interests with pushing Kotlin instead.
Meanwhile most Scala shops have pivoted to also give feature parity on modern Java, and Kotlin, thus reducing the interest in using Scala in first place.
However as mentioned, they are doing cool stuff with capabilities at EPFL for Scala 3.
https://virtuslab.com/blog/scala/introduction-to-scala-3-che...
PS The Scala team should have been fixing their type inference engine which lacked some important features and needed a better (Horn clause based) architecture. They did a complete rewrite instead.
*https://signalsandthreads.com/performance-engineering-on-har...
At least from the sidelines, it looks like they've built/forked most parts of the OCaml ecosystem to make it work (OxCaml, Dune was built by then, custom profilers, custom networking hardware, etc).
Of course a lot of their work is open source and can be used, but I wouldn't assume that it would be worth the effort to do something similar with OCaml yourself. Maybe it is! LLMs go brrr and all that.