Serialization support has been coming for years, I lost patience.
Otherwise, yes, some support for expressions, some support for immutability, no support for optional semi-colons, no privacy modifiers so "_" littered everywhere.
I just found it to be an exceedingly ugly language when I used it a couple of years ago. Yes, some more pleasant modern functionality has been bolted on since then, but it's unfortunate that Dart was chosen as the backing language for Flutter, which is an awesome mobile framework.
Big turnoff with Dart is the lack of json (de) serialization -- kind of shocking to have to resort to source code generation libraries in a modern language.
Also, statement based instead of expression based, and not immutable by default are kind of a drag; not the end of the world but a bit unpleasant, IMO.
Looking at a Thinkpad 16" P1 Gen 8 with 2X 1TB SSD, 64GB RAM, QHD+ screen, centered keyboard like MBP (i.e. no numpad), integrated Intel GPU, lightweight (4 lbs) for a little under $2.5K USD.
Closest I've found to an MBP 16" replacement.
Have been running Dell Precision laptops for many years on Linux, not sure about Lenovo build quality and battery life, but hoping it will be decent enough.
Would run Asahi if it supported M4 but looks it's a long ways away...
This is indeed a sticky problem, one that usually requires a subselect or other workaround to address the non-determinism of group by + order by; i.e. one cannot simply "select * from employees group by role order by join_date limit 1" and be guaranteed to get the expected ordering.
Limited to a certain subset you most definitely could use the same statements (obviously not CTEs and the like).
Ideally you'd have a translation layer, so instead of writing error prone string-y SQL, you'd have a type safe DSL in the vein of LINQ to SQL, Esqueleto, Slick, Quill, etc. that generates approriate SQL based on the target driver. That way you write the same query once, with the same model, and dispense with the inefficient square wheel that is IndexedDB + javascript.
OT, but I was and am still pretty steamed that Mozilla spearheaded the effort to deprecate WebSQL back in 2010 [1], while providing a replacement that left many disappointed [2] (see comments in both threads universally deriding the decision).
The idea was that javascript libraries would be created that would replicate SQLite in the browser (albeit horribly inefficiently with terrible APIs compared to shipped-with-the-browser native C implementation that is SQLite).
Anyway, now that Firefox has become less relevant than ever with Microsoft's adoption of Chrome, I wonder if there's any chance that WebSQL will live on despite its deprecation? After all, it's still available in Chrome and Safari, which dominate the browser market.
IndexedDB is fine if NoSQL is how you store your data, but an absolute PoS if you want to work efficiently in a relational model with joins, grouping, etc.
Such a shame, every server-side language under the sun compiles to javascript now; imagine being able to share SQL statements between client and server; being able to aggregate data, count & sum with reckless abandon. Instead we have to do it all by hand in javascript, such a step backward [3]
The point is that most server languages these days compile to javascript. OCaml has Bucklescript, Haskell has GHCJS, Kotlin and Rust compile to JS, etc.
Clojurescript and Scala.js are probably the most mature, but getting developers to make the switch when their server language is not Clojure or Scala is an uphill battle. Case in point: I find Bucklescript to be absolutely amazing (generated binaries on par with size of hand written JS) but Scala.js is a better fit since I've been writing Scala for 6 years.
Clojure's not dying, but it's also not thriving[1].
I think it will continue on as a solid niche language for the foreseeable future, but it's highly unlikely that the language will grow by leaps and bounds barring some must-have innovation in the Clojure language and/or ecosystem that gets the tech world to take it more seriously.
There are so many options these days that it's tough to stand out from the crowd. Clojurescript, while interesting, is a dime-a-dozen with Elm, Purescript, Scala.js, Typescript, etc. all on offer, and with static types to boot. Also, Lisp itself is a tough sell, mainstream adoption isn't in the cards without a major paradigm shift.
Unlikely you'll be cranking out a Rails style MVP in Scala + Play, but you will produce a robust, blazing fast, scalable application that's a dream to maintain and build upon.
In short, Play is a really, really good MVC framework. For SPAs you can go lightweight with just Play's router and WS api, or try something like http4s for a more FP-based REST api.
Throw Scala.js into the mix and you've a got a fully typed stack across the board.
and then Scala Native on the horizon...things are looking good in Scala land ;-)