mihaelm

Docker Sandboxes is using microVMs, not containerization.

With AI and how a lot of people use it, the quantity of written PRs goes up, but the quality goes down, and the maintainers of the project, who are often volunteers, now have to deal with this in addition to the standard work they've been doing before.

Scaling AI use in highly-collaborative environments, which open source projects are, is very challenging. I totally understand the apprehensiveness around it.

On your last point, I think it has a lot to do with how it's introduced in organizations. If everyone just goes hog wild with it, enamored with their newfound productivity, not only will the little gains be lost, I'd argue all the generated noise will be a net negative. And people will hate that.

That's the result of AI adoption in a company being people just getting a subscription and doing their own thing, instead of systematically introducing and finding a common ground; a trivial example of that would be open source projects increasingly adopting LLM policies to get everyone on the same page.

Joe Schmoe LLC will probably do just fine by sticking to popular clouds. I reckon adopting Oxide Computer would pay off at much larger volumes of traffic, or if you have to do on-prem due to regulatory reasons.

It would be nice to know more about pricing so the Enthusiast Joe can have a better idea, but it's more a boutique vibe right now.

Do you maybe know some Rust? I'm also not that experienced with FP languages, but Gleam felt familiar enough, due to some Rust-isms, to allow me to focus more on the concepts rather than the syntax. Granted, I spent a few afternoons with it, but if I were to pick a FP language again to wrestle my brain into submission, I'd probably go with Gleam due to familiarity.

Less mosquitoes, more bees please :)

More generally, it's known as the sterile insect technique and you'll find plenty of campaigns with some googling.

Microsoft's recent track record with Windows 11 seems to have kickstarted another Win -> Linux migration wave.

`pnpm` also has that and it's on by default since `v11`:

https://pnpm.io/settings#minimumreleaseage

I just use `pnpm` and set up a liberal `minimumReleaseAge`: https://pnpm.io/settings#minimumreleaseage

Thankfully, it's on by default since v11.

They're probably refering to their strict "No LLM / No AI" policy: https://codeberg.org/ziglang/zig/src/branch/master/README.md...

which applies to contributing to the Zig project.

The "contributor poker" blog post should probably be a required reading to understand where it comes from: https://kristoff.it/blog/contributor-poker-and-ai/

"Anti-AI stance" is painting it with too broad of a brush. You're definitely not breaching any CoC or whatever by using AI for your Zig projects.

I always wanted my car to feel like a plane pilot cabin.

Dunno, people hate the all-touch trend so much (I've never come across someone who likes it), it surprised me it took them so long to reverse course.

I read it as finding a happy medium between analog and digital i.e. people will love the big screen if they still have physical buttons for all the functions they use often while driving. If you force them to fiddle around with touch screen for everything, they'll hate the big screen alltogether because the experience frustrates them.

It's more the hope that he can bring the culture embedded in the hardware division over to software, which hopefully results in better software.

Small countries are already doing this through the Internet since so much of the consumed content is in English.

Sure, this is the issue tracking the work: https://codeberg.org/ziglang/zig/issues/30677

The idea is to offer some kind of CLI parsing in the std. It says minimal, but the discussion also veers into some more advanced options.

The discussion resulted in two PRs (that I know of):

- Type-driven: https://codeberg.org/ziglang/zig/issues/30677

@dotcarmen extracted it into a package (https://codeberg.org/dotcarmen/clip) so people could more easily try it out.

- Composition-based: https://codeberg.org/ziglang/zig/pulls/31620

If you're familiar with Rust's clap, it's a bit like derive vs builder API.

You can also see how each approach would look in practice if you inspect the diff for the "tools" directory on the PRs.

I didn't understand him that way. It's more that it helps if people can more easily pick up a foreign language, or solidify their skills, along the way through media. Doubly so when it's a lingua franca like English.

Though for you, I understand you might have been peeved if people kept switching to English when you just wanted to practice Dutch.

Subtitles all the way. Only advantages of dubbing I can see is accessibility for vision impaired and employment opportunities for local VA talent.

But dubbed live action media is such a horrid experience for me.

The approach feels like a natural extension of Zig's philosophy about explicitness around low-level operations (no hidden control flow, no hidden memory allocations, etc.). Your function can be blocking? Communicate that through the function signature! Very in style for the language.

Obviously, I/O as an interface is the headliner here, but there are lots of other goodies to pay attention to, such as the "juicy main".

Small integers auto coercing into floats is a nice gift to game devs. It's nice that game dev is acknowledged as one of the niches Zig can target as I believe it could really thrive there due to how easily it can integrate with C & C++. Or, rather, more easily than the alternatives.

It's the dark horse of this release as CLI parsing can also be more easily built on top of it. There's a couple of proposals floating around now, so I hope we get something soon-ish (maybe in 0.18 since a short cyle is planned for 0.17).

It doesn't necessarily mean they're going to migrate from C, building a C project is just so much nicer with Zig than fiddling around with CMake. You got people using it as a build system even for Go projects, especially if they're relying on CGo.

However, if you were entertaining the idea of slowly switching to Zig, the build system would be the place to start. Moving away from CMake is worth it even if you don't push it further.

But yeah, the C-Zig interop story is so good it's a no brainer if you want to "modernize" your C codebase, and you can do so incrementally instead of stopping the world for a rewrite.

It's a lower-level component in so much stuff we're not even aware of.

My guess is they meant metaprogramming in general (templates/generics, macros), but traits are not quite like the others.

That's a bit harsh, depending on how a person developed or where they worked they may not have had exposure to other facets beyond basic development. Beyond that, it might as well be magic. They'll have to figure out how to provision a VM, ssh into it & lock all the proverbial doors first. Without going into managing it with IaC tools like Terraform, Ansible, Packer, etc.

A truly lean team (say, <=5 people and limited project scope) should be able to live off their code forge's free CI/CD minutes, or whatever is included in the basic tier they're running. Just run the suite on a schedule against trunk instead of on every PR.

If not, then that's a good signal they should invest more into their CI/CD setup, and like you said it's not necessarily a huge investment, but it can be a barrier depending on skills.

I'd say LLB is the "standard", Dockerfile is just one of human-friendly frontends, but you can always make one yourself or use an alternative. For example, Dagger uses BuildKit directly for building its containers instead of going through a Dockerfile.

Maybe if you only look at it through the lens of building an app/service, but containers offer so much more than that. By standardizing their delivery through registries and management through runtimes, a lot of operational headaches just go away when using a container orchestrator. Not to mention better utilization of hardware since containers are more lightweight than VMs.