maksut

That wouldn't surprise me.

Surprisingly Windows audio stack is a mess. I have a mini keyboard with Bluetooth and it was an adventure to get it working in Windows. In Linux it was pretty much plug and play.

Low latency audio drviers are also messy in Windows when not using an audio interface with well written ASIO drivers. Pipewire in Linux is much easier to configure. Looks like MacOS also does not have this driver problem.

It is surprising. Because most audio plugins and DAWs support only Windows and MacOS.

I disagree with this. The tooling around JVM is great or at least good enough.

Maven is mostly smooth sailing comparing to Python's env solutions or JS ecosystem. Maven is 21 years old. A quick search says Python has/had; pip, venv, pip-tools, Pipenv, Poetry, PDM, pyenv, pipx, uv, Conda, Mamba, Pixi.

Debugging is just fine. Modern debugging tools are there. There is remote debugging, (although limited) update & continue, evaluating custom expressions etc. I don't know what they complain about. If using Clojure, it is also possible to change running application completely.

Monitoring tools are also great. It is easy to gather runtime metrics for profiling or monitoring events. There are tools like Mission Control to analyse them.

That is interesting. I wonder if L1 is denser because it has to have more bandwidth. But doesn't that point to a space constraint rather than money? A combination of L1 & L2 will have a bigger capacity so it would be faster than pure L1 cache in the same space (for some/most workloads)?

I always thought cache layers was because of locality but that is my imagination :) The article talks about different access patterns of the cache layers which makes sense in my mind.

It also mentions density briefly:

> Only what misses L1 needs to be passed on to higher cache levels, which don’t need to be nearly as fast, nor have as much bandwidth. They can worry more about power efficiency and density instead.

It was a learning exercise. Just playing around with clojure, raylib and this new api. I know all these can also be done with C# with some pros & cons.

I wasn't advocating java for gamedev. Just pointing that, this new api is a nice addition. And I am glad that jvm ecosystem is improving.

To be fair, if I was starting a game project I wouldn't stay in Java/C# level. Depending on the project, something like C, C++, zig might be more practical. Ironically I believe they would be easier for iterating ideas and deploy into different platforms (mobile, wasm etc.).

I don't know much about C#. It certainly looks more popular in gamedev circles.

When I played with this new java api. I wasn't worried about the FFI cost. It seemed fast enough to me. My toy application was performing about 0.77x of pure C equivalent. I think Java's memory model and heavy heap use might hurt more. Hopefully Java will catch up when it gets value objects with Project Valhalla. Next decade or so :)

Is that still true when distributing libraries?

I'd like to learn how they do it. Because last time I've looked at this, the suggested solution was to copy the binaries from claspath (eg: the jar) into a temporary folder then load it from there. It feels icky :)

It is free to try. But may not be free for commercial use. Some random blog post says check it with Oracle if you want to sell your products/services with it.

Apparently those are not available for native executibles produced by graalvm community edition.

Profile guided optimisation for native executibles sounds cool. Too bad Oracle wants to keep it closed for monetisation.

I am eyeing river wm. Because it has pluggable layout manager and controller via custom wayland protocols. Which means I can implement just those parts in my favourite lang to scratch the itch. Kudos to you going for the whole wm :)