Hacker Newsnew | past | comments | ask | show | jobs | submit | lemming's commentslogin

Or if the code is really important, sometimes even “please make no mistakes” is necessary.

Perhaps not in that one, but in plenty more: https://www.972mag.com/lavender-ai-israeli-army-gaza/

Yes our government purportedly used technology to work up a list of targets in the Iran debacle as well just not with a LLM a distinction that to me just isn't that meaningful

https://www.theguardian.com/news/2026/mar/26/ai-got-the-blam...


Because just firing up Claude and let it rip

Based on Tridge’s post, this seems an unfair characterisation of how he used Claude.

Did Claude increase bugs in rsync?

TFA answered this, the answer is “no”.


Tridge in his blog post describes people as "foaming at the mouth"?!

Did you see the picture in the article where the user posted a picture of them strangling the maintainer? I think “foaming at the mouth” is probably gentler than how I would characterise that.


I always remember when, as a young geek writing games for my C64, I was thrilled when I saw the Terminator and a lot of the code scrolling past in its HUD was 6502 assembly code!


Great article, as always.

There is one thing that I think is important to bear in mind when discussing inlining, especially in the context of Clojure. This is that once a function has been inlined, you can no longer update the definition of that function in the REPL and have that update the behaviour of functions which use it, unless you recompile those as well. This is not a criticism of course, it’s just part of the natural tension between dynamism and performance.


Julia actually has some really cool machinery for handling this that I would encourage other JIT languages to copy.

Whenever you call a function, that function and any calls in that call stack occur in a 'fixed world age'. Within a given world-age, method tables and global constants are all fixed, and the langauge can be analyzed like it's statically typed (there are escape hatches like `invoke_in_world`, and `invokelatest`)

Between world-ages, things are allowed to change. When a function calls another function, we add a 'backedge' from the caller to the callee.

So if I have `f(x) = g(h(x))`, and I redefine `h`, we then say it's no longer valid, and then we look at the backedge that leads from `h` to `g` and say the old definition of `g` is also no longer valid, and then we go from `g` to `f` and also invalidate the old definition of `f`.

This means that once `f` is called in a new world age (the world-age gets incremented every time a new method is (re)defined, or if a global const is changed / defined), the compiler knows that it has to recompile `f`, `g`, and `h`. What's especially cool is that this system works regardless of inlining, and it allows us to safely do all sorts of interproceedural optimizations, but in a JIT compiled language.


That is very cool indeed. Are there limitations that this imposes? Is Julia a whole world compiler or does it support partial compilation?


There's two main limitations:

1. If you try and re-define a global constant or add new methods inside a running program using `eval` or whatever, then your running program won't see those changes until it advances the world-age (i.e. either by using `invokelatest`, or by returning to the top-level scope). Note though that things like closures and defining functions within functions is fine, you just can't do an arbitrary `eval` to define something completely dynamially

2. Method invalidations can cause a lot of compilation latency. If you load a package that invalidates a bunch of already compiled methods, then those methods will later need to be recompiled, which means you hit some more compiler latency than expected. These invalidations can have false postives too, so sometimes more methods get invalidated than you'd want

__________________________

> Is Julia a whole world compiler or does it support partial compilation?

On the LLVM side, we only do partial compilation. Every function method specialization in each different world (modulo inlining) is its own LLVM module that gets compiled in parallel by LLVM. Non-inlined function calls then involve linking these modules.

On the julia-side with our own custom internal IRs though, that's where we perform whole-world style interproceedural optimizations and inlining before handing the individual compilation units to LLVM. At least if I'm using "whole world" right here. What I mean is essentially everything statically known to be reachable from a compilation unit's entry-point given its signature. If by "whole world" you mean compiling every possible method signature, that's not possible in julia at all, because the space of possible method specializations is infinite due to parametric types.

We generally get the best of both worlds with these two approaches (at the cost of just using a lot of space to store all the different possible specializations and all of our differnt IRs and different pieces of machinery).


That is really interesting, and very clever - thanks for the details! What you describe is indeed what I meant by whole world, I'm not sure if there's a better term of art for it.


Hey lemming! You're right, which is why it should be used sparingly. Since clojure.core is compiled (on the JVM) with direct linking, reacting to var changes isn't an intended concern, since they're not going to work properly throughout any clojure.core code using that var. This makes it a good candidate ns for inlining things. But users shouldn't just be doing this for their normal application vars without giving it due consideration.


