Sam Mohr (May 11 2024 at 11:26): Sam Mohr (May 11 2024 at 11:26):Is there a discussion already in Zulip as to why the standard library is as lean as it is?
There's not much detail in the GH issue on why JSON was removed. There are some features that are common to most apps, like URLs, UUIDs, JSON, etc. that would normally go in either the standard library or in a package. However, (as I understand it) URLs are in basic-cli so that the code is colocated with its published platform. But we seem to lose portability, meaning basic-webserver and basic-cli both have a URL module. Is there a plan for if/how we will maintain modularity of this code that isn't platform-specific? I know we have module params for libs, but that doesn't seem to be what we're planning for the official platforms.
Brendan Hansknecht (May 11 2024 at 11:28):Is there a plan for if/how we will maintain modularity of this code that isn't platform-specific?
Once module params are in and fully funcitional, we should be able to share a lot more. I think this is more an early ecosystem issue that has designs to fix.
Brendan Hansknecht (May 11 2024 at 11:29):I know we have module params for libs, but that doesn't seem to be what we're planning for the official platforms.
Official platforms are likely to become thinner (with simpler primitives in some cases) and then use libs with module params to expand functionality and share code with other platforms.
Sam Mohr (May 11 2024 at 11:31):Yes, that would make sense to me. I am not pushing against the current approach to moving Weaver's code into basic-cli, as it seems to give the best usability for users at the moment, but this approach of centralizing non-specific modules probably won't be sustainable long-term.
Sam Mohr (May 11 2024 at 11:31):But yes, in a year or so I'm sure things will look much different :smile:
Brendan Hansknecht (May 11 2024 at 11:32):URLs, UUIDs, JSON
I think we lean for most of these types of things to be in packages. They really aren't standard. Many have plenty of valid designs. On top of that, they are not things that make sense in a lot of platforms. So the standard library leans more data structure heavy (especially for datastructures that need support from zig to be performant).
Brendan Hansknecht (May 11 2024 at 11:33):Also, a number of these things are likely to have more churn and we wouldn't want them to require us releasing a new version of roc every time they change.
Sam Mohr (May 11 2024 at 11:34):I know that Rust has also taken a leaner approach to its standard library because it wants to make stability guarantees, and as long as the ecosystem shifts around on implementing libraries for these features (URLs, UUIDs, JSON), then it's not a stable addition to std
Brendan Hansknecht (May 11 2024 at 11:34):This is at least what I have gather from the many discussions over the years.
Richard Feldman (May 11 2024 at 11:45):yeah we could totally have Url be in its own package - I think that makes sense!
Richard Feldman (May 11 2024 at 11:46):normally URLs are just represented as Str, so there's no need for an opaque type there, which means platforms wouldn't need to depend on that package
Richard Feldman (May 11 2024 at 11:47):but if you want to do things like splitting up URL strings into protocol/paths/etc, having a package which does all that would be nice
Sam Mohr (May 11 2024 at 11:54):I'm already working on a UUID package, and the URL code is all there, it wouldn't be too much work! Just a potential issue if we try to split out a library that's needed inside a platform. E.g. URL is in a package, and then the user wants to use the library, but the platform needs types from the URL library as well. Now you have to both import and use the same library version (at least for now).
Sam Mohr (May 11 2024 at 11:54):Still worth the effort IMO, but not free, per se
Richard Feldman (May 11 2024 at 12:24):yeah there's a design for package versioning which addresses that: https://docs.google.com/document/d/1rklo1p2jETKVxhkAtClcMH8N4sHIgePm2JgJ3ciBR60/edit?usp=drivesdk
Last updated: Jul 26 2025 at 12:14 UTC