I have never once in my life cared about where a programming language kept its source and I think if anyone is using that as a basis for decision-making, they are truly a moron.
I don't care if it's on GitHub at all, it's not hard to work with any arbitrary git remote. CVS would be a weird choice, but it wouldn't be a dealbreaker on its own. Fossil or some other modern alternative VCS wouldn't be a red flag or weird at all.
But I wasn't talking about contributing to the language, which is a weird standard to use here since Zig isn't interested in outside contributors. I was talking about choosing a programming language for use for some professional or personal project. I don't give a fig what version control solutions the team chooses to use if the language is good and solves my problems, and I would consider it very strange if someone tried to argue that I shouldn't use some language because they put their code on a non-Microsoft owned server.
I generally agree with you that choosing something based on where it's hosted is dumb. I still think there could be an impact wrt a network effect.
The original comment you replied to was talking about "the loss of network effect" and you sounded dismissive of it. It might not even matter, but I think it's somewhat fair to say it could have an impact.
I agree. It's possible in the future a project hosted on codeberg is a silent "stamp of quality". Though, I still think there could be impact wrt a network effect.
What I assume you mean is not the network effect, where more users of a product makes the product more valuable. That's still true for Zig as more users increase the ecosystem, funding potential etc. regardless of where the compiler source lives.
I think you mean to say something like barrier to entry for contributors? Where having to sign up for a new service will discourage some engagement with the core repo.
One funny thing is that if you go on codeberg and want to submit a PR to Zig, you can't. Because Zig's too big for Codeberg, and you're over your free quota, so you can't push your update to your fork.
Yes there are ways around it if you have patience, but what the heck!!
Worth noting that while it's absolutely unfortunate that we're hitting this Forgejo design flaw, AGit honestly is just a better workflow, and I (Zig core team member here, full push access to the upstream repo) have started using it for pretty much all of my PRs. There are a couple of small things I'd like to see improved about Forgejo's implementation of AGit, but IMO it fundamentally makes so much more sense than the two-step push-then-PR workflow (especially if you're an external contributor who would also need a first step of "fork the repo").
Two main reasons I don't have this setup already is
- the resource you need to give the VM running opencode to build your projects
- Faster testing
I run pi coding agent right on my mac and I run our entire software suite - example: redis, postgres, kratos, .. etc. With coding agent running on my main development device, I can build faster (assuming opencode VM is a on a low specd machine) as well as test it faster. Example: I can just rebuild the backend and restart it and test it on the UI client with the new changes.
You need tools sufficient to do the job in an economical way, optimizing for both cost and quality. That is what 'best' means. We don't give every engineer all the resources under the sun, only what is appropriate.
I suspect many will realize millions more dollars are being spent than needed to achieve the highest marginal productivity gains, and reallocate accordingly. Who wants more of their money going to developer tooling, rather than bonuses?
Of course. I have a $20/mo Codex subscription that has been serving me very well. Occasionally when I run out of quota, I switch to another one of my backup $20/mo subscription.
That's way more economical and produces far better result than any self hosted models today.
Go has one of the best stdlibs of any language. I'd go as far and say it's the #1 language where the stdlib is the most used for day to day programming. cut the bullshit
You can't comment like this on Hacker News, no matter what you're replying to. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
I cannot identify with this at all. We have Python and Go applications in production, and for Go the vibe is mostly "standard library plus a few dependencies" (e.g. SQL driver, opentelemetry) whereas with Python it's mostly "we need a dozen libraries just to get something done".
For example Go has production ready HTTP server and client implementations in the standard library. But with Python, you have to use FastAPI or Flask, and requests or httpx. For SQL there's SQLAlchemy I guess and probably some other alternatives (my Python knowledge is not that great), whereas again with Go the abstraction is just in the standard library and you only include the driver for the specific database.
We use Renovate to manage dependency upgrades. It runs once a week. Every Python project has a handful or more dependency upgrades waiting every week, primarily due to the huge amount of dependencies and transitive dependencies in each project. The Go projects sometimes have one or two, but most of the time they're silent because there is nothing to upgrade (partly due to just having so few dependencies to begin with).
I don't buy this for one moment. Python and breaking changes are lovers. Nobody I have ever worked with builds or tries to build stdlib python. Most Go devs to pride themselves on minimal dependencies.
