I haven't used it heavily but one of our newer microservices uses Quill for read-only access to Postgres. I have found it to be great to work with, to combination of "just use case classes" and a DSL that feels like writing SQL is pretty nice.
From a political perspective, yes for sure. From a technical perspective, less so. The Cats ecosystem and ZIO are meaningfully different with their designs that the two evolving separately isn't so bad in my opinion.
The Scalaz/Cats schism was worse in the sense that they were largely the same (at least at the time) which led to a lot of duplicated effort.
I like ordered UUIDs, but if you care about 100% strict and accurate ordering you need to be careful about generating them in app code vs. on the DB side. With the former + using multiple app servers, server clock drift can become an issue. Which is why I still generate my ordered UUIDs on my Postgres server. It means writing some funky PL/pgSQL (or however you decide to do it... I think you can run Python too), but it gets the job done.
I wish ordered UUIDs were built-in to more DBs natively. I remember seeing UUIDv6 being proposed, but I don't know if/when that will be standardised.
There's probably a nicer way (or more performant at least), but I created a function that uses the built-in `uuid_generate_v1mc` and then reverse the order of the time component so that high values come first.
Personally, being able to solve problems with the abstractions you can achieve within the language over adding very specific language features to solve them appeals to me more.
I often see comparisons to Go, Kotlin, Rust, etc, and I agree that it's unlikely for Scala to have a second renaissance and have an steep upward trajectory like those languages, but is that really a death of a language? I'm actually fine with Scala narrowing its scope and focus at being really good at just a couple of things. Such as embracing its FP-side more so than its OO-side. Not to say there is no value in its OO-side (I still see some value there mostly pertaining to modules). But I just mean that not every language needs to aim to be a top 5 language. FP and advanced type systems still seems to alienate a significant percentage of programmers for various reasons. That's fine. It's not like that sentiment is going to change overnight.
Scala missed its opportunity with Android. I think you just have to concede that to Kotlin at this point and just focus on moving in a direction that is not occupied. Which is why I mention FP with a strong focus on types. There's not much competition there besides Haskell. And since Haskell for the JVM will likely never be a thing (a few have tried, but none have gained traction), Scala is still there. And with the direction Scala 3 is going and all the improvements it brings, it's actually looking quite positive. At least in my eyes.
And besides, I don't think Scala has to be a "worse Haskell" in everything that it does. I think ZIO is a good example of a great Scala library that actually resulted in something really special by embracing what Scala can do:
https://zio.dev
I agree with almost everything you're saying. I'll just add that while Scala missed it's opportunity with Android, the big problem has always been a borderline dogmatic approach to pure FP by the community at the cost of simplicity. Scala libraries are generally complex and difficult to use (sometimes even for Scala engineers with several years experience).
Also, core FP principles are not that hard (immutability, expressions, HOF, functional error handling, pattern matching), but when you go full / pure FP, that is a steep cliff and an end goal in itself that has serious time /monetary/ complexity costs. The real goals should always be a healthy balance of reasonably fast business functionality delivery and a good code base.
There is that, yeah. There was a lot of translating things from Haskell to Scala 1:1, and that didn't always work out so well. Well, actually it does mostly work on a technical level, but with heavy costs when it comes to ergonomics. The implicit imports and poor type inference was enough to cause frustration within our team.
That's why I specifically mentioned ZIO. Things improved greatly after migrating to it. It feels like it plays to Scala's strength. It infers well and we don't have a single implicit import to make it work. Well, with the 1 exception of the optional Duration syntax so that we can write "5 seconds" instead of "Duration(5, TimeUnit.SECONDS)".
> But I just mean that not every language needs to aim to be a top 5 language.
I wonder about the extent to which this is true. One of my primary considerations in picking the language for a product is economic fit. Once you get outside of the top 10 or so, I think you need an especially strong set of niche-specific positives to offset the negatives of a small community.
As an example, for fun I've been working on a mobile app using Dart and Flutter. They are clearly targeting the niche of "mobile app developers who want to be cross platform and don't really care about it being a perfect iOS experience". Which is a pretty big niche, and Google has invested a lot in the platform, so I'm enjoying it. But library support is about 10% of what I'd want, so for things where in Python I'd have a few decent packages to pick from, in Flutter I'm often deciding between an under-maintained 0.0.7 and rolling my own.
If I were doing this for real and with funding, this would at least be a risky bet. Maybe we save 20-40% on our mobile dev costs and , maybe we get screwed by Google's fickleness and have to rewrite everything. Does that offset the extra recruiting and ramp-up time costs? Are good mobile devs willing to work in a less marketable language? Will Google dessert-topping-and-floor-wax it to death in service of internal political goals? Etc, etc.
Scala's in a similar bucket for me. I tried it out and liked it well enough. It's certainly reliable; I wrote my home lighting system in it and the only failure I've had in 3+ years was when Kubernetes shat the bed. But I'm of a similar mindset to Eckel on this: when it's good it's good, but it has a lot of cliffs that I found it very easy to stumble over. [1] Add on top of the hiring problems, and I'm wondering in what niches the economic case is strong enough. Especially so if it's going to keep dropping in popularity.
> > But I just mean that not every language needs to aim to be a top 5 language.
> I wonder about the extent to which this is true. One of my primary considerations in picking the language for a product is economic fit. Once you get outside of the top 10 or so, I think you need an especially strong set of niche-specific positives to offset the negatives of a small community.
I think you have to take into account the ecosystem in that equation. Scala may have less than 5%
programmer mindshare but it has access to the massive Java ecosystem underneath. So languages
like that I think get to be viable at a significantly lower threshold than languages that
require the whole ecosystem to be built from the ground up (even if that is mostly by
writing wrappers that FFI to C libraries). The risk is heavily mitigated by that as well,
as a retreat back to Java from Scala is far more doable than from say, Go or Rust
to Java if things turn sour.
Scala is disadvantaged by the fact it philosophically departs from the
Java ecosystem (in terms of FP, HOF, etc), because
that pretty much ruins the interop story backwards into Java (that is, without effort,
your idiomatic Scala code / library is not going to be accessible idiomatically to Java
programmers). This is unlike Kotlin and Groovy both of which are built
intentionally to fit smoothly into the bigger Java ecosystem (although Groovy is more
so than Kotlin).
Good point on the ecosystem. That definitely makes Scala more viable. I know I never would have tried it without that. Although I think that applies more to runtimes and (some) libraries than what I think the real drivers of cost are, like hiring and a community of practice (e.g., forums, mailing lists, and the likelihood of having the SO answer you need in your first few Google hits). And I think there's still a tax there; if you're doing a lot of Java interop you'll still have to know Java and the quirks of dealing with it from Scala.
Of course, there could be special-purpose stuff that's very nice not to have to rewrite. PDF generation comes to mind, as it's an enormous pain in the ass, and there are some good Java libraries for it. But it's often not much more work to encapsulate something like that as a service or a CLI tool.
Not to say people shouldn't do it, of course. But I'm not sure what Scala's niche should be as it shrinks. I originally saw it as a better Java, but I think Kotlin did a better job of is winning there. I get the impression that Clojure is doing better at "functional language on the JVM". Which is already a niche inside the FP niche. And given how much other languages have been learning from functional approaches, I don't know whether that niche is growing. I look forward to seeing if they find one.
Yes, I agree with you, I think it's niche is probably going to shrink away from the "better java" and enterprise space but will probably hold up in the data science space as the only real counterpoint to Python for large scale distributed data processing. For people who for whatever reason want to use the JVM, or who need language performance that can't be achieved with Python, there isn't really anything else in the data science space to compete with it.
The killer problem for me is that you can't write a good library in Scala and have Java users adopt it. Because it uses its own collections etc, unless you build highly non-idiomatic Scala code, you will always end up with a huge impedence mismatch there. So while you can use libraries from java, you can't contribute to them, and your audience is always limited. Contrast with Kotlin or Groovy where you can write idiomatic Java-consumable libraries much more easily (esp. Groovy).
What is the story with Scala on Android? Years ago I thought it was a matter of using too much memory. There’s not much talk about it but it does seem to be possible:
As the person who was involved in Scala on Android (and particular in creating the website), I'll chime in with this:
What sunk Scala on Android was largely the completely lack of interest from the core team.
Everything that Scala on Android achieved was pretty much _despite_ the actions of Scala's upper echelon.
- It's hard to get a good message out, when core members spread FUD by bringing up problems that were solved year ago (like the big std lib issue).
- The core team's perception of Scala was always inward – new platforms existed such that Scala developers could run their code in more places, not because it could attract new developers from these existing ecosystems to Scala.
(Scala.js partially overcame this by herculean efforts of individual members of the Scala.js community that got the word out to the JavaScript world about Scala.js.)
- Core Scala pulled the plug from Android support in the backend. So Scala on Android was pretty much left to die on an outdated Scala version.
- Something like TASTY (an interchange format that can be recompiled on the fly to target new backends), which could have dealt with the problem above – was promised for years, but still hasn't shipped.
- The core team was against even acknowledging the existence of Scala on Android on the website – good luck in convincing that Scala on Android works, if the official website/documentation doesn't mention it with a single word.
- Core Scala treated the main contributor with so much public disrespect, that I'm still surprised he didn't outright quit back then. It takes balls to publicly blame the main contributor of Scala-on-Android for not working on the project full-time, but also conveniently managing not to tell him this crucial "requirement" for half a decade. And with "full-time" I mean "unpaid full-time".
It's a sad story, because Scala-on-Android shipped with some amazing features like hot-code-replacement years before Google managed to ship it. The typed resources stuff was also pretty impressive.
I don't know the whole story. Perhaps somebody who knows can chime in. But my impression is that Android being stuck basically on pre-Java 8 at the time while Scala relying heavily on Java 8 features was one complication. Scala generating a bunch of class files for lambdas and so on with no SAM types + invokedynamic to reduce all that plus strange DEX limitations might have caused issues. Plus memory limitations like you said.
I'm not sure there are any real blockers for Scala on Android anymore. I imagine it's mostly a resource problem now. With Kotlin's momentum in that space though, I'm not sure too many people are calling for it anymore. Who knows though, maybe after Scala 3 is finally out the door priorities could shift.
From a few years ago, with Scala 2, but the fundamentals may not have changed much.
Scala had, and has, a large bespoke standard library, which is big enough that if you tried to ship it with even a trivial app, it exceeded limits not just on memory, but on numbers of classes, methods, and so forth. (And even if those limits have been raised on newer phones, older ones are still a nontrivial market segment.)
So the way people got around that was by using "tree shakers", which would grovel through the app and its libraries, and chuck out portions of the library which weren't actually used. This works, but significantly complicates the development toolchain.
Between that and the official support for Kotlin as the "better Java" dialect of choice, you have to really like Scala to make it worth the effort...
> And since Haskell for the JVM will likely never be a thing (a few have tried, but none have gained traction)
It's more than social reasons. The JVM has technical limitations that ruin idiomatic Haskell. Lack of a mechanism for efficiently and modularly compiling general tail-call elimination.
For instance, if you traverse too long of a list, you'll blow your stack. You can try it and fail yourself with Eta.
FP in Scala has the same issues, but they have some extra utilities to work around it, but it's something you gotta be aware of.
One of the biggest complaints that I've had about Scala is it's community. They've made huge strides to make political statements and gatekeep who contributes. (The core team makes it worse for John De Goes (He's the guy that was either the creator or a big contributer with scalaz and zio) at every turn and it's really annoying)
F# is quite nice. I used it a long time ago for a couple of libraries when I was working in a team that mostly used C#. Fable looks really cool too.
I remember getting the feeling that C# is holding it back though. F# can't have any feature that it wants because interop in both directions seems to be a priority. If I recall correctly, that's what is holding back higher-kinded types in F#.
That, and the last time I tried F# on .NET Core things were still very rough. This was when .NET Core was still fairly new though. It might be fine now.
not as much C# the language, as CLR, the runtime. Because of reified generics, which is the way things are done in the .NET world, and which the runtime needs to support, it would also require explicit support in the runtime for Higher-kinded types or Type classes. And that won't happen without C# having these features (and having them first).
F# is really really great, but it is like an unwanted child of Microsoft :(
Not too sure about the case in the article and if relates exactly, but it made me think about spaced-reptition systems. I aim for a 80-90% success rate as I've found that to be the optimal range (arrived at that after doing this for 10+ years now with varying settings).
While I wouldn't say it's THAT significant, there is one other advantage to fixed-width fonts that I've experienced. Due to the fact that they align vertically, sometimes they expose mistakes if you're constructing data in a table-like fashion. Or when you have a bunch of copy/pasted lines that differ only in the parameter values. Like, "Hey wait a minute... this line is 1 char wider than the previous one. Oh, whoops, I fat-fingered something there".
I wish I had more specific examples and could quantify it better, but I know I've caught quite a few errors this way.
This exactly. Most recently I had a script that was calling functions with fixed width data sets (IDs, credit card numbers, birthdates, etc..), and typos were significantly easier to find due to the data and fonts both being fixed width.
This is because we don’t have any decent rich formatting options available for code in a plain text file. You could totally find those errors in an excel spreadsheet, and excel doesn’t default to using fixed-width typewriter fonts.
If you're on iOS and in the affected area you should have received the alert.
If you're on Android you might need a device sold in the Japan market to get them (seems there are mixed reports on this, would love to hear from someone in the industry - does this stuff use standard GSM features and are these enabled on Android by default? could weird manufacturer skins disable them?).
You also need to be in the affected area to receive the message, although third party apps often let you customize the range or priority of messages to receive.
On my US-sold iPhone running on an MVNO I reliably receive earthquake/flood alerts. But I didn't receive the alert this morning since I live in the other end of the country where it was not broadcast.
Interesting, I assumed it was the carrier, but it might be the model. I have a Galaxy S7 which I got in Hong Kong. With this variant, I can't find the emergency alert settings anywhere. That might explain it.
Devices on MVNOs can still receive the alerts as long as they're set to receive. You'll have to dig around in the settings for it, but it should be on by default. If you got it through Yahoo though, probably no need to worry since you'd just get duplicates...
If they're limiting APM to that of human levels, I don't see it being much of an issue though. APM would just be a limited resource like any other. In fact, I sort of want to see how a strong AI would choose to spend its limited pool of actions. How different would it look compared to a pro? Maybe not much, but I'm not actually certain.
In SC1, just the act of moving a large army is a commitment and takes quite a few resources. Moving your armies under fog of war and not letting your opponent know exactly how you're set up in order to get a good angle on you is incredibly important. I want to see how much of an importance a great AI puts on that vs the other things it could be doing instead. Are the strongest AIs going to be more methodological, safer, and slow moving? Or will the best AIs try to exploit the imperfect information aspect of the game and try to lure the opponent into making a wrong decision? I feel like AIs tend to excel at the former, but the latter has been a huge component for the very best pros in SC1.
I don't follow SC2, so I don't know much of this also applies there. I just feel like SC1 isn't as mechanical as it's made out to be. There's definitely that huge initial barrier, but once passed that, the game actually feels very delicate and is about good use of resources (including mouse/keyboard actions), timing, and transitions in unit composition to catch your opponent off-balance.
Personally, I think focusing on BW would have been more interesting (as long as the APM limit still stands), but I guess SC2 is alright too. The fact that they're even doing this though makes me happy.
The reason I say BW would be especially interesting is simply because the game has remained basically unchanged balance-wise since v1.08 which came out in 2001. Despite that, the pro scene never left, and we're still seeing some shifts in the meta even today. It would be cool to see a strong AI flip the script completely for such an established and "well understood" game. Opportunities like that are kind of rare, at least when it comes to video games.
Having said that I think Quill looks nicer (https://getquill.io/) if you want a DSL like that.