Does that not happen automatically? I know there are contexts in which jvm will deoptimize inlining and recompile, like in response to class loading that causes a call site that was previously provably monomorphic to no longer be.


No, it doesn't. In JVM Clojure's case, the vars are usually compiled to the moral equivalent of a global variable holding a pointer to a function. This allows you to update the function if the developer redefines it in the REPL, but it comes at a performance cost (the JVM can't inline it or otherwise optimise it). Clojure also allows you to compile with "direct linking", e.g. for production deployments, where you know you're unlikely to be wanting to dynamically update the code. In those cases defns are compiled down to static methods which call each other - much faster since the JVM can perform its magic with them, but you can't update them at the REPL.

I'm unsure exactly how jank works WRT this tradeoff, but the article makes it sound like it's closer to the direct linking version, but with the inlining etc being done by jank rather than the JVM. I don't know if this is only for AOT or also in JIT cases.


> the vars are usually compiled to the moral equivalent of a global variable holding a pointer to a function. This allows you to update the function if the developer redefines it in the REPL, but it comes at a performance cost (the JVM can't inline it or otherwise optimise it)

might be out of my depth but I find it surprising; I thought compilation through invokedynamic should be able to handle redefinition while still allowing inlining and other jit optimizations


Clojure (AFAIK) does not use invokedynamic, except perhaps in the latest version for some of the new interop stuff. It still officially supports JVM 1.8 bytecode. It’s a language which greatly values stability and backwards compatibility, so it’s been very slow to adopt newer JVM features.


Though there may be other reasons not to use it, invokedynamic is not a new feature of the JVM. If they're targeting 1.8 binary compatibility, they certainly have it at their disposal, since it landed in 1.7.


I can't speak for the core team, but from memory invokedynamic took a long time to become performant. So if you still want to support older JVM versions, the performance will be pretty terrible on those older systems if invokedynamic is used for something as integral as var lookups.


Is that really true? Can't you track invalidations via a dependency graph?

Right, as you said, you'd have to recompile dependents.


That's what Julia does. It works pretty well.


When I was in NYC a while back, I met a woman at a friend's dinner party. She sounded totally American, but was in fact Brazilian. She worked as a lawyer, and said that she'd had to get extensive voice training in order to sound American so that people would take her more seriously professionally. I have no idea if the professional part worked, but the accent, mannerisms etc was amazing - I would never have guessed.


What's amazing to me is how little space is required to have a completely self-sustaining ecosystem. A 60km diameter circle just doesn't seem like a very big space to have enough plants to support "flourishing" numbers of multiple types of large herbivores, without migration, as well as all the different prey species required to keep things in balance.

Regardless of the arguments about radiation, it seems pretty clear that lack of humans is really the most important thing for animals to flourish.


Just to put things in perspective; a square kilometre can support nearly 250 cows in ideal conditions. The exclusion zone is 2827 square kilometres. Forest supports fewer animals, but on the other hand most of them are a lot smaller than cows. I wouldn’t be surprised if there were many thousands of animals of all types living in the area.

With our planes, trains and automobiles 60km doesn’t seem like a long way, but try walking that distance through untracked forest. It would take days. We’re totally cut off from nature in most of our daily lives.


Sure, but the article talks about flourishing populations of deer, elk, and bison. I assume that means we’re talking about herds of each, all in the same space. And they have to survive over winter, which sounds pretty cold there - presumably they don’t migrate, which I guess they usually would? It’s definitely not ideal conditions.

Obviously it’s possible, but I was surprised.


Chernobyl exclusion zone is not same as it was 40 years ago. For example in 2019 research was done on growing crop in the exclusion zone. You could even buy Atomik vodka, made with grain and water from the Chernobyl exclusion zone.

https://www.bbc.com/news/science-environment-49251471

In 2022 the German Federal Office for Radiation Protection (BfS) in cooperation with State Agency of Ukraine on Exclusion Zone Management has published the initial results of the radiological remapping of the exclusion zone. The data can be used to assess which areas of the exclusion zone could be reopened for use. The start of Russian invasion halted all this activities and research.

https://www.bfs.de/SharedDocs/Pressemitteilungen/BfS/EN/2022...


Actually some lands were returned back to commercial usage. The land is extremely beautiful and rich. They have even created new resorts on the former land of the Exclusion Zone. [1]

I have been a part of the working group researching possible commercial usage of contaminated land, which should not be returned into agriculture or cannot be made livable BUT is perfectly suitable for things like prison, recycling plant or launch pad for space.

[1] https://maps.app.goo.gl/JU3HHsz1hHyGak9U6


"cannot be made livable BUT is perfectly suitable for things like prison"

That sounds a bit dark.


My dream project for the Chernobyl Zone was a Norwegian style prison combined with college and completely and totally isolated from legacy soviet penitentiary system.

So that we can take younger first offenders and rehabilitate them and give them purpose in life.

Unfortunately, no one in the government we did discuss that gave any shit about the future of younger generation of Ukrainians.


Well, that sounds a bit nicer.

(I assume what makes it acceptable for a prison, but not "livable" is that prison inmates do not roam around, but are enclosed in a artificial compound?)

And for whether government is interested, I suppose also depends on how much more expensive it would have been?


> what makes it acceptable for a prison, but not "livable" is that

Much simpler. The main concerns are digging (radioactive fallout is about 30cm deep into the ground at this point) and unmapped hot spots. Basically, there could be a patch of the land with radioactivity high enough that it has to be either deactivated or tagged out.

> government is interested

One of the cultural gaps between us, russian [1] people and western world is the vast depth is misunderstanding of the function of government. Our governments is only interested in personal enrichment and the well being of people is never a factor. Literally.

[1] as in "slavic people", not "citizens of russian federation".


Origin and history of English word slave

https://www.etymonline.com/word/slave

slave(n.)

c. 1300, sclave, esclave, "person who is the chattel or property of another," from Old French esclave (13c.) and directly from Medieval Latin Sclavus "slave" (source also of Italian schiavo, French esclave, Spanish esclavo), originally "Slav" (see Slav); so used in this secondary sense because of the many Slavs sold into slavery by conquering peoples.


The European green belt is an even starker example, it’s thousands of miles long but just a few tens to hundreds meters wide in most locations, yet its stability and continuity have made it a huge wildlife conservation area.


thank you. TIL. Hiking the Green Belt sounds like an interesting long-term hiking project


At a glance the part of it that goes along the Polish coastline is largely forests growing on the sand dunes at the coast.

The experience is mixed, as while you can find amazing places like Słowiński Park Narodowy, where due to proximity to the lake and sea light pollution is low enough to behold the Milky Way, most of that section is interrupted by footpaths for beachgoers and really busy in season.


Things have been different for well over five years...

In fact, I first presented Cursive at the conj 2014, and I'd been working on it in open beta for perhaps a year before that, so well over 10 years!

...all this fantastic "static analysis style" developer tooling by borkdude and eric dallo.

ahem


Thank you Colin for the outstanding work and selfless, continuous gifting and self-generosity. Cursive remains one of the important pillars of Clojure journey for many beginners and seasoned pros.

You just can't ignore the amazing collaboration and camaraderie between Clojure tools builders. - you Colin, Peter (Calva), Eric (clojure-lsp), Michiel (babashka, kondo, etc.), Bozhidar (CIDER, clojure-mode), Juan (flowstorm), Chris (Portal), and many others.

Everyone, instead of competing with one another just wants for people to find their best way of using Clojure, and that is really awesome. You can see the ideas freely circulating between spaces and creating great of awesomeness for everyone in the community. I'm telling you all this as someone who doesn't even use Cursive. I still can see your work. I can tell how valuable, important and vital you are for me personally and for many of my friends and colleagues. I salute you, and every other tool-making hero. Thank you, guys!


Thanks! Yes, I get on really well with everyone in the community - the community in general is perhaps my favourite thing about Clojure!


Cursive has been way ahead of the curve, yes. Sorry Colin, I'm both emacs-addled and fuzzy with timelines :D

So think of it more like "static analysis stuff for the rest of us" :D


Hehe, Lisp Emacs Myopia is indeed a real thing. Cursive users have been not starting REPLs for over a decade now!

j/k of course, and no offence taken :-)


I still don’t understand why they’re referred to as persistent vectors rather than immutable vectors, but I digress.

I believe that immutable just means, well, immutable, but persistent means that updates are achieved via structural sharing, so they’re efficient.


structural sharing = log n updates

if you think immutable updates are O(n) in 2026, you're so far behind the curve it's laughable

it's crazy how many ppl i interview just stop thinking and insist you can't do better than O(n)


Can you please share these data-structures you are talking about? What papers?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: