There’s almost certainly a way to make VS Code use --no-verify.

Are you referring to how the nixpkgs-unstable branch hasn't been updated in the past five days? Or do you have some specific software in mind? (not arguing, just curious)

It’s a variety of different software that just isn’t updated very often.

I don’t mind being somewhat behind, but it seems like there are a lot of packages that don’t get regular updates. It’s okay to have packages that aren’t updated, but those packages should be clearly distinguishable.

This is an issue in Python but less so in languages like JavaScript that support "field name punning", where you pass named arguments via lightweight record construction syntax, and you don't need to duplicate a field name if it's the same as the local variable name you're using for that field's value.

That forces you to name the variable identically to the parameter. For example, you may want to call your variable `loggedInUser` when the fact that the user is logged in is important for the code’s logic, but then you can’t pass it as-is for a field that is only called `user`. Having to name the parameter leads to routinely having to write `foo: blaFoo` because just `blaFoo` wouldn’t match, or else to drop the informative `bla`. That’s part of the tension I was referring to.

One of the other PhD students in my department has an NDSS 2026 paper about combining the strengths of both LLMs and traditional decompilers! https://lukedramko.github.io/files/idioms.pdf

Could you clarify what you mean about Nix missing concurrency and parallelism? I often run builds using nix-output-monitor and it definitely looks like things are running in parallel, although I could be mistaken.

I meant as part of the language itself, not just the runtime or for specific parts. Say I'm processing 100 JSON files, it'd be great if I could fire that off wrapped in 'parallel' or whatever, similar to Clojure and others I guess.

I think you can do this with Virgil, but I'm having trouble finding the exact doc page at the moment: https://github.com/titzer/virgil

The description is in the paper, but not all of it is implemented.

https://arxiv.org/abs/2410.11094

Bradley implemented a prototype of the packing solver, but it doesn't do the full generality of what is proposed in the paper.

I tried this five years ago back when I was an engineer on the PyTorch project, and it didn't work well enough to be worth it. Has it improved since then?

It works well enough that I didn’t realize this wasn’t first party till right now.

It works, but there are fair amount of caveats, especially for someone working on things like Pytorch, the runtime is close but not the same, and its support of certain architectures etc can create annoying bugs.

For me, no. Spend days trying to get it to recreate a production environment workflow. It is too different than production.

it has. it's improved to work with ~ 75% of steps . fast enough to worth trying before push

This sounds cool but is extremely uninteresting without performance measurements. Are there any?

Same question but for Jai.

Jai does not compile to C. It has a bytecode representation that is used primarily for compile time execution of code, a native backend used mostly for iteration speed and debug builds, and a LLVM target for optimized release builds.