[HN Gopher] Zig now has built-in HTTP server and client in std
___________________________________________________________________
Zig now has built-in HTTP server and client in std
Author : huydotnet
Score : 141 points
Date : 2023-05-18 17:57 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| naikrovek wrote:
| yesss, been waiting for this, though I've waited long enough that
| I forgot why I wanted it.
|
| it hasn't been that long, I'm just an airhead.
| tills13 wrote:
| why does _literally_ every line start with "try"?
| formerly_proven wrote:
| A lot less verbose than "if err != nil { /* 2-3 lines */ }"
| after every substantive line.
| C-x_C-f wrote:
| More like `catch |err| return err` so not that big of a
| saving but yeah it's more convenient
| dundarious wrote:
| Same meaning as the Rust "?" operator.
| syrrim wrote:
| A middle ground between exceptions in c++ and checking every
| function call for an error code in c.
| defen wrote:
| It's not literally every line, but `try` means "unwrap the
| error union result or pass the error back up to the caller".
| It's roughly equivalent to Rust's `?` operator (although Rust's
| can also unwrap optionals or return `None`)
| zamnos wrote:
| ~$ curl
| https://raw.githubusercontent.com/ziglang/zig/7cf2cbb33ef34c...
| 2>/dev/null | wc -l 541 :~$ curl
| https://raw.githubusercontent.com/ziglang/zig/7cf2cbb33ef34c...
| 2>/dev/null | grep '^[ ] _try ' | wc -l 114
|
| 541 != 114
|
| Did you mean _figuratively*?
| regulation_d wrote:
| I mean if the OED allows for a metaphorical or hyperbolical
| meaning, I think you're fighting a literal uphill battle.
| paulddraper wrote:
| * every substantive line
| laserbeam wrote:
| It makes it obvious that those calls can fail. Every single
| write to disk, network or malloc can in theory fail. This just
| makes it obvious that some code needs to handle those edge
| cases (or, ykno, you can pass them on to the human user).
| martinhath wrote:
| Not just in theory, they can, and do, fail in practice.
| laserbeam wrote:
| Agreed. Poor choice of word there.
| cturtle wrote:
| In addition to the other answers, this is the most logical way
| to handle most errors in this specific type of code. The http
| code in the Zig standard library doesn't know how the
| programmer wants to handle all the errors, so it uses try to
| bubble up any error it doesn't know how to handle.
|
| Why so many uses of try? Because Zig is all about readability,
| and anytime you see try you _know_ that the called function can
| possibly fail.
| AndyKelley wrote:
| welcome to networking, where every operation can fail
| bricss wrote:
| It can even parse JSON out-of-the-box! \m/
| eatonphil wrote:
| I love this but I had heard they wanted to remove it from the
| standard library once they introduce a package manager. I hope
| it stays in personally!
| jchw wrote:
| Very nice!
|
| I couldn't grok from this test suite alone, but I do have
| questions.
|
| 1. Do either the server or client support 'full duplex', i.e.
| streaming the response body while streaming the request body in
| parallel?
|
| 2. Are there provisions for HTTP/2?
|
| I'll answer my own questions if I find the answers first, but I'm
| not very good at Zig.
| [deleted]
| pfyra wrote:
| Regarding 1, do you mean that the server would send the
| response before the request has been received completely? Or is
| the response for a different request?
| orbz wrote:
| Probably for HTTP Pipelining:
| https://en.wikipedia.org/wiki/HTTP_pipelining
| 1vuio0pswjnm7 wrote:
| HTTP/1.1 pipelining is not the same as HTTP/2 multiplexing.
|
| Obviously, one cannot multiplex with HTTP/1.1, but AFAIK
| there is still a question of whether someone can pipeline
| (not multiplex) with HTTP/2. HTTP/2, introduced by an
| advertising company and developed in part by CDN service
| providers, is designed for web pages that auto-load
| resources from a variety of hosts, namely advertising
| servers. It's commercially-focused.
|
| Here is an old example of using HTTP/1.1 pipelining. For
| the basic task of fetching many files from same host over a
| single TCP connection.
|
| https://www.daemonology.net/phttpget/
|
| Of course there is much more than one can do with HTTP/1.1
| pipelining, such as fetching 100s or 1000s or pages, as
| "streaming" text/html, from a website in a single TCP
| connection. It is also possible to HTTP/1.1 pipeline POST
| requests. IME, HTTP/1.1 pipelining is generally fast and
| reliable, a very useful and convenient feature for web
| users, one that I have been using for two decades.
|
| HTTP/2 proponents on HN will sometimes insist that HTTP/1.1
| pipelining is entirely supplanted by HTTP/2 multiplexing,
| ignoring that the web can also be used for non-commercial,
| non-advertising purposes. They will argue that HTTP/1.1
| pipelining is useless because it is not supported by web
| browsers and cannot support improved e-commerce accompanied
| by online advertising, data collection and tracking, e.g.,
| websites comprised of resources from a variety of hosts,
| especially advertisers.
|
| This is a mistake. HTTP/1.1 pipelining and HTTP/2
| multiplexing are two different things and they can and they
| will co-exist. The web is not just for Google and other so-
| called "tech" companies. Nor is it only for their chosen
| HTTP clients, "Chrome" and what not. The web is not just
| for commerce. It is for non-commercial web users, too. It's
| open to all HTTP clients, including this one from Zig. The
| web is a public resource.
| laserbeam wrote:
| My understanding is http/2 is out of scope. The purpose is to
| have functional http to implement the package manager. I would
| expect a high performance http client/server to be a third
| party library, not std lib.
| EscapeFromNY wrote:
| If that's the only purpose, why is there an http server too?
| The package manager should only need an http client.
| squeek502 wrote:
| My understanding is that it's there to allow for testing
| the client. Relevant issue:
| https://github.com/ziglang/zig/issues/910
| jsyolo wrote:
| To host packages metadata?
| brundolf wrote:
| Does a package manager not benefit from high-performance
| parallel HTTP (for downloading a bunch of little files)?
| kcbanner wrote:
| The package manager is designed to download archives
| (.tar.gz) of packages, not the composite files.
| aseipp wrote:
| Most source code packages, including their metadata, are
| generally small even as an aggregated compressed file,
| and it's very common to download a lot of them all at one
| time once you've resolved the necessary dependencies. It
| depends on several factors though -- including community
| ones (are lots of tiny packages encouraged?) and how
| things like the build system work when downloading
| things.
|
| In practice, it's very much an appropriate use case for
| multiplexing, if you ask me. But not having it isn't a
| dealbreaker either, IMO. It's a bit more work to support
| HTTP/2 and can be done rather transparently later on
| anyway, since the underlying transport can be switched
| and has an upgrade path.
| von_lohengramm wrote:
| > are lots of tiny packages encouraged?
|
| Very much the opposite
| laserbeam wrote:
| Sure. But I wouldn't do that for 1.0 of the lang. It sounds
| quite feasible to add support for that in 1.x if the
| community needs it. There's a reasonable path to upgrade to
| http/2 while spending more effort into what's critical for
| the lang to get to 1.0.
|
| [Edit] And it's quite feasible to decide later that http/2
| was never needed for this usecase.
| brundolf wrote:
| Sure, but GP was saying "out of scope" in a way that
| sounded like "forever, for this use-case", not just "for
| 1.0". I may have misinterpreted
| WhereIsTheTruth wrote:
| Zig starting to look nice, but compile speed is painfully slow..
|
| Everyone wants to go after Go, but they fail to understand how
| important compile speed is
| slimsag wrote:
| Zig is working on incremental linking, and even hot-code-
| swapping while your program is running. I would suggest Zig
| cares more about compilation speed than most other languages,
| just hasn't gotten there yet.
| VWWHFSfQ wrote:
| Is there a Rust vs Zig war going on? I just started to learn Rust
| because I figured that it was going to be the C++ successor and I
| want to be sure that my skills are (somewhat) future-proof. So
| what's going on with Zig? Should I learn Zig?
| secondcoming wrote:
| Modern software engineering summed up in two sentences...
|
| Use which ever one you enjoy using.
| snacktaster wrote:
| Rust is by far the more mature option if you're really trying
| to replace C++. Zig is personally interesting to me though. But
| if you need to write actual production critical code then you
| should definitely go with Rust.
|
| Honestly, it's still a little bit surreal to me that I won't
| even consider C++ now for a new project after so many years of
| my career.
| infamouscow wrote:
| You can use both. There's no need to make binary choices or
| create division. Only fools mimic such behavior.
| arp242 wrote:
| "Rust vs. Zig" is like "Ruby vs. Python": both languages occupy
| more or less the same space, but have a rather different
| approach to things. Which is "better"? It's kind of a matter of
| preference and taste.
|
| That said, Zig is still very much in active development and
| isn't stable. For example the upcoming 0.11 release will change
| some syntax. Personally I like Zig, but you need to be prepared
| to deal with these kind of changes and instabilities for the
| time being, much like early Rust adopters had to before 1.0.
| Also the Zig ecosystem is less mature: fewer libraries,
| learning resources, etc. Purely objectively speaking, I think
| that's the biggest difference at this point.
| bobbylarrybobby wrote:
| My understanding is that rust is a better C++, Zig is a better
| C. They're better than their respective antecedents in
| different ways (Rust is memory safe, Zig is ergonomic).
| FpUser wrote:
| It is not "better" it is different. Rust is "safer" although
| with the modern C++ along with tooling I do not really
| encounter any safety issues for about 3 years already.
| Looking at feature set C++ has way more. In my opinion Rust
| sits somewhere between C and C++.
| slondr wrote:
| I see this line repeated a lot, especially in Zig spaces, but
| it doesn't really make sense to me. Rust is an excellent
| replacement for C, even though it has more features. What
| makes C the language of choice for so many applications is
| not its lack of features.
| brigadier132 wrote:
| This is a silly way of comparing these languages.
|
| Zig and rust are both modern iterations of low level
| languages.
|
| Rust chooses safety with more complex syntax. Zig chooses a
| less complex syntax with less safety.
| AndyKelley wrote:
| You can just ignore Zig. It will be there for you when you want
| it, and it will take you less than an hour to learn when the
| time comes that you want to use it.
| lytedev wrote:
| Well, I was maybe considering ignoring it... until its
| creator told me to.
|
| You can't tell me what to do!
| kristoff_it wrote:
| > So what's going on with Zig?
|
| It's a language made for people who like to do things a certain
| way both in terms of technical details (eg no macros, no hidden
| control flow) and when it comes to governance of the project
| (small, independent, non-profit organization free from big tech
| influence). While we do believe that there's value in this
| approach, this doesn't mean any other way of doing things is
| now obsoleted in favor of what we're doing :^)
|
| More in general, Zig and Rust are different enough that if you
| spend enough time to properly evaluate both, you will probably
| find one more congenial to you than the other. I like Zig
| because I like simplicity, somebody else might like Rust
| because they like sound memory safety guarantees and a powerful
| type system.
|
| You shouldn't see Zig as a threat to Rust, also because Rust
| already succeeded pretty much, and in fact I would recommend
| Rust as the much safer bet if you're looking for a new language
| to bet on, all else being equal.
|
| > Is there a Rust vs Zig war going on?
|
| Uhhh, no? There are certainly different sensibilities at play
| when it comes to the different communities, but that's it. I
| think I understand where this is coming from, but I really feel
| compelled to point out that I find crazy how people get really
| worked up when it comes to programming languages and
| immediately assume there has to be a fight for ultimate
| dominance there, while instead are completely oblivious about
| actual wars being fought under their noses. If you want to look
| at a war, watch Deno vs Bun, where different VCs have backed a
| different horse, and now they truly are in a battle for
| dominance. The ZSF has taken no VC money, has no big tech
| company brand to bolster, and lives off of donations. We just
| want to be able to move forward with the development of Zig
| and, for as long as we can do it, all is good, no need to
| convert the entire planet.
|
| If you do end up evaluating Zig, I would recommend reading
| these two non technical blog posts about the ZSF & the people
| involved with it:
|
| https://kristoff.it/blog/interfacing-with-zig/
| https://kristoff.it/blog/the-open-source-game/
| IshKebab wrote:
| Not any more than there was a C/C++ war. C++ is for people that
| aren't scared of features and want their code to be reliable. C
| is for people that really value simplicity and don't care about
| the odd segfault or catastrophic security vulnerability (in
| some situations that is reasonable).
|
| It's basically the same with Rust vs Zig.
| alchemio wrote:
| Wow, so much ignorance in one comment. So C people choose an
| unreliable language and don't care about catastrophic
| security vulnerabilities! All that when most safery-critical
| and realtime software is written in C. In addition to
| whatever OS you're currently using!
| skybrian wrote:
| Popular programming languages don't get replaced, even by
| something that's mostly a superset. C++ didn't mean the end of
| C.
|
| So I'd say stick with your plan, as there is going to be Rust
| around for a long time.
|
| It's rather early to learn Zig, as it's not stable yet. It
| might be worth learning if you're curious and want to tinker.
| _hypx wrote:
| You can always learn both. They do not really compete against
| other as one is aiming to replace C++ and the other C.
| nusaru wrote:
| Relevant autodocs:
|
| Server:
| https://ziglang.org/documentation/master/std/#A;std:http.Ser...
|
| Client:
| https://ziglang.org/documentation/master/std/#A;std:http.Cli...
| impulser_ wrote:
| I wish more programming languages provided interfaces for
| building libraries around the std library like what Go does. It
| makes using libraries a lot better because you aren't dependent
| on that library as long as it uses the std library interface.
|
| This is huge for things like database drivers which might become
| outdated or not support certain features. In Go switching
| database drivers in as simple as importing the new library. You
| dont have to change your code.
|
| In rust for example you have to go out and pick a database driver
| and no two libraries will work the same. If you pick one postgres
| library and it becomes outdated you have to go rewrite you code
| to support the next one to move too.
|
| This is why I would never use Rust, or Zig for being things like
| http servers.
| themerone wrote:
| Python, Java, and all of the .NET language have standardized
| database APIs.
| xyproto wrote:
| Go also have standardized HTTP handlers, and a standardized
| io.Writer interface for writing to anything, like a file,
| buffer or a HTTP reply.
| impulser_ wrote:
| Yeah, but Go provides this for almost everything in the STD.
| io, networking, http, sql, and so on.
| slimsag wrote:
| If you are familiar with Go, you're gonna be at home with
| Zig's standard library in general. `std.io.writer`,
| `std.io.reader`, `std.io.multiWriter`, etc. are all there
| and pretty similar to Go's interfaces.
| andrewchambers wrote:
| While in general I agree, database libs are probably the worst
| example of this - in practice you can't just swap sqlite for
| postgres or mysql. I usually avoid the generic driver wherever
| possible and use one specific to my database.
| impulser_ wrote:
| You actually can, you might have to update some of your
| queries but if you use basic SQL queries you can switch
| drivers without changing code.
| anonymoushn wrote:
| In Go if you'd like to make an interface-compatible database
| driver, you have to construct structs with non-exported fields
| from another package using unsafe.
| impulser_ wrote:
| database/sql provides a generic interface for SQL which
| drivers use to build their libraries. You can switch from one
| postgres driver like pq to pgx easily because they both
| support database/sql.
| jtanza wrote:
| As someone who only has some minor experience with Go, can you
| maybe elaborate a bit on what you mean by the stdlib providing
| such interfaces? I don't recall any such paradigm being called
| out when first learning the language and it sounds pretty
| interesting.
| 2h wrote:
| https://github.com/mattn/go-
| sqlite3/blob/master/_example/sim...
|
| notice that the SQLite package isn't used directly, its only
| imported to handle the database behind the scenes. all the
| actual code is written using only the standard library
___________________________________________________________________
(page generated 2023-05-18 23:00 UTC)