This is very true, the Sony vs Bleem and Virtual Game Station lawsuit set precedent and made Emulators legal. Roms in the other hand are not legal, but for what I have heard Game companies are too afraid that the case of Bleem and Virtual Game Station to be repeated that they prefer to not file lawsuit and make copyright claims to websites that upload roms.
In this case is clearly stated if you read the report as xCloud, not Gamepass. Even they metion about the latency, and metion as competetitors Nvidia Geforce Now and Playstation Now
Microsoft have in 2021 the 60-70% of global cloud gaming services representing 1-3% of the gaming industry. Is true that this number have been growing, but anyway the reasons that are using is backed by the idea that ultimately the Cloud Gaming Services will take over all the industry. But this is just especulation, and probably even if this is true this would happen even without Microsoft buying Activision.
It's speculation based on marketing hype that isn't found in the product.
I have access to xCloud. The lag is unreal. I don't see how they will get the lag down to an acceptable level for the kinds of games that Activision makes.
Cloud gaming makes sense for party games, turn-based games, anything that doesn't require reflexes. This leaves out everything Activision makes.
There is no evidence that the lag issues with cloud gaming are solvable.
I think that the main problem upgrading beyond Java 8 is Java 9 and module system and a lot of javax package classes that were removed. It will be very helpful a tool that can detect what modules or classes that are being used by your codebase and add them as maven or gradle dependencies and add them to the classpath.
As Clojure programmer, i tell you that you should, because any moment Java introduce new features libraries will start using and most Clojure libraries are Java libraries wrappers.
In addition if you want to use these new Java libraries in case and Clojure does not catch up with new Java features the ergonomics of using Java libraries with clojure decrease.
And still they are trying to figure out how Ifn Clojure interface with Java functional interfaces.
Also when Project Loom lands on JVM it will benefit Clojure too, allowing to remove code for instance of Clojure futures.
If Clojure catch up with Value classes can increase performance of Clojure too.
But this disregard of Java features or improvements is the kind of Clojure developer so content of what he have that forgots that can get better things.
I have the feeling that after Nubank bought Cognitech, Clojure has gone to stagnation. I mean, i feel that promoting and improving Clojure is no longer a priority. And another think that stinks me everytime Cognitech talks about Clojure they have to bring to the table Datomic. They tried to push Datomic on my company long time ago when they do some consultancy job at my company. You can skip all the talk, because is all about how good Clojure is and that is. No any eta about future features, improvements and fix problems of current Clojure users.
Lot of open source contributors have leave the community, because there is any plan on Clojure. I guess that Rick Hickey is happy with Clojure as it is now, and this is the way is going to stay. And still no Java 8 support for CompletableFuture, lambdas interface, Stream api, java.time, no pattern matching, java records, this group feels like a group of old programmers stuck at Java 6 that cannot move forward.
All the things you are mentioning would be nice to haves but frankly nothing prevents us to use these today already, either directly or via a bit of wrapping.
Communication "style" and slow pace is frustrating sometimes but that's a small price to pay for all the positive facets of the language/community. I used to be more critical of these but I don't care anymore, the community is wonderful, the language is very usable and thriving, that's what matters ultimately.
About Datomic, I still don't get why there's no push to open-source the on-prem version, especially since nubank acquisition.
I dug onto the internals a few times, contributed to some of the alternatives, read/viewed pretty much everything about it and used it for fun in toy projects, and that thing is just so versatile it makes me angry it's not more accessible and as a result not more popular. It has an incredible untapped potential.
Every conj I am holding my breath hoping for a "one more thing" announcement where they'd do just that.
The "alternatives" do things either quite differently on too many aspects or lack traction.
Which of the datalog alternatives do you think is closest? And how much of an improvement do you think a datalog db is over boring Postgres or SQLite? I’ve been weighing what db to adopt.
datalog is just the query language. For me there's no such thing as a datalog db, there are various db that uses some derivative of datalog for querying but that's it. To give you an idea, datomic has other ways to query your data than with datalog alone.
The "closest" to datomic is datahike right now.
Crux/datahike/datascript/asami all use datalog in some way or another but they cover different use cases.
It seems to me that these things are a big deal if you're doing a lot of JVM interop and not so much if you're primarily using Clojure-native libraries.
Clojure has futures, lambdas, streams, a community-maintained java.time library, core.match, and Clojure records. I'm sure there would be benefits to adopting the newer JVM-native equivalents, but I'm not as sure they're worth the costs.
I thought you might be trolling. But then when I looked at the Clojure repo on Github https://github.com/clojure/clojure the last commit was 2 months back. There is some merit in your arguments.
Clojure evolves slowly and deliberately -- it gets about one release a year (with various prereleases) so "2 months" between commits isn't a big deal. I consider it a "feature" because it means Clojure is extremely stable -- which is great for us at work given that we've used it in production for a dozen years at this point and have been able to run alpha builds in production safely during nearly all of that time.
For me, protocols i tend to not use it, because it makes it harder to understand the code and Cursive cannot find instances that implements the protocols.
For testing purposes is easier to redef a function than implementing a full new test protocol.
I agree that in most cases with-redefs works fine, and I tend to use protocols sparingly myself for the same reasons.
I thought it was worth mentioning that you can use them to encapsulate any effectful code since they can be used as a tool to help enforce a bit of discipline. If you're just calling functions that can cause side effects then it can get tricky to figure out what all the functions that need to be redefined are. You basically have to read through all the code to know what you need to mock. If you stick all the side effects in a protocol, then you're being very explicit about what needs to be mocked out.
Well, i have to add having developing in a Clojure shop that starting to develop a new feature with Clojure is easier than Kotlin, you don't have to care almost about of the shape of the data. But later, this is a pain, you need a lot of discipline to document because you would look back at this code a who knows what data are you receiving.
In addition i have to say, that a lot of libraries are falling into clj-commons because the original developers no longer works on the project, other like compojure, that is mentioned in the blog post last stable release is from 2016 and version 2 is in alpha since then.
I am curious why are you using c3p0 on 2022 when hikaricp is being maintained, and last release of c3p0 is from 2019. Also no support for R2DBC.
My impression is that in the last 2 years, the ecosystem has shrink, less talks, less new libraries, new libraries that are no longer maintained.
Others problems arise is that Clojure lag a bit with compatibility with new Java features, still i think Clojure cannot pass Clojure functions as parameter to Java functions. It results in awkwardly having to reify Java function interface to pass function when using a Java library. No conversion from Java 8 CompletableFuture to clojure async primitives in 2022. And i think they not going to support it in the near future.
What i am saying is that Java is in the future, and Clojure is in the past. They just cannot catch with new Java features and i doubt they are going to support it ever. You can still run it on modern jvm because they update the bytecode but that is all.
Others problems arise is that Clojure lag a bit with compatibility with new Java features, still i think Clojure cannot pass Clojure functions as parameter to Java functions. It results in awkwardly having to reify Java function interface to pass function when using a Java library
Ouch, Java 8 was released in 2014. To be fair, Clojure was never a community project though.
