Andrew Kelley quit his job in 2018 to build a programming language. Eight years later, Zig powers Ghostty, TigerBeetle and Uber's cross-compilation. It's top 5 most admired on Stack Overflow. There's just one thing missing: 1.0. Andrew Kelley explains why.

Vitaly talked to Andrew about:

• Why Zig has no 1.0 after a decade, and why that's deliberate
• Why Zig left GitHub
• Why Zig banned AI from Zig
• What makes Zig better than C (and why every other C replacement failed)
• Andrew’s take on Open Source

It's a long interview, but I found it very interesting and worth it.

cross-posted from: https://lemmy.world/post/49397080

The official jscrambler npm package was compromised in v8.14.0, where a malicious preinstall lifecycle hook executed a Rust-based infostealer as soon as npm install was run. Because the payload ran during installation, both developer workstations and CI/CD runners that installed the affected release should be treated as potentially compromised. The malware targeted developer secrets, including SSH keys, Git credentials, browser data, cryptocurrency wallets, and other locally stored tokens. According to the vendor, v8.22.0 is the first malware-free release. If you installed v8.14.0, it's recommended to upgrade immediately, review affected systems, and rotate any credentials that may have been exposed

Been dealing with this more often lately. Tests pass on my machine, I push, and CI blows up. Usually it's one of these:

• Different Node/Python/whatever version
• Missing env vars that exist in my .env but not in CI secrets
• File system case sensitivity (macOS vs Linux)
• Some flaky test that depends on timing

My current debugging flow is pretty basic: check the logs, compare versions, run the exact same Docker image locally if I can. But it still eats 20-30 minutes each time before I figure out the actual problem.

Anyone have a more systematic approach? Like a quick checklist you run through before you even look at the logs?

Also curious — do you replicate your CI environment locally with something like act (for GitHub Actions) or just trust the remote runner?

Ok, I start: I like synthwave, synthpop and sovietwave. And it’s not as much a question of focus as the fact music energized me, so lyrics are also ok and even welcome and I don’t get distracted at all.

Had a backup script running via cron for months. Worked fine until it didn't — turns out the disk filled up three weeks ago and the job started failing silently. Nobody noticed until we actually needed a restore.

The obvious answer is "check your logs" but let's be honest, nobody's reading cron logs daily for 15 different scheduled tasks across 4 servers.

What's your setup for making sure crons are actually completing? Do you just grep logs periodically, or do you have something more structured? Curious how others handle this without turning it into a whole project.

My guess is that people who work on small codebases with low-turnover teams (say, Redis or games like The Witness) would say “obviously you have to understand it completely, otherwise you can’t do good work”. I’d also guess that people who work on large codebases with high-turnover teams (say, the Google web search backend or GitHub) would say “obviously you can’t understand it completely, you just have to do the best you can in your local area”.

These are two largely different ways of programming with different methods, practices and cultures. However, the first group is over-represented in online discussion about software engineering. I want to defend the second group against the first.

cross-posted from: https://lemmy.world/post/49193875

DConf2026 mostly has proAI talks, with the biggest standout being Adam Wilson's talk about integrating LLMs into developing the next version of the standard library.

This lead to a lot of debate within the community, with even some pro-genAI people calling it out, and there's even an open letter calling for rethinking the use of genAI, and some increased interest in the OpenD fork. It is also found out that people did try to volunteer for the new standard library (including me), but were rejected with the excuse of "we already have things in the works".

I'm also interested into some D alternatives that's not Rust (🤮🤮🤮🤮🤮 - no I'm not a Lunduke fan, but a gamedev, also no "const by default" languages!), has metaprogramming capabilities, and no (mandatory) header files (🤮🤮🤮🤮🤮), in case I decide to leave. I have a game engine that could be ported, its resource management needs to decoupled for D's garbage collection though.

Spent an hour today renaming env vars across three services to make them "consistent." Broke staging in the process because one service cached the old values. Should've just left the mess alone — it worked fine before I touched it.

Not under a freely available license or anything, but the game's source code is on GitHub right now, shortcuts and all!

Working on a project where I need to grab screenshots of pages on a schedule — mostly for QA and keeping a visual history of what changed and when.

Right now I'm running Puppeteer in a cron job on a cheap VPS. It works, but honestly it's a pain to maintain. Chromium eats RAM like crazy, sometimes it hangs and the whole thing needs a restart, and the screenshots come out wrong on pages that load content dynamically.

A few things I've been struggling with:

• Pages with lazy-loaded images — half the time the screenshot fires before everything renders
• Cookie consent banners blocking the actual content
• Memory usage goes through the roof when I try to do more than ~50 pages in a batch

I've looked into Playwright as a replacement but from what I can tell the resource usage is about the same. Also tried running headless Chrome in Docker which at least makes cleanup easier, but didn't solve the core problems.

Curious what others are using. Are screenshot APIs worth it for this kind of thing, or is self-hosting still the way to go? Anyone running something similar at scale?

Self-host your compiler, you cowards!

Several times this year, I've read about new systems programming languages, usually created with robotic help. That's great! New languages expand how we think about programming. I've noticed their compilers are almost always written in Rust.

Rust is a fine systems programming language in its own right, but a systems programming language, the kind of language meant for writing things like compilers, ought to be used for its own compiler before it's used for any other serious work.

I'm kidding about the cowards part of course. I'm sure all language designers are brave and kind, even if some look like serial killers.

@programming

@programming@programming.dev

#programming #languagedesign #rust #compilers

cross-posted from: https://lemmy.ml/post/49785198

https://web.archive.org/web/20240603213749/https://junit.org/junit5/22

After seeing its announcement a few days ago I didn't think much of it, but after looking into it a bit this looks awesome !

• Blog Post
• Github

Box3D was released a few days ago by legendary developer Erin Catto accompanied by a blog post, this is the person behind the popular Box2D engine.

In the blog post he explains that his work stems from his collaboration with Dirk Gregorius, "Principal Software Engineer II and Physics Architect" at Valve, the person behind Half-Life: Alyx's physics engine "Rubikon", which Box3D is based off.

Facepunch has also revealed that they have been using Box3D for about a year now as well in s&box. Showcasing a cool demo

An interesting quote from the blog post:

On the Valve side, Rubikon continues to evolve and Dirk has developed optimizations (similar to those in Box3D) in a new engine called Ragnarok. Look for that in future Valve games.

👀
Did he just reveal Valve's next physics engine ?
+HL3 confirmed

• cool showcase 1
• showcase 2
• showcase 3 in gmod (already??)