shelajev

good catch, it's naturally `ANTHROPIC_API_KEY`, but I could have been more specific.

Nice, I really like the recent Vulkan support.

my background is mostly Java so I know this happens-before: (https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.htm...).

from the article: > [Note 8: Informally, if A strongly happens before B, then A appears to be evaluated before B in all contexts. — end note]

this is the Java happens-before, right? What's the non-strong happens-berfore in C++ then?

I recently was trying to build an AI assistant to help with various chess things, which took shape of an MCP server: https://github.com/shelajev/mcp-stockfish

it builds as a docker image which has stockfish and maia (maiachess.com) together with different weights so it can simulate lower-level players.

It was a fun exercise, I tried a bunch of local models with this MCP server, which isn't particularly optimized, but also doesn't seem that bad. And the results were quite disappointing, they often would invent chess related reasoning and mess up answering questions, even if you'd expect them to rely on the tools and have true evaluation available.

It was also fun to say things: fetch a random game by username 'X' from lichess, analyze it and find positions which are good puzzles for a player rated N.

and see it figure out the algorithm of tool calls: - fetch the game - feed the moves to stockfish - find moves where evaluation changed sharply - feed it to maia at strength around N and to stockfish - if these disagree, it's probably a good puzzle.

I don't think I got to have a working setup like that even with managed cloud models. Various small issues, like timeouts on the MCP calls, general unreliability, etc. Then lost interest and abandoned the idea.

I should try again after seeing this thread

> "...engineers often mistakenly optimize for speed of information consumption over depth of understanding, leading to superficial knowledge."

really. Learning should [never] be fun - https://news.ycombinator.com/item?id=42099596

This is a Voxtral WebGPU demo for audio transcription where everything runs entirely in your browser with Transformers.js and ONNX.

Saying CI is a developer experience thing is completely misunderstanding the point.

AI workflows, vibe coding and such only emphasize the need for proper test suites and for a measured release process, where you don't actually delete your production databases on the whim.

It took me an embarrassingly long time to internalize what the reverse proxy is. My brain got stuck on the fact that it is just proxying requests. What's so reverse about this? Silly.

> "Closed platforms are going to lose to open ones that allow innovation"

Only if people (end-users) actually care. If you're trying to build against the momentum but misjudge your values for the community values, then you're in for a disappointment.

what a strange place to link to. Even Wikipedia has a better entry [1].

The model itself is fun to think about: preventing failures by stuffing more cheese into the system. If you're interested, the classic example of the cheese failure is Chernobyl, where many different things had to fail in order to become a catastrophe.

--- [1] https://en.wikipedia.org/wiki/Swiss_cheese_model

it's the latter: "you can actually start telling it to write a Playwright Python script instead and run that".

and while running the code might faster, it's unclear whether that approach scales well. Sending an MCP tool command to click the button that says "X", is something a small local LLM can do. Writing complex code after parsing significant amount of HTML (for correct selectors for example) probably needs a managed model.

"spooky action at a distance" sounds bad, but this is how most frameworks that embrace convention over configuration work. You add a dependency to your SpringBoot application and suddenly your app actually has new endpoints and config for them and so on.

If the code generation quality is so good you trust it to generate your verification system. You might as well write the tests yourself, and generate the actual implementation.

This way you're in control of what it means the code works, and formalize the acceptance criteria. Instead of feeding it a potentially incorrect implementation, and asking it to come up with a set of requirements what it should actually do.

I don't think it runs Docker. You can run minikube and use it for Docker workloads, which should work with testcontainers.

https://minikube.sigs.k8s.io/docs/commands/docker-env/

Here's a video of a session by Chen Li (mentioned in the post as a collaborator) from the Graal workshop with more details and some background: https://www.youtube.com/watch?v=Hepjf00LJrM

that's this tetris: https://github.com/kt97679/tetris/blob/master/Tetris.java

ncurses I think. There's an issue with how jconsole and tetris work together, so when tetris exits, jshell does too.

For example, NextJorunal is using it for React SSR [1]. There are other companies using GraalVM's JS engine for similar functionality.

The Dutch Police is using GraalVM's interop between Scala and R for their data science [2].

I'm sure there are other projects which explore the benefits of having a polyglot runtime, would love to hear about those efforts.

[1] https://nextjournal.com/kommen/react-server-side-rendering-w... [2] https://vimeo.com/360837119

From the description it's an aggregate of the common modern JVM workloads.

The following is the complete list of benchmarks, separated into groups.

actors akka-uct - Runs the Unbalanced Cobwebbed Tree actor workload in Akka. (default repetitions: 24)

reactors - Runs benchmarks inspired by the Savina microbenchmark workloads in a sequence on Reactors.IO. (default repetitions: 10)

apache-spark als - Runs the ALS algorithm from the Spark MLlib. (default repetitions: 60)

chi-square - Runs the chi-square test from Spark MLlib. (default repetitions: 60)

dec-tree - Runs the Random Forest algorithm from Spark MLlib. (default repetitions: 40)

gauss-mix - Computes a Gaussian mixture model using expectation-maximization. (default repetitions: 40)

