The overlap with Jetpack's devbox name is not fine. Not morally, given the massive overlap in functionality between the two implementations. At the very least, their existence will prevent you from getting a trademark.
Both projects even use devbox.json for their definitions, for crying out loud. If your usage is not compatible with Jetpack's devbox.json, please switch to a different filename ASAP.
I don't get why this is so important. I don't love Oracle. I do love JavaScript. I couldn't care less who owns the trademark, and not sure what if anything would make me care.
I benchmarked rendering performance with Razor Pages and it was fantastic. I'm assuming Blazor Server is probably good too as long as you're not using the wasm stuff. The dx on the other hand...
(just realized in my previous comment I didn't specify I meant Blazor with WASM)
The Popular Mechanics article talks about it as if it was just "discovered" Both the original blog post and the video linked from the article are 5+ years old. Not exactly news.
Funny. I was just thinking about dismissing Clojure for a project I'm going to work on because I was concerned about it's lack of ability to work with async calls. I'm too used to how async in JavaScript and C#, and I'm not sure I'd want to work in an environment that doesn't have a simple way to structure async calls. It doesn't necessarily have to be async / await. Just some attention to the issue rather than completely ignoring it.
That has always been one of Clojure's main strengths (async & concurrency). With the new JVM VirtualThreads, things are looking better than ever.
The transition of core.async specifically to VirtualThreads is still WIP as far as I understand, but with minimal tweaks, 90% of the benefits are already there, even with the current latest version.
I’m curious what led to that conclusion. As far as I remember, making concurrency easier to manage was always presented as one of Clojure’s primary objectives. It’s fundamental to the design e.g. a major motivation for all core data structures being immutable.
STM, atoms and agents were there from the beginning. I think futures and promises were added in 1.1. core.async is from 2013. Even popular third-party libraries like promesa and manifold are around 10 years old at this point.
I think flow promises to make it easier to orchestrate core.async, specifically, in complex applications, but the essential primitives are far from new and I don’t consider them any harder to use than JavaScript.
Not talking about the cross-platform versions of .NET and VS-Code. I'm specifically talking about the Windows-specific software I mentioned above.
I don't see this happening, despite the fact that by now, these types of porting efforts were supposed to be trivial because of AI. Yeah, I'll wait.