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.
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.
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.
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.
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.
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)".
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.
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
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.
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.
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.
The fact that Slack has made it clear they don't intend to support large open source projects is the biggest thing in my opinion. Reactiflux was basically forced off Slack for getting too big. Other large communities like the Clojurians Slack community will likely be forced off soon in the near future too (some members of the community have begun discussing this and evaluating alternatives). The Elixir Slack community is also similar in size, and I see the same thing happening there eventually.
Yeah, I saw that. :) This is impressive. I wish I knew about this project sooner. I didn't see this project on the Clojure subreddit, so I shared it there in case others haven't seen it before either.
I see the issue you created about separating the Clojure API from the AI code. I think I'd have to do that because I'll be creating an AI from scratch.
I noticed in the thread you linked to that you mentioned Java packaging and possibilities for contributions. I might be able to help there. Let me know, or if you want to create some GitHub issues, I can take a look later and see which ones I can take.
I see you even hosted a micro tournament recently. I didn't know that was a thing. How did it go? So there's at least some interest for that it seems? If so, I think I'd like to give it a shot too in the future (it'll probably be a while before I can get to this though).
This is great, thanks! The fact that it's possible to get started in Clojure, I no longer have any excuses to not try this.
Having an interactive REPL seems like it would be helpful for iterating on micro routines (this is what I want to focus on). I see you already have some situational micro examples too.
I feel like a kid again. Can't wait to try this! Now I'm wishing I still had my StarCraft discs with me.
Having said that I think Quill looks nicer (https://getquill.io/) if you want a DSL like that.