5 ms·

Looks like there's active work going into it (1) (2), but Zig's lack of built-in http library has been a showstopper for me. I've had a few small side projects

by latch 6y ago

Looks like there's active work going into it (1) (2), but Zig's lack of built-in http library has been a showstopper for me. I've had a few small side projects I wanted to do which involved exposing an API. (1) https://github.com/ziglang/zig/issues/910 https://github.com/ziglang/zig/issues/910 (2) https://github.com/ziglang/zig/issues/2007 https://github.com/ziglang/zig/issues/2007

deleted 6y ago
[deleted]
mseri 6y ago
I am still torn about this. I can see the usefulness of it from python and go, but I also fear that it brings an unnecessary large maintenance burden. Http standards are evolving and soon the implementation will get stale, being in the standard library there will be need to updated it and possibly maintain backwards compatibility, even when it becomes clear that a new design may be a better option. So, suddenly people will start using new, often better, libraries but you need to keep find workforce to maintain the old stdlib http library. That is mostly why I keep thinking that it would be better to have it as a separate library, with an easy-to-use package manager to discover and use it.
- coldtea 6y ago
  >I am still torn about this. I can see the usefulness of it from python and go, but I also fear that it brings an unnecessary large maintenance burden. Http standards are evolving and soon the implementation will get stale, Why would it "get stale"? It doesn't get stale in Golang. If anything, being part of the standard library is a greater assurance for more eyes going into it, and not having it get stale, as opposed to the language having 5-6 half-abandoned third party libs...
  - flohofwoe 6y ago
    Keep in mind that a HTTP server is only useful for a subset of users, it might be an "obvious" requirement for you, but it definitely isn't for me ;) Features like this should go into libraries, but not the standard library. When looking for a Go or Python alternative, Zig doesn't immediately come to mind TBH. Also: Go (or python) has no UI system or 3D API wrapper in the standard library, but those are (probably) useful for at least as many people as a HTTP server. Does that mean that Go should get UI and 3D-rendering support in the standard library?
    - coldtea 6y ago
      >Keep in mind that a HTTP server is only useful for a subset of users, it might be an "obvious" requirement for you, but it definitely isn't for me ;) Yes, but that "subset" is huge. >Also: Go (or python) has no UI system or 3D API wrapper in the standard library, but those are (probably) useful for at least as many people as a HTTP server. Not in the backend/network server world that Go primarily targets...
      - moldavi 6y ago
        Whats your criteria/cutoff for what should be in a standard library?
    - detaro 6y ago
      Python has Tk bindings in the standard library at least, which are usable if you just want "an GUI" quickly.
kzrdude 6y ago
Why a http server in the standard library? It's quite likely to end up where Python 3's http.server module is: "Don't use this in production". So when can I then use it? It's mostly a party trick of a module, then.
- acqq 6y ago
  Exactly. Probably better using some established C http library in Zig? Using C libraries is very easy in Zig, as far as I understand. What‘s the problem in using Libcurl?
- q3k 6y ago
  Yet, Go’s net/http client/servers are fully production ready. This can be done right. Being able to just use them without having to follow the newest trends in a language’s ecosystem is a huge cognitive burden off my mind.
  - kzrdude 6y ago
    That is great. Maybe I should ask, what is it that makes Python standard lib modules likely to end up like this? The list is pretty long.
    - cesarb 6y ago
      The Python standard library is old. For instance, urllib.urlopen() already existed in Python 1.4 (the oldest I could quickly find docs for), which is from 1996. Things that were useful back then (like a built-in uuencode module) no longer make much sense as part of the standard library. And mistakes in the API of a standard library are hard to fix without breaking backwards compatibility, while a third-party module can, in the worst case, be discarded and replaced by a newer one.

by latch 6y ago

deleted 6y ago

[deleted]

mseri 6y ago

I am still torn about this. I can see the usefulness of it from python and go, but I also fear that it brings an unnecessary large maintenance burden. Http standards are evolving and soon the implementation will get stale, being in the standard library there will be need to updated it and possibly maintain backwards compatibility, even when it becomes clear that a new design may be a better option. So, suddenly people will start using new, often better, libraries but you need to keep find workforce to maintain the old stdlib http library. That is mostly why I keep thinking that it would be better to have it as a separate library, with an easy-to-use package manager to discover and use it.

coldtea 6y ago
>I am still torn about this. I can see the usefulness of it from python and go, but I also fear that it brings an unnecessary large maintenance burden. Http standards are evolving and soon the implementation will get stale, Why would it "get stale"? It doesn't get stale in Golang. If anything, being part of the standard library is a greater assurance for more eyes going into it, and not having it get stale, as opposed to the language having 5-6 half-abandoned third party libs...
- flohofwoe 6y ago
  Keep in mind that a HTTP server is only useful for a subset of users, it might be an "obvious" requirement for you, but it definitely isn't for me ;) Features like this should go into libraries, but not the standard library. When looking for a Go or Python alternative, Zig doesn't immediately come to mind TBH. Also: Go (or python) has no UI system or 3D API wrapper in the standard library, but those are (probably) useful for at least as many people as a HTTP server. Does that mean that Go should get UI and 3D-rendering support in the standard library?
  - coldtea 6y ago
    >Keep in mind that a HTTP server is only useful for a subset of users, it might be an "obvious" requirement for you, but it definitely isn't for me ;) Yes, but that "subset" is huge. >Also: Go (or python) has no UI system or 3D API wrapper in the standard library, but those are (probably) useful for at least as many people as a HTTP server. Not in the backend/network server world that Go primarily targets...
    - moldavi 6y ago
      Whats your criteria/cutoff for what should be in a standard library?
  - detaro 6y ago
    Python has Tk bindings in the standard library at least, which are usable if you just want "an GUI" quickly.

kzrdude 6y ago

Why a http server in the standard library? It's quite likely to end up where Python 3's http.server module is: "Don't use this in production". So when can I then use it? It's mostly a party trick of a module, then.

acqq 6y ago
Exactly. Probably better using some established C http library in Zig? Using C libraries is very easy in Zig, as far as I understand. What‘s the problem in using Libcurl?
q3k 6y ago
Yet, Go’s net/http client/servers are fully production ready. This can be done right. Being able to just use them without having to follow the newest trends in a language’s ecosystem is a huge cognitive burden off my mind.
- kzrdude 6y ago
  That is great. Maybe I should ask, what is it that makes Python standard lib modules likely to end up like this? The list is pretty long.
  - cesarb 6y ago
    The Python standard library is old. For instance, urllib.urlopen() already existed in Python 1.4 (the oldest I could quickly find docs for), which is from 1996. Things that were useful back then (like a built-in uuencode module) no longer make much sense as part of the standard library. And mistakes in the API of a standard library are hard to fix without breaking backwards compatibility, while a third-party module can, in the worst case, be discarded and replaced by a newer one.