Interesting read. There are instances when you need unlimited capacity, and there is a proposal for it: https://github.com/golang/go/issues/20352
It doesn’t look like it will make it as the maintainers are opposed to it.
Huh, CF Workers used to limit the payload to 1MB, and any slightly nontrivial golang js/wasm artifact (not tinygo) I’ve ever built was >2MB compressed, so the idea of running those on CF Workers was dead on arrival. However, apparently the limit was raised to 5MB for paid plans some time last year.
You're skipping over all the emails that explain that it's not a fundamental limitation, many of the falliable allocation APIs already exist and many others have been in planning for a long time.
I think specific flavors of unlimited make sense. It sounds like Corkboard can offer unlimited storage but with a cap of 50MB on files. The number of people willing to jump through the hoops required to make that truly unlimited is likely very few.
We do a similar thing at LayerVault. We offer unlimited storage and versioning of design files, but only for design files we support.
I think there are still some limits applied even on cutting edge hardware. GitHub previously said they hit network limitations cloning their multi-gb repo for instance.
No, it’s not. My concern isn’t this particular implementation, it’s that implementations will keep using up larger and larger chunks of adressable space.
Thinking something is unlimited is the fastest way to find out that it is.
This is pretty neat. I looked at the current limitations, though, and a lot of them are things that damage performance, or greatly limit compatibility (TCP-only, no client certs, lzo compression required, only one choice of algorithm). I expect many of these will get fixed over time.
I'm pretty sure even back then you could edit the hard-coded limit in the source code and recompile. I remember us doing something like this as it was too expensive to just keep buying servers and our apps were connection-happy.
Most 'unlimited' things still have some max. Using a BIGINT for your primary key will get you a max of 18446744073709551615. Should we complain that we can't go higher in any application that uses one of these?
Slack's advertisement for unlimited users was based on their product's design. Their hard limit is perfectly reasonable because the interface wasn't really designed to handle 10k users in the first place.
To complain about this is like buying a sailboat and complaining when you sail it into a hurricane.
My claim is that it’s not easy, not impossible. There’s little incentive to hack in JavaScript or maintain a Pyodide compatible build. The 4gb limit isn’t a technical limitation, just a standards thing (it could change easily).
Yes but that is an artificial limit and not an architectural limitation. i.e. a feature added to code that was once / would have been infinite otherwise.
reply