-
GraalVM JDK19 dev builds are available at https://github.com/graalvm/graalvm-ce-dev-builds/releases/la....
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
I would use Scala. I like FP and Scala comes with some awesome libraries for concurrent/async programming like Cats Effect or ZIO. Good choice for creating modern style micro-services to be run in the cloud (or even macro-services, Scala has a powerful module system, so it's made to handle large codebases).
https://typelevel.org/cats-effect/
https://zio.dev/
The language, the community and customs are great. You don't have to worry about nulls, things are immutable by default, domain modelling with ADTs and patter matching is pure joy.
The tooling available is from good to great and Scala is big enough that there are good libraries for typical if not vast majority of stuff and Java libs as a reliable fallback.
-
I would use Scala. I like FP and Scala comes with some awesome libraries for concurrent/async programming like Cats Effect or ZIO. Good choice for creating modern style micro-services to be run in the cloud (or even macro-services, Scala has a powerful module system, so it's made to handle large codebases).
https://typelevel.org/cats-effect/
https://zio.dev/
The language, the community and customs are great. You don't have to worry about nulls, things are immutable by default, domain modelling with ADTs and patter matching is pure joy.
The tooling available is from good to great and Scala is big enough that there are good libraries for typical if not vast majority of stuff and Java libs as a reliable fallback.
-
1. Library creators do not want to have to deal with the headache over managing multiple runtime libraries and also between sync/async. IMO this is going to make Rust's library offerings very fractured, to the point where we will either be stuck on a legacy runtime for a long time or the hype for Rust will sizzle out because it's too difficult to write good code
2. Tokio has the best support right now but Tokio is very difficult to write libraries for and may not be the best designed async library. Monoio looks like a very good design and may be the best option for web servers because you don't have to deal with Send and Sync.
3. This method usually works but for async they should have been more opinionated. Stackfull coroutines line [May](https://github.com/Xudong-Huang/may) would have worked best for 99% of the use cases and maybe there could be a separate no-cost async setup for embedded. But trying to have both under the same async paradigm is causing huge issues.