> My ideal syntax for function pointers is

this is actually very Kotlin, in Kotlin it'd be `val lambda: (Int, Char) -> Int = { myInt, myChar -> return 69 }`

Zig has also come very close:

  const Call2Op = *const fn (a: i8, b: i8) i8;
  fn doOp(fnCall: Call2Op, op1: i8, op2: i8) i8 {
      return fnCall(op1, op2);
  }

> Every language should either have a pipe operator or let you call any function with method syntax

there is a nicety in Zig that may help: `fn1(p1, ...)` is the same as `fn1.p1()`, so `fn2(fn1(p1))` can be unfolded into `p1.fn1().fn2()`

Sure, but those places don’t need such lofty resumes to begin with.

With the right kind of credentials, it's not about need, it's about want. Flip the roles and let yourself become an object of desire, an aspirational hire.

it's kind of hard to save a company billions in operating costs via software without it being part of Silicon Valley (culture)...

I wonder, how many such interesting and universally beneficial developments did emergence of tools like Claude Code kill?

call me an optimist, but I believe that more and more things are getting more viable to do from the terminal. tools like jj remove the need in Git GUI because mental model and UX gets streamlined, and the AI craze incentivizes practically every company to create their own CLI

not quite! if your project is mixed C/Zig, then editing Zig would work but editing C would not. the Zig compiler caches Zig AIR but no information from C. plus, the C compilation can only really be done with LLVM and writing a self-hosted backend would be PITA for C

Not quite true, there is already a capable C compiler written in Zig (Aro/arocc), and a plan to transition to it for C compilation: https://codeberg.org/ziglang/translate-c

Using this native (written in Zig) C compiler to translate C source into Zig source as a part of the build, would presumably lend itself trivially to all the incremental logic in TFA, as updating C would update the generated Zig, and the incremental logic would detect differences just like it detects differences made by a human in an editor. Maybe there are aspects of the generated Zig that would complicate that somewhat, but I don't know -- just a warning about my ignorance.

This is part of plans to remove the hard LLVM dependency. AFAIK, the LLVM dependency will still be a variant many will use for the convenience of Zig as a much better clang, but removing the hard dependency is part of enabling all these great features like incremental compilation.

> a plan to transition to it for C compilation

That's not planned AFAIK (see https://github.com/ziglang/zig/issues/16269). `translate-c` is really only intended for header translation, not C source code.

See https://github.com/ziglang/zig/issues/20875 for the (not fully fleshed out yet) plans around C compilation.

Thanks for the correction, I knew I was about 2 decisions out of date when I had the impulse to write my post, but my research to fill in my blanks was a bit faulty. I added the 2nd paragraph and "plan to" ending of 1st as an edit because I thought I had learned enough good info when writing the rest, but I was wrong.

Zig already uses arocc! https://codeberg.org/ziglang/zig/src/branch/master/lib/compi...

That's there for translate-c, it's not used for compiling C code

(To be clear, squeek502 is a part of the Zig core team [0], so he knows what he's talking about :D)

[0]: https://ziglang.org/news/welcoming-new-team-members/

my bad, thank you for pointing that out!

64 GB! you are lucky :) sitting there with 16GB, a GPU that already shows the signs of strain, and AM4 Ryzen 5 5600G. (MacBook Air M1 equivalent in single-threaded tasks.) apparently the CPU requirements slowly crept up across the line. and then there is looming AVX512. why "looming"? because at some point enough people will move to it that software will require AVX512.

Maybe a year from now we'll all be using MI300As and EPYC 9600s to read e-mails. Or Nvidia Veras, maybe AWS will sell some of their Graviton stuff in an effort to offset their capex.

Unfortunately, I don't think IBM Cloud will suffer enough for me to play Tux Racer on my very own Z17.

> play Tux Racer on my very own Z17

Interesting. It looks like Debian has a Tux Racer package for Extreme Tux Racer on s390x. I guess it'd be remote graphics, and not accelerated.

I don’t think Linux on Z supports GPUs on the PCIe IO drawers, but that’s a relatively minor software enablement issue. All I need is a z17 for myself to play with it ;-)

actually I'm looking forward to that :3 but that requires Claude et al. going bust and HN is gonna kill me if I wish that publicly

not worth 32GB RAM becoming unobtainium imo. what's use of Claude if Claude can't build the project on my machine?

and before you say "cloud IDE" or "Ona" or "GitPod", know that I'm going to draw the metaphorical revolver with a calm gaze. [1][2]

[1]: using Amazon listing for reference, the original author of this edit is unknown. https://www.amazon.co.uk/WENSHUI-Portrait-Painting-Posters-P...

[2]: I reposted it on bsky because I share it too often. https://bsky.app/profile/bpavuk.neocities.org/post/3mffdd5ud...

> including agriculture

in fact, agri sees its share of impact now! all of this investment has to come from somewhere, which means that money is getting sucked up into AI from the entire economy. job cuts in tech are part that, part general "de-bloating" of post-COVID tech. retail investors are a lot more likely to invest into AI than any other industry, although there are signs that big players already consider risks of overexposure to AI.

not to mention, agri saw a "bubble" of its own, surrounding Agtech, which peaked at 2021 and has been cooling ever since. scare quotes here because it was nothing like AI bubble

that could also be just marketing. OpenAI has been doing the "too dangerous to release" playbook since GPT-2 at the very least.

Huggingface didn't seem to think so.

If it is marketing, the misrepresentation is not that the attack occurred, it is that it was an accident, rather than an intentional consequence of setup and instructions that the attack occurred.

Huggingface has nothing to do with that either way.

Indeed. There's nothing new about this incident.

https://news.ycombinator.com/item?id=48348578

Huggingface is a for-profit private company. They are very easily bribed, or baited into publicity stunts.

At some point the conspiracy gets so deep that an AI hacking something is just far higher probability.

We're not that deep yet. OpenAI has federal stakeholders, they're already playing dirty.

Why you would give Scam Altman the benefit of the doubt is beyond my understanding.

ffmpeg is actually asm and for a good reason - it has to go fucking fast or else media playback will take too much resources

Great then let's prove that ASM is correct.

the reference C code is just as bad.

Which is actually possible, unfortunately the industry never cared that much about strong typed assembly.

See Verve OS from Microsoft Research, TAL and the origins of the Dafny language.

It's smallish snippets that implement self-contained algorithms, which should make it well within reach of direct formal proof of correctness.

There are projects such as Halide[1] that actually allow you to achieve performance without needing to resort to asm.

[1] https://halide-lang.org/

and now people install Remote Access Trojans just to let GPT and Claude think and work for them, granting them shell and a11y access. really? after seeing that, nothing surprises me

Yes, really. The obvious answer that security maximallists deny even exists is, who is doing it and why. In LLM case, users are doing it themselves to allow a way of computing they want and find useful, in spite of platform locks designed to deny users just that.

I mean, go tell Anthropic to prompt Claude to make it adopt Landlock in Claude Code instead of regex-based filtering. actually adopt it, not how Codex did, but with controls on the level of some third-party harnesses and Pi plugins.