yogthos

Because, unlike the US, USSR had an actual education system.

Looks like I got my Kimi subscription just in time.

Incidentally, it looks like this idea also works with Jolt now. It's still in alpha stages, but works as a proof of concept. https://github.com/jlt-commons/jolt-openldk

Good news is that CXMT is ramping up DRAM production, and given how things went with solar and EVs, I'd expect Chinese ram will soon flood the market at very reasonable prices. https://www.cnbc.com/2026/10/13/cxmt-memory-chip-stock-rout....

The amount of mental gymnastics you're doing to justify the amount of SLAVE LABOR in the US is truly incredible. And couple that with one of the highest rates of incarceration in the world, that really tells us all we need to know about the state of human rights.

The original context here was human rights in China, and what we see is that the US both has far higher prison population per capita, and that it is being as slave labor which is a significant factor in certain sectors of the economy.

Your whole argument about the percentage overall economy is nonsensical because most of the US economy is not actual productive economy. It's ephemeral stuff like service industry, entertainment, and software development. Obviously, you're not going to force prisoners to go on Joe Rogan podcasts. But when it comes actually producing things, 17% of the industry being done by slave labor is obviously very significant.

Depends on the sector. For example, in California's large-scale wildfire responses, forced prison labor in firefighting acts as an important auxiliary force. https://www.commonwealmagazine.org/los-angeles-firefighters-...

In Arkansas, agricultural work accounted for 17% of all prison labor assignments in 2021. https://www.prisonlegalnews.org/media/publications/Captive_L...

oh please, the US economy literally runs on slavery

https://www.prisonstudies.org/world-prison-data/highest-lowe...

https://www.theguardian.com/us-news/2022/sep/27/slavery-loop...

A shameless plug for my engine which supports different backends, and lets an LLM create rules on the fly for it

https://github.com/jlt-commons/lev

capitalism at its finest

Closed source software model is basically dead now.

It's actually fun to read the code for Java games, people tend to do all the allocation up front to avoid GC pauses. So, it's a very unique style. :)

Very much agree on Electron, there is a noticeable lag, and it's always bothered me that making a native app has become such a chore that people now just package a browser to render the UI.

And thanks, it's always nice to hear that it is useful and appreciated. :)

I have yet to have a good experience with any JVM based app on the desktop with or without Clojure. Take a look at something like in IntelliJ as an example. It doesn't have a Clojure runtime, and it takes forever to start using gigs of memory. Like you said, it makes Electron apps look lean. I ended up switching to using VSCode because it just runs a lot better and uses less memory. And when it comes to Clojure specifically, ultimately it doesn't really matter whether the slowdown is JVM or Clojure specific. This problem has existed for around a decade now, I'm not expecting that it'll be addressed in the foreseeable future.

And yeah, Jolt solved this problem for me completely. Startup is fast, you get a single binary, and it runs anywhere Chez Scheme runs which is mac, Linux, Windows, Android, and iOS. The best part is that you can use FFI to access native ecosystem as easily as Python.

There's also some fun Burin's been working on porting OpenLdk to Jolt https://github.com/jlt-commons/jolt-openldk

It might make it possible to translate Java bytecode to Jolt, and then link it into the binary similarly to native libs as a statically linked fasl. That way there might not even be much of a runtime cost.

I've been following development Jank for a while, and I think it's a really exciting effort. But it's not really easy to get up and running with at the moment, and there are some gaps, such as lack of protocols, which preclude many existing Clojure libraries from working on it.

My understanding is that the main aim of Jank is to facilitate game development through tight integration with C++. And I think it's done some very interesting work on that front with the ability to generate LLVM bytecode on the fly. But it's not aiming to be a drop in replacement for Clojure.

So, I'd say that Jolt and Jank serve slightly different niches. My goal is to be able to build native binaries, have relatively good performance with fast stratup time, reasonable memeory use, and a high degree of compatibility with the JVM Clojure to run existing Clojure libraries. Jank appears to be aiming to be a highly optimized language bringing Clojure semantics to the C++ ecosystem.

I think this kind of stuff will work for certain domains, but there are limitations of what you can do in terms of defining complex behaviors using natural language. I expect there are still going to be plenty of software problems where you do need to be far more hands on. A formal description will always be more precise at the end of the day.

What I expect will happen is that we'll move more towards creating specs and contracts as developers that the LLMs will fill. And this works great with Clojure.

For example, I've been working on this library which lets you specify the state graph and constraints https://github.com/jlt-commons/writ

And I used it to formally encode Erlang OTP specs in a machine verifiable way here https://github.com/jlt-commons/ensemble/tree/main/test/ensem...

All I can say is best of luck to anybody trying to do something like that using natural language.