cl-cuda VS rewrite

> You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this

this is not the job of compiler writers (although writing macros is akin to writing a compiler but i do not think that this is what you mean). in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0]. also here is the similar library in common lisp [1]

[0] https://github.com/JuliaGPU/CUDA.jl

[1] https://github.com/takagi/cl-cuda

A Common Lisp Library to Use Nvidia CUDA\ (0 comments)

Personally, I've been relying on the stream-based method using py4cl/2, mostly because I did not - and perhaps do not - have the knowledge and time to dig into the CFFI based method. The limitation is that this would get you less than 10000 python interactions per second. That is sufficient if you will be running a long running python task - and I have successfully run trivial ML programs using it, but any intensive array processing gets in the way. For this later task, there are a few emerging libraries like numcl and array-operations without SIMD (yet), and numericals using SIMD. For reasons mentioned on the readme, I recently cooked up dense-arrays. This has interchangeable backends and can also use cl-cuda. But barring that, the developer overhead of actually setting up native-CFFI ecosystem is still too high, and I'm back to py4cl/2 for tasks beyond array processing.

If you're into this sort of thing, there's OpenRewrite[1] for the Java ecosystem.

[1] https://docs.openrewrite.org/

> Spring has gotten so bloated.

I'd call Spring feature-rich than bloated. You can always shed weight that you don't want to carry.

> Plus there's multiple ways of doing the same thing. e.g. JPA, spring-data.

That's because there are different ways to solve a problem. Someone may want an ORM-based approach to connect to the database; they can choose spring-data-jpa. Someone may want to use JDBC with a light abstraction on top of it; they can choose spring-data-jdbc. It's all about choices and right tradeoffs and Spring offers plenty of them.

> they don't provide easy upgrade paths between majors versions

That's not my experience. I've been happily upgrading 2.x.x versions and plan to upgrade to 3.2.x when it is ready. But depending on the codebase, I admit it can be painful. Projects like OpenRewrite[1] might help here.

> and they stop updating vulnerabilities on older major versions.

This is not news. They want you to pay for extended support if you need it.

> No docs on migration.

They do maintain migration docs on GitHub wiki which are a lot more detailed than their blog posts on migration. Here's the latest one to upgrade from Spring Boot 2 to 3: https://github.com/spring-projects/spring-boot/wiki/Spring-B...

[1]: https://github.com/openrewrite/rewrite

The issue you may run into when migrating from Spring Boot 2.x to 3.x is the JEE namespace renames. Migrating code from 8 to 17 in my experience hasn't been all that difficult. In most projects, there are no changes to make. However, with the namespace change, you'll probably have to do some planning and testing. If you are migrating a lot of projects, check out Open Rewrite, it may help automate a lot of these upgrades (for both 8 to 17 and Spring Boot versions).

Couldn't OpenRewrite (https://docs.openrewrite.org) do a big part of this manual work?

Openrewrite would probably be a big help, see https://docs.openrewrite.org

In a similar vein there is OpenRewrite which is an open-source project that works in a similar way. It also has a lot of great refactorings already built in, like doing all the grunt work for migrating to JUnit 5, or replacing string concatenation in SLF4J log calls with parameterized formatting.

seems a case for https://docs.openrewrite.org/

https://github.com/openrewrite/rewrite might help