I very much like Go's simplicity, but nils are terrible. Pointers carry 3 different intents that are not encoded in the code:
- Optionality
- Mutability
- Memory optimisation
I agree with the author that when the pointer is here for mutability or to limit copies you need to check nullity at the outer layer. But for optionality you need to check it each time you access that value.
Sometimes the intent is not clear and you are forced to check nullity everywhere. An Option type fixes this but it's not idiomatic Go code and forces to wrap every thing you call
I find this kind of rewrite both disrespectful and completely useless. Useless because the difficulty isn't getting to a working state but maintaining it. You now have to build a community around it to make any of this worthwhile. What would this software be worth if security issues weren't patched and bugs weren't fixed? You can't do this alone.
And I find it disrespectful because people have spent decades building this, and you're taking all that collectively built knowledge to create something that will compete with the project itself.
I hope people will restrain themself from doing this at least in the name of good ethic. I fear this is going to hurt OSS a lot.
I hope people will hold back from this, if only out of respect for the work that came before. I fear it could do real damage to OSS. It would discourage the maintainers whose effort makes any of it possible.
At this stage, AI is no longer a tool that enhances your ability to ship code, it has replaced you entirely in that role. You don't control what is shipped, and you can't verify if it's correct. That's a serious problem! As software engineers, we remain accountable for code we no longer fully understand.
Then, what comes next feels less like a new software practice and more like a new religion, where trust has to replaces understanding, and the code is no longer ours to question.
Don't you need to obtain consent before filming random people in the street? I already feel uncomfortable when someone takes a photo in public and I happen to be in it, but this type of device takes things to an entirely different level. With smart glasses, there's no visible cue that you're being recorded. No phone held up, no camera in sight. I'm questioning the legality of this in Europe, where privacy laws tend to be stricter. In the meantime, should I just assume that anyone wearing these glasses is always filming? And would I be within my rights to ask them to stop the moment I notice them?
I've been using Claude for a little over a year, but the recent events with DoW are making me want to explore European alternatives. I'm willing to give Devstral 2 a try, but I'm not sure what to expect. In terms of tool calling and coding abilities, should I expect something closer to Sonnet 3.5 or to Sonnet 4.5?
Domestic mass surveillance might feel tolerable when you live in the country conducting it. But how would you feel about other countries adopting similar policies, and thereby mass-surveilling the American people? Because that's exactly what these policies authorize when applied to the rest of the world.
On my personal coding agent I've introduced a setup phase inside skills.
I distribute my skills with flake.nix and a lock file. This flake installs the required dependencies and set them up. A frontmatter field defines the name of secrets that need to be passed to the flake.
As it is, it works for me because I trust my skill flakes and skills are static in my system:
-I build an agent docker image for the agent in which I inject the skills directory.
-Each skill is setup when building the image
-Secret are copied before the setup phase and removed right after
I pay a Max subscription since a long time, I like their model but I hate their tools:
- Claude Desktop looks like a demo app. It's slow to use and so far behind the Codex app that it's embarassing.
- Claude Code is buggy has hell and I think I've never used a CLI tool that consume so much memory and CPU. Let's not talk about the feature parity with other agents.
- Claude Agent SDK is poorly documented, half finished, and is just thin wrapper around a CLI tool…
Oh and none of this is open source, so I can do nothing about it.
My only option to stay with their model is to build my own tool. And now I discover that using my subscription with the Agent SDK is against the term of use?
I'm not going to pay 500 USD of API credits every months, no way. I have to move to a different provider.
It's not HTML purism. It's simply recognizing that HTML and CSS have evolved a lot and many things don't need (or are close to not need) JS anymore.
This shouldn't be taken as an anti-JS article, everyone benefits from these gradial improvements. Especially our users who can now get a uniform experience.
There's a bit of UI around it where you can accept the plan. I personally stopped using it and instead moved to a workflow where I simply ask it to write the plan in a file. It's much easier to edit and improve this way.
A significant portion of TraefikLabs' engineering team and maintainers are French. Before each new release, the team holds polls and spirited debates to determine which cheese would be the perfect fit for the version name.
Staying true to French culinary tradition, the enterprise versions are given wine codenames, with each wine carefully selected to pair perfectly with its corresponding cheese release.
- Optionality
- Mutability
- Memory optimisation
I agree with the author that when the pointer is here for mutability or to limit copies you need to check nullity at the outer layer. But for optionality you need to check it each time you access that value.
Sometimes the intent is not clear and you are forced to check nullity everywhere. An Option type fixes this but it's not idiomatic Go code and forces to wrap every thing you call