> And then there’s the Stack Overflow Developer Survey.
Honest question, at what point is the Stack Overflow Developer Survey not representative of the average software engineer, many (most?) of who no longer use Stack Overflow?
Good question. I no longer use SO at all, it's been years now, but I still get the yearly developer survey email alert, and I still take the time to answer, I take it most people doing the survey is the same...
true and I'd love to be able to expand support out for the equivalent versions in linux / windows. For now, you can always fall back to using safeStorage on non macOS platforms!
> What about consensus? Elections? Which server is the primary for a given repository? It also doesn't matter! There's no state and no consensus here. Any server can be the primary. All updates to the write-ahead log are synchronized with an atomic compare-and-swap (CAS) operation on S3, so it's always safe for any instance of a repository to receive a push.
Again reminded of what an amaizing piece of engineering S3 is (99.999999999% - 11 nines of durability) [1]
I really enjoyed the article. What's great about the design outlined in it is that it builds on things that work, like leveraging S3 rather than improvising your own distributed storage system.
Of course S3 goes beyond just Amazon these days. It's a proven design and architecture for doing object storage that you find across different cloud providers that you can also self host if you need to.
This article will no doubt inspire people working on projects like forgejo, gitea, tangled, etc. that are all facing the same scaling challenges.
"Great" for the majority of these is a stretch. There's no shortage of complaints about how Spotify treats both artists and customers, and Roblox enjoys yearly controversies from how it provides access to and exploits its customer base of children.
Bruh, Spotify has been absolutely shit, and their practices and push towards AI and completely unusuable suggestions algorithm are making it more and more shit.
The more I write software, the more I think errors should be first-class citizens (camp #2 from the OP's post).
I've been using https://github.com/biw/enwrap (disclaimer: I wrote it) in TypeScript and have found that the overhead it adds is well worth the safety it adds when handling and returning errors to users.
That said, I see parallels between the debate about typed vs. non-typed errors and the debate of static typing vs. dynamic typing in programming languages.
> I see parallels between the debate about typed vs. non-typed errors and the debate of static typing vs. dynamic typing in programming languages.
Author of the post here. I also see this parallel in error handling discussions. But seems like it's much harder to sell error handling than static typing. Static typing was also much more debatable in the past then now so maybe same can happen to error handling mechanisms in the future as well.
Your project seems very interesting! Typescript is sophisticated enough to model complex Result-like types that can narrow-widen error cases throughout the code. I will check it more if I find the time.
The biggest problem I see is that, like static/dynamic typing, it's usually a boil-the-ocean problem. Most languages have historically been static or dynamically typed. Only recently have TypeScript and Python allowed for migration from dynamic to static typing, introducing millions(?) of developers to static types in the process.
With errors, it's hard since many languages can throw errors anywhere, so it's hard to feel like any function is "safe" in terms of error handling. That's one of the reasons why `enwrap` returns a generic error alongside any other result: to support incremental adoption.
If you have a chance to check out `enwrap` and have feedback, email me! (link in bio)
My only issue with kitty and tmux is that I always have to copy over my terminfo files manually or else I get a 'xterm-kitty': unknown terminal type error.
I'd say it's less about covering all edge cases and more about showing that text editors are insanely complex, and it doesn't take long to find edge cases that text editors with 10s/100s of millions of users have.
The chances that this would survive ICANN's dispute-resolution policy [2] is very low:
> (iii) your domain name has been registered and is being used in bad faith.
I don't think putting up a page asking for $1M would pass the "bad faith" test
1: https://x.com/polycoolintern/status/2090532162067918941 2: https://www.icann.org/resources/pages/policy-2024-02-21-en