17 ms·
Zig now has built-in HTTP server and client in std
- jchw 3y agoVery 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.
- pfyra 3y agoRegarding 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 3y agoProbably for HTTP Pipelining: https://en.wikipedia.org/wiki/HTTP_pipelining https://en.wikipedia.org/wiki/HTTP_pipelining
- 1vuio0pswjnm7 3y agoHTTP/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/ 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.
- jrockway 3y agoWhy is HTTP/2 corporate? Why use HTTP if interoperability with browsers isn't a concern?
- akkartik 3y agoHTTP/1.1 is supported by all browsers, right? Using it doesn't give up any interop. At least until said ad company develops enough of a monopoly to move into the Extinguish phase. I don't know anything about pipelining or multiplexing, but I too have the impression standards bodies are now dominated by large browser vendors. Older standards therefore seem less corporate.
- 1vuio0pswjnm7 3y ago"Using it doesn't give up any interop." And interop is quite valuable for web users. But for the so-called "tech" companies and CDN service providers authoring the HTTP/2 RFCs, maybe not so much. Who receives the primary benefit of HTTP/2. Certainly not web users. Perhaps they get some small secondary benefits. What does not make any sense to me is why past/present Googlers and other HTTP/2 proponents voting and replying on HN are offended by someone who likes using HTTP/1.1. For pipelining. The (non-browser) interop is much better than HTTP/2. That is, using 1.1, I can pipeline HTTP to/from almost every httpd on the internet, using a vast array of TCP clients written over a long period. If I want to use HTTP/2/, the number of libraries and clients is much smaller and all are recent. Further, AFAIK these clients cannot pipeline the way 1.1 does, retrieving many files from same host sequentially over single TCP connection, in the order they were requested, with HTTP headers. Google existed when RFC2616 came out. If it is so flawed then why not try to change it then. HTTP/2 is flawed for what Google and other so-called "tech" companies want to do, always with a browser or mobile OS they control, not necessarily what web users want to do, with whatever clients web users choose, 100% of the time. We've seen the stuff so-called "tech" companies get up to and it usually involves surveillance to support commerce. HTTP/2 isn't going to solve or alleviate any of those ills. To keep the Wall Street analysts happy, Google will not be adding to their browser, inspiring and backing standards that translate to less profit for Google. If a new standard decreases the amount of data collection or tracking, that's less profit for Google. HTTP/2 is not such a standard.
- deleted 3y ago[deleted]
- laserbeam 3y agoMy 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.
- brundolf 3y agoDoes a package manager not benefit from high-performance parallel HTTP (for downloading a bunch of little files)?
- kcbanner 3y agoThe package manager is designed to download archives (.tar.gz) of packages, not the composite files.
- aseipp 3y agoMost 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 3y ago> are lots of tiny packages encouraged? Very much the opposite
- laserbeam 3y agoSure. 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.
- naikrovek 3y agoyesss, 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 3y agowhy does _literally_ every line start with "try"?
- dundarious 3y agoSame meaning as the Rust “?” operator.
- tialaramex 3y agoRust's ? is the Try operator, which is currently contemplating Try::branch() to produce a ControlFlow and then if the ControlFlow is Break it returns whatever is inside the Break. Historically ? was just doing what try! did but while that's equivalent to the current behaviour for Result, there are several more implementations of the Try trait today (and in nightly you can implement it on your own types)
- syrrim 3y agoA middle ground between exceptions in c++ and checking every function call for an error code in c.
- defen 3y agoIt'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 3y ago~$ curl https://raw.githubusercontent.com/ziglang/zig/7cf2cbb33ef34c1d211135f56d30fe23b6cacd42/test/standalone/http.zig https://raw.githubusercontent.com/ziglang/zig/7cf2cbb33ef34c... 2>/dev/null | wc -l 541 :~$ curl https://raw.githubusercontent.com/ziglang/zig/7cf2cbb33ef34c1d211135f56d30fe23b6cacd42/test/standalone/http.zig https://raw.githubusercontent.com/ziglang/zig/7cf2cbb33ef34c... 2>/dev/null | grep '^[ ]try' | wc -l 114 541 != 114 Did you mean figuratively*?
- 3y ago
- nusaru 3y agoRelevant autodocs: Server: https://ziglang.org/documentation/master/std/#A;std:http.Server https://ziglang.org/documentation/master/std/#A;std:http.Ser... Client: https://ziglang.org/documentation/master/std/#A;std:http.Client https://ziglang.org/documentation/master/std/#A;std:http.Cli...
- bricss 3y agoIt can even parse JSON out-of-the-box! \m/
- eatonphil 3y agoI 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!
- VWWHFSfQ 3y agoIs 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?
- snacktaster 3y agoRust 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 3y agoYou can use both. There's no need to make binary choices or create division. Only fools mimic such behavior.
- arp242 3y ago"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 3y agoMy 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).
- slondr 3y ago
- impulser_ 3y agoI 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.
- jtanza 3y agoAs 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 3y agohttps://github.com/mattn/go-sqlite3/blob/master/_example/simple/simple.go 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
- themerone 3y agoPython, Java, and all of the .NET language have standardized database APIs.
- xyproto 3y agoGo also have standardized HTTP handlers, and a standardized io.Writer interface for writing to anything, like a file, buffer or a HTTP reply.
- 3y ago
- WhereIsTheTruth 3y agoZig 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 3y agoZig 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.
- norir 3y agoThe Zig compiler is significantly limited in performance by the llvm backend. Even with a different backend, I also suspect that the language is already complex enough that it is difficult to write a genuinely fast compiler (by which I mean a compiler that can produce good machine code from most files less than say 10k lines of code in under 50ms, which I am quite certain is possible -- but llvm takes about 50ms just to start up and is also slow once it actually starts doing work.) To write a fast compiler, it has to be fast from the start. It is extremely difficult to make a slow compiler fast because usually there are pervasive design issues that cannot be eliminated by hotspot optimization. These design decisions often reflect the design of the language itself, which is to say that some languages are more amenable to fast compilation than others and I suspect that Zig is at best average or slightly above average for languages of similar expressivity.
- TimSchumann 3y agoI thought Zig was self hosting their compiler now. Am I wrong about that?
- slimsag 3y agoYou're correct, Zig is self-hosted, with its own non-LLVM backends heavily in development; lots of wildly incorrect statements about both Zig and Go in this thread.
- shirro 3y agoI wish Zig had Go-like interfaces. I understand why they don't as they have decided control flow must be explicit but having to include a heap of boilerplate to get the same result isn't a win for readability or maintenance. Given my limitations and tastes I would not want to write or maintain web backend code in Zig but there is a lot to like about Zig as a C replacement and having batteries included for things like HTTP is a win for any language.
- jonahx 3y ago> I wish Zig had Go-like interfaces. I understand why they don't as they have decided control flow must be explicit How do Go-like interfaces make control flow non-explicit?
- philosopher1234 3y agoprobably referring to the dynamic dispatch
- dvt 3y ago> having batteries included for things like HTTP is a win for any language I actually kind of disagree with this. I was a super early Go contributor and helped a tiny bit on the HTTP library (back then it was the core `http` package, now it's under `net/http`). Imo, a lot of HTTP stuff tends to be very "grey area" (what are sensible timeouts? how do you handle different socket errors? should we allow self-signed certificates?) so a lot of opinionated design debate ends up happening, and there's also a lot of scope creep, including having to include things like SSL/proxying if you really want "batteries" to be included which is a lot of non-trivial work (all of a sudden, you also need a elliptic curve cryptography lib, too) that basically has nothing to do with the language itself. I know we live in an "HTTP world" and it's a lot easier to sell a language that can also do stuff on the web, but it would be pretty far down my list.
- candrewlee14 3y agoAgreed about Go-like interfaces. I don’t think it’d fit Zig to make them dynamic at runtime the way Go does, but even just as a compile-time constraint it would make building a composable ecosystem like Go’s much easier. See writer: anytype.
- latch 3y agoI just tried it out and it's very slow. Using `wrk` to hit a basic endpoint that just prints "hello", I got ~500 req/sec. Using a third party zig implementation, I got ~175000 req/sec. It's also both cumbersome to setup and use. Before learning Zig, I used to think Zig needed an http server in the standard library. After using it for a few months, and watching this implementation get added, I think it's a mistake - there just isn't enough bandwidth to support a _quality_ kitchen-sink included stdlib.
- synergy20 3y agomight add this as a performance issue to zig's github ticketing system? before 1.0 there is always room to improve it
- cturtle 3y agoMaybe you compiled in Debug rather than a Release mode? There is also definitely enough time before Zig reaches 1.0 to improve things.
- fbdab103 3y agoI do not think fast needs to be a goal? Great to have sure, but a slow, stable, compliant implementation is perfectly fit for purpose in the standard library.
- KRAKRISMOTT 3y agoIf you are getting 500 reqs per second for a statically typed compiled systems programming language with no garbage collector on a modern machine, you have bigger problems than standards compliance. 1Ghz/500 is ~2Mhz per request. Taking 2 million cycles to respond to a request in a benchmarked environment on localhost means something has gone horribly wrong.
- karmakaze 3y agoOne of the things that made Go good is that the stdlib may not have everything, but what it has was production grade in terms of performance. I don't see value in spreading work out thin just to have something in the stdlib.
- stephc_int13 3y agoI tend to think that standard libraries should be minimal enough to contain mostly code that is reasonably trusted to be near optimal. I don’t think that can be the case here. This should be released as reference implementation, an example, provided for convenience and education, probably not production ready…
- synergy20 3y agoi think it justifies a http server in stdlib in today's world, everything is connected, it should also include a TLS 1.3 implementation(it has some basic TLS based on bearssl), both are essential nowadays.
- _8j50 3y agoNim has been unpleasant trying to get https client working with a staric build because it needs openssl. Does this support native TLS and static linking?