Console? good, GUI? good, game dev? use Godot engine with its similar language Gdscript, but what else? Ive been seeing AI, Data Science stuff, but whats the point if ita slow?

I’m looking to follow more creators and developers on Mastodon who are passionate about open-source, privacy-first software, and system tinkering.

I spend most of my time working within the Android development stack, building local-first/offline-first applications, running Arch Linux, and messing around with low-level Android rooting and custom kernels.

Let's follow each other!

@jksalcedo@mastodon.social

I'm a beginner in programming, and I found out I cannot even reproduce a simple number guessing program I have earlier copied from a book.

Is it a beginner issue, or there is more than just continuing to learn to be able to code without hints?

#Hello eveyone!!

D.eSystem 6.0.8 beta is the final release of D.eSystem 6, ist way more stable than the old Beta versions and it introduces a gui for the D.eSystem version app

D.eSystem 6.0.8 on github: https://github.com/D-electronics-scratch/all_D.eSystem_versions/releases

Github main page: https://github.com/D-electronics-scratch/all_D.eSystem_versions

*The Rustification of Bun#

Rewriting 500,000 lines of Zig into another language would be a gargantuan undertaking if done by hand. “A rewrite in another language would take a small team of engineers a full year. It would mean freezing bugfixes, security fixes or feature development for that time,” Sumner wrote.

Instead, Sumner went with Claude. He spun up about 50 dynamic Claude Code workflows, reaching a peak of about 1,300 lines of code per minute and generating over a million lines of Rust code. The job took 11 days and cost about $165,000 at API pricing. Claude Fable did most of the heavy lifting.

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?

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.

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.