HN user
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`:
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.
"You turn it on and it scales right up"
is my favorite quote from the video.
And no doubt they’ll find a way to spend it in the app considering you can manage almost all aspects of your life within it.
Revolut works similarly. You don’t pay any fees on transfers to other Revolut accounts, but you do for other bank accounts.
Never, it’s a very effective punctuation mark. While it may not have been common in day-to-day messaging, it’s very common in writing of all sorts.
For something like OpenClaw yes, but not for Zclaw. I think the naming is more about riding the current wave of Claw-related interest rather than positioning it as competition or replacement for other clawies.
Zclaw is about running an agent in your embedded system.
File size is a legit property to keep in mind if your goal is to create an agent that runs on ESP32 boards. They don't expect you to run Zclaw on Mac Mini.