log-regression - Runs the logistic regression workload from the Spark MLlib. (default repetitions: 20)

movie-lens - Recommends movies using the ALS algorithm. (default repetitions: 20)

naive-bayes - Runs the multinomial naive Bayes algorithm from the Spark MLlib. (default repetitions: 30)

page-rank - Runs a number of PageRank iterations, using RDDs. (default repetitions: 20)

core dummy - A dummy benchmark, which does no work. It is used only to test the harness. (default repetitions: 20) database db-shootout - Executes a shootout test using several in-memory databases. (default repetitions: 16) jdk-concurrent fj-kmeans - Runs the k-means algorithm using the fork/join framework. (default repetitions: 30)

future-genetic - Runs a genetic algorithm using the Jenetics library and futures. (default repetitions: 50)

jdk-streams mnemonics - Solves the phone mnemonics problem using JDK streams. (default repetitions: 16)

par-mnemonics - Solves the phone mnemonics problem using parallel JDK streams. (default repetitions: 16)

scrabble - Solves the Scrabble puzzle using JDK Streams. (default repetitions: 50)

neo4j neo4j-analytics - Executes Neo4J graph queries against a movie database. (default repetitions: 20) rx rx-scrabble - Solves the Scrabble puzzle using the Rx streams. (default repetitions: 80) scala-dotty dotty - Runs the Dotty compiler on a set of source code files. (default repetitions: 50) scala-stdlib scala-kmeans - Runs the K-Means algorithm using Scala collections. (default repetitions: 50) scala-stm philosophers - Solves a variant of the dining philosophers problem using ScalaSTM. (default repetitions: 30)

scala-stm-bench7 - Runs the stmbench7 benchmark using ScalaSTM. (default repetitions: 60)

twitter-finagle finagle-chirper - Simulates a microblogging service using Twitter Finagle. (default repetitions: 90)

finagle-http - Sends many small Finagle HTTP requests to a Finagle HTTP server, and awaits the response. (default repetitions: 12)

The last graph is a bit hard to read with the log scale. It's 10x improvement from GNU-R to FastR+rJava and another 10x with the native GraalVM interop.

you can use profile guided optimisations when building a native image with GraalVM. You'll need to run your code in a special way under the desired load to gather the profile information, then it can be used when building the native image. YMMV, but the results can be quite interesting, here for example someone compiled http4s: https://twitter.com/lukasz_bialy/status/989091065033625606

The things from the post: 1. High-performance modern Java 2. Low-footprint, fast-startup Java 3. Combine JavaScript, Java, Ruby, and R 4. Run native languages on the JVM 5. Tools that work across all languages 6. Extend a JVM-based application 7. Extend a native application 8. Java code as a native library 9. Polyglot in the database 10. Create your own language

The idea is to use an instance of logger to store messages related to some event, like serving a particular request or running a background job. If nothing happends, you discard everything and don't pollute logs. If you're not so lucky, it will flush all the messages, so you get a better picture of what was happening before the error. Compared to having just an info level logs that usually omit many relevant details.

Being able to configure stuff that is listed as features is a natural requirement. And it is supported: process listeners, process destroyers, stream handlers - all are behind interfaces, you can supply your own implementation. Some things maybe aren't that flexible (ProcessBuilder, I'm looking at you), but if you find a need to extend their behavior, create an issue, we will be happy to change that.

Default settings are sensible and fit the use case of: start process, consume and return its output/error streams, check error code. Common use-cases like killing process when parent JVM exits are supported with one-liner calls, etc. It was aimed to be friendly.

Finally, the comparison with other frameworks. You can find a couple of examples in the [readme file](https://github.com/zeroturnaround/zt-exec/blob/master/README...) on github. Also tests somewhat reveal the feel of the api.

My favorite feature is that it supports futures. When you want to run your process async mode commons-exec tutorial suggests:

    executor.execute(cmdLine, resultHandler);
    // some time later the result handler callback was invoked so we
    // can safely request the exit value
    int exitValue = resultHandler.waitFor();

zt-exec has:

    Future<ProcessResult> future = new ProcessExecutor()
                                    .command("java", "-version")
                                    .start();
    // do some stuff
    future.get(60, TimeUnit.SECONDS);

You get a process library that works well with java's default async framework.

Hope it gives some insight. If you have any more questions, I'll be happy to help to the best of my abilities.

disclaimer: I'm working for ZeroTurnaround, but I haven't been directly involved in creating or making zt-exec publicly available.

If your biggest issue with java is about restarting containers/redeploying your app, you should check out JRebel (http://zeroturnaround.com/jrebel). It's a tool (javaagent) that will pick up changes you make to your code and introduce them in your running application. Unlike Play! it supports your application server and your framework stack.

Also it supports picking up changes in the configuration of major frameworks, like spring, for example.

Basically, with JRebel you can develop in java as you would do in python :)

disclaimer: I'm employed by the company that develops JRebel, but this fact doesn't make it any less awesome.

You definitely want to try jrebel to solve your problems with redeploys and wasting time. It'll reload your classes and resource as you compile/provide them. Check it out, http://zeroturnaround.com . disclaimer: I work there, but jrebel is awesome anyway.