jspdown

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

Who is going to maintain all these forks? The person forking it has no community and can't realistically be an expert in all of these domains.

So no, it doesn't "work", it just worked at some point in the past.

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

All in all, Nix is quite nice for Skills :)

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.

My bad, in the context of the article you are definitely right.

I think I was biased by the fact that this argument was used in an HN comment where people tend to be heavy users of LLM based agents.

This article compares a single ChatGPT query against 1h of video streaming. Not apple to apple comparison if you ask me.

Using Claude Code during an hour would be more realistic if they really wanted to compare with video streaming. The reality is far less appealing.

You can type Option+Enter. A more standard Shift+Enter would have been better but until then that's the best we have

I suppose yes. That's actually what happened with distributed rate-limit.

Looks like it's OpenAI response to Google's Agent Payment Protocol (AP2) but without the micro transaction part.

Do you mind telling us a bit more? I never used OpenCode, what makes it better in your opinion?

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.

I'm wondering if it's not just: spawn multiple time the same prompt and take the best

Thanks for the detailed feedback. This is exactly the kind of input we need.

We're going to work through these points with the team. Appreciate you sticking with Traefik despite the documentation friction.

Traefik maintainer here.

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.

Traefik maintainer here.

You are right, Traefik is fundamentally built around the concept of "providers," which are external systems from which Traefik obtains routing configuration and service/server definitions.

These providers can range from dynamic service discovery systems (like Docker, Kubernetes, Consul) to static configuration sources (file-based configs, HTTP APIs, etc.). The provider architecture is what makes Traefik particularly well-suited for containerized and cloud-native environments where services are ephemeral and discovery is crucial.

Traefik maintainer here.

Traefik is a reverse proxy and load balancer that automatically discovers services and configures routing rules dynamically through integration with various configuration sources such as container orchestrators (Docker, K8s, Nomad, Consul, ECS, ...)

As of today, Traefik is not a web server.

Traefik maintainer here.

I can confirm that bring-your-own certificates, ACME, and mTLS are all included in the OSS version. For enterprise users, Traefik Hub also provides seamless integration with HashiCorp Vault.

Regarding the cache middleware: like many of our more advanced middlewares, you have two options. You can use a community-maintained plugin (such as Souin), or your organization can purchase an enterprise license to access TraefikLabs' officially maintained built-in middleware as part of Traefik Hub API Gateway or Traefik Hub API Management.

Traefik maintainer here.

Documentation quality has been a common complaint. Previously, we only provided reference documentation and relied on the community to create tutorials and guides.

Based on feedback like yours, we've completed documentation rewrite. Have you had a chance to review the new version? Your feedback is taken very seriously, so we'd greatly value your thoughts on these improvements.

With today's state of LLMs and Agents, it's still not good for all the tasks. It took me couple of weeks before being able to correctly adjust on what I can ask and what I can expect. As a result, I don't use Claude Code for everything and I think I'm able to better pick the right task and the right size of task to give it. These adjustment depends on what you are doing, the complexity of and the maturity of the project at play.

Very often, I have entire tasks that I can't offload to the Agent. I won't say I'm 20x more productive, it's probably more in the range of 15% to 20% (but I can't measure that obviously).

I share the same experience. Looking at diffs inside a terminal is as helpful as looking at diffs inside GitHub. I need code navigation to fully understand the impact of a code change or just the code base.

I exclusively use Claude Code these days, and I don't remember having accepted the result of a prompt a single time on the first shot. I always have to fix some stuff here and there, improve some tests or comments or even make the code more readable. Being in an IDE is a must for me, and I don't see how this could change.

It's the 5 best years that you have left to live. It's not nothing indeed.

Yes exactly, each situation is different.

As a team you constantly need to assess whether a dependency should be brought in or of a re-implementation is not better.

Sometimes, the re-implementation is so specific to you actual problem that maintenance becomes almost free. A generic solution always open more doors to problems and require more effort to maintain.

For a rich client web application, you need a really good reason not to bring an external dependency such as React.

There's no free meal and adding a dependency is far from being free. Each dependency you add needs to be carefully reviewed, each of its update as well. Though, apparently many people just YOLO this part.

Jules creates a PR of the changes. Approve the PR, merge it to your branch, and publish it on GitHub.

Then, who is testing the change? Even for a dependency update with a good test coverage, I would still test the change. What takes time when uploading dependencies is not the number of line typed but the time it takes to review the new version and test the output.

I'm worried that agent like that will promote bad practice.