Zig now has built-in HTTP server and client in std

https://github.com/ziglang/zig/blob/7cf2cbb33ef34c1d211135f56d30fe23b6cacd42/test/standalone/http.zig

by huydotnet • 3 years ago

267 174 3 years ago

jchw• 3 years ago

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.

pfyra• 3 years ago

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• 3 years ago

Probably for HTTP Pipelining: https://en.wikipedia.org/wiki/HTTP_pipelining

laserbeam4• 3 years ago

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.

brundolf2• 3 years ago

Does a package manager not benefit from high-performance parallel HTTP (for downloading a bunch of little files)?

EscapeFromNY• 3 years ago

If that's the only purpose, why is there an http server too? The package manager should only need an http client.

naikrovek• 3 years ago

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.

tills132• 3 years ago

why does _literally_ every line start with "try"?

dundarious• 3 years ago

Same meaning as the Rust “?” operator.

tialaramex• 3 years ago

Rust'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• 3 years ago

A middle ground between exceptions in c++ and checking every function call for an error code in c.

defen• 3 years ago

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• 3 years ago

~$ 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*?

paulddraper2• 3 years ago

* every substantive line

regulation_d• 3 years ago

I mean if the OED allows for a metaphorical or hyperbolical meaning, I think you're fighting a literal uphill battle.

tills132• 3 years ago

No, I clearly meant "literally"

Don't be a pedant.

laserbeam4• 3 years ago

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• 3 years ago

Not just in theory, they can, and do, fail in practice.

formerly_proven• 3 years ago

A lot less verbose than “if err != nil { /* 2-3 lines */ }” after every substantive line.

C-x_C-f• 3 years ago

More like `catch |err| return err` so not that big of a saving but yeah it's more convenient

jrockway3• 3 years ago

What are you doing with lines 1 and 2? Most people just `return fmt.Errorf("stuff the caller can't know: %w", err)` and call it a day. To me, this beats exceptions because a human can provide context; what iteration of the loop were we on, what specific sub-operation failed, etc.

Spending a lot of time typing in error handling code seems OK to me. You are never going to get paged when your software is working. So you'll probably spend more of your time dealing with rare error conditions. Thus, the code spends a lot of lines capturing the circumstances around the error conditions, so you can go change a line of code and redeploy instead of spending 6 months debugging.

AndyKelley3• 3 years ago

welcome to networking, where every operation can fail

cturtle2• 3 years ago

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.

xedrac6• 3 years ago

Rust used to use the word try in a similar context, but was considered too noisy, and opted for ? instead, which I think worked out very well in practice.

lenkite3• 3 years ago

In Go, every line would start with "if". In Rust every line would end with "?".

I find the anti-exception attitude of newer languages questionable.

nusaru• 3 years ago

Relevant autodocs:

Server: https://ziglang.org/documentation/master/std/#A;std:http.Ser...

Client: https://ziglang.org/documentation/master/std/#A;std:http.Cli...

bricss• 3 years ago

It can even parse JSON out-of-the-box! \m/

eatonphil• 3 years ago

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!

VWWHFSfQ• 3 years ago

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?

snacktaster• 3 years ago

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• 3 years ago

You can use both. There's no need to make binary choices or create division. Only fools mimic such behavior.

arp242• 3 years 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• 3 years ago

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).

slondr• 3 years ago

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.

brigadier1322• 3 years ago

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.

FpUser• 3 years ago

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++.

pjmlp10• 3 years ago

Zig is Modula-2 with C like syntax, plenty of @, no support for binary libraries.

What it has over Modula-2 feature checklist is mostly comptime.

IshKebab• 3 years ago

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.

skybrian• 3 years ago

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.

AndyKelley3• 3 years ago

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• 3 years ago

Well, I was maybe considering ignoring it... until its creator told me to.

You can't tell me what to do!

crubier• 3 years ago

Nice flex, I like the attitude!

synergy204• 3 years ago

zig is as small as c, perfect for my brain to actually be able to remember without checking some 100s page reference book like other languages have, learning it now. my only 'wish' for zig is to replace its {} with indentations kind of like nim/python for readability.

_hypx6• 3 years ago

You can always learn both. They do not really compete against other as one is aiming to replace C++ and the other C.

xedrac6• 3 years ago

I hear this repeated quite often in Zig crowds, but Rust is absolutely, 100% aiming to displace C. There's no way it would have made it into the Linux kernel otherwise. It just so happens that it can also replace most of C++, which is why it's also found in the Windows kernel.

secondcoming• 3 years ago

Modern software engineering summed up in two sentences...

Use which ever one you enjoy using.

endorphine2• 3 years ago

I don't know why you're downvoted (perhaps because it's a blanket statement), but there's definitely some truth to that.

With so many great choices, after a point it comes down to personal preference.

pjmlp10• 3 years ago

For many of us it is "use whatever is allowed/required on the job".

kristoff_it• 3 years ago

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/

ChubbyGlasses• 3 years ago

idk about a "war" or we, but features aside, zig feels like a less obnoxious language, and i mean that as politely as possible. to make an analogy, rust is like a friend that constantly nags about _everything_; like you know they mean well, but girl chill i know. about to cross a street, rust reminds you to look both ways. empty street with no cars around and it's safe to cross, rust wont let you cross until the crosswalk sign lights up. cooking something, rust will pester you about proper knife safety. like yes i know, being a nuisance about things i already know about doesn't help me write better software; i already know to look both ways before crossing. every once in a while it catches something you wouldn't have otherwise, but you have to deal with that constant pestering _all_ the time. also, just my personal opinion, but rust has some of the worst language ergonomics i've seen in any modern mainstream language and i don't think it can reasonably be fixed due to its 1.0 promise

Georgelemental• 3 years ago

Rust is annoying when you are doing something you know is sound, "yes I looked both ways and re-checked twice, chill out OK", but the compiler yells at you anyway. Zig is great in such situations. Rust really shines when you are doing something you are not confident at all in—juggling 17 knives, in a large codebase with many contributors that you are new to, and you haven't had any coffee—and you can relax because you know the compiler will catch your soundness mistakes.

Good blog post to this effect: https://matklad.github.io/2023/03/26/zig-and-rust.html

Cloudef2• 3 years ago

I find rust easy to use when you are doing high level programming, but it becomes very annoying language when you are trying to do something low level, or trying to manage memory yourself.

NathanielBaking• 3 years ago

I don't want to get grabbed on a side street and beaten but... Rust is language designed to solve a process problem (bad buggy code) with a straitjacket language approach. It is pedantic to the point of being unreadable and in it's own problem domain (system, embedded and up) has been ticking the wrong boxes. Zig is substantially better yet I think a better language is still around the corner. Having said that, you absolutely can't go wrong mastering C. Zig wraps C in a way that doesn't choke you on configuration issues. Zig's out-of-the-box support for many target's is a savvy decision too.

However, both Zig and Rust make some of the same errors so I will put my plea here for future language developers. How you work with Threads, Async, Interrupts are all implementation details. Please don't make them part of the language. A good Function type is sufficient to make elegant solutions that do not require language support.

impulser_4• 3 years ago

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.

jtanza• 3 years ago

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• 3 years ago

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

themerone2• 3 years ago

Python, Java, and all of the .NET language have standardized database APIs.

xyproto• 3 years ago

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_4• 3 years ago

Yeah, but Go provides this for almost everything in the STD. io, networking, http, sql, and so on.

andrewchambers2• 3 years ago

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_4• 3 years ago

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.

fractalb• 3 years ago

Exactly. It's like a feature on a paper, but I don't think anyone would ever dare to make a database driver switch in production.

kitd• 3 years ago

Agreed. Wrapping all db access in its own class or module is one of the easiest architectural decisions to be made in a project. Allows you to use specific drivers but isolates changes to a few easily found locations. Makes it dead simple to test too.

anonymoushn2• 3 years ago

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_4• 3 years ago

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.

lmm7• 3 years ago

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.

The effect is that every database driver becomes outdated and doesn't support certain features, instead of just a few. Python people have a saying that the standard library is where modules go to die. Java's database drivers massively lag behind (e.g. there's still no good async support for most of them), because JDBC is a lowest common denominator that every driver has to be dumbed down to, but is established enough that it sucks all the oxygen away from any efforts to write better drivers.

Far better to keep the standard library small and allow modules to update on their own terms and their own schedule. If the library you're using does what you need, you can stick with it, but a better alternative (which always means a new interface in practice - the idea that you can make substantial improvement without changing the interface is mostly a myth, because the interface is the most important part of a library) can appear and compete on its merits, and if the improvements are worth migrating to then it will win out.

alfiedotwtf• 3 years ago

Exactly. Perl had BerkleyDB as part of Core, as well as CGI. How's that going for the Perl footprint!

born-jre• 3 years ago

one approcach with golang is make interface that can be leaked if you really want, you will be using standard interface 99% but if you need sth not provided by abstraction you can ask for underlying impl `db.Driver()` and cast to appropriate type.

lenkite3• 3 years ago

Java's database drivers massively lag behind (e.g. there's still no good async support for most of them),

Very Hard Disagree. JDBC is pretty amazing actually. Thats why you find so many Database tools and wizards written in Java as opposed to Rust.

Regarding async - With Java 19 virtual threads , you have newer versions of JDBC drivers support async with none to minimal changes. Example: https://medium.com/oracledevs/introduction-to-oracle-jdbc-21...

I am very, very glad that human civilisation standardised on one system for gears instead of every manufacturer making their own special snowflake.

badrequest• 3 years ago

Go doesn't provide standard library implementations of database drivers, only standard library interfaces for driver implementations to adhere to.

JodieBenitez3• 3 years ago

Python people have a saying that the standard library is where modules go to die.

That's just a quote from a 10 years old talk by Kenneth Reitz, and it's quite an overstatement.

jiehong• 3 years ago

Java has something called R2DBC as well, the async jdbc driver equivalent. Most major db have such a driver nowadays.

pjmlp10• 3 years ago

All those complains always forget that the standard library happens to be available everywhere the language has a full implementation available, while third party libraries are hit and miss.

I rather have outdated code that works, than not having anything at all.

paulddraper2• 3 years ago

In Go switching database drivers in as simple as importing the new library.

Neat!

Kinda like Java. (JDBC)

Kinda like C#. (IDb)

Kinda like Python. (DB-API)

Kinda like PHP. (PDO)

Kinda like Perl. (DBI)

Kinda like C/C++. (ODBC)

Of course, you work as the lowest common denominator and have abstractions that don't quite match the implementation. And let's be honest, how often do you switch databases.

But yeah this is very common.

---

I'd argue in practice, Java follows your advice the most of any community:

* JDBC

* Servlets

* SLF4J (not technically stdlib but very common)

fzeindl• 3 years ago

I wish more programming languages provided interfaces for building libraries around the std library like what Go does.

Java does, but apart from JDBC for databases, and the servlet-API, I haven't seen many cases where that really improved the world of programming. Java-EE relied heavily on such abstractions, but nowadays those would be replaced by simpler, less abstract constructs with less redirections.

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 don't have to change your code.

Database drivers are an abstraction that tends to leak it's underlying technology very fast.

The idea of just being to swap your database out under the hood is neat, but generally holds only for simple projects.

Also the abstraction that helps you here is SQL really, not the driver.

pjmlp10• 3 years ago

Java EE isn't gone away, it is the foundation of all modern Java frameworks, via Jakarta EE renaming and Microprofile.

Spring, Quarkus, Helidon, Liberty, Wildfly, TomEE, Payara all support it.

It turns out such standards are quite valuable for the industry at scale, instead of playing tetris with third party library stuff of various quality.

dragonwriter2• 3 years ago

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.

So, standard interfaces, or dynamic or structural typing? Lots of languages have those (some all three.)

WhereIsTheTruth• 3 years ago

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

slimsag3• 3 years ago

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.

norir2• 3 years ago

The 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.

alchemio2• 3 years ago

Zig is plenty fast for a compiled language with optimizations. The Go compiler has no debug/release profiles and the generated machine code isn’t as optimized as say a language using llvm. If you compare it to C++ or Rust, Zig actually has better compile times, and it keeps improving.

pjmlp10• 3 years ago

Only C++ without incremental compilation, incremental linking and modules.

VC++ does import std in a fraction of time it takes to #include <iostream>.

AndyKelley3• 3 years ago

Many people are not aware that - currently - Zig completely rebuilds your entire application with every compilation - including any parts of the standard library you use. There is not yet any incremental compilation.

It takes a lot of time investment to make compilation fast, and we have gone all in on this investment. There was almost an entire year when not much happened besides the compiler rewrite (which is now done). Finally, we are starting to see some fruits of our labor. Some upcoming milestones that will affect compilation speed:

* x86 backend (90% complete) - eliminates the biggest compilation speed bottleneck, which is LLVM.

* our own self-hosted ELF linker - instead of relying on LLD, we tightly couple our linker directly with the compiler in order to speed up compilation.

* incremental compilation (in place binary patching) - after this Zig will only compile functions affected by changes since the last build.

* Interned types & values. Speed up Semantic Analysis which is the remaining bottleneck of the compiler

* Introduce a separate thread for linking / machine code generation, instead of ping-ponging between Semantic Analysis & linking/mcg

* Multi-threaded semantic analysis. Attack the last remaining bottleneck of the compiler with brute force

Anyway, I won't argue with cold hard performance facts if you have some to share, but I won't stand accused of failing to prioritize compilation speed.

ragnarsson• 3 years ago

Thanks Andrew, for me a big frustration with Rust is the compilation times coming from Go.

Based on your Milan presentation as well, I have a lot of hope that Zig is seriously pushing on this.

shirro• 3 years ago

I 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• 3 years 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• 3 years ago

probably referring to the dynamic dispatch

dvt• 3 years 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• 3 years ago

Agreed 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.

Tozen• 3 years ago

There have been many arguments that Zig's Try/Catch is hidden control flow. Though many would argue that trying to stick to "catch phrases", can result in painting one's self into a corner, versus what's best to accomplish a task.

Lots of people love interfaces (or similar like "traits"). Helps them get what they need done and there are lots of examples of their usage in different languages. Accomplishing the task, is what's most important.

latch• 3 years ago

I 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.

synergy204• 3 years ago

might add this as a performance issue to zig's github ticketing system? before 1.0 there is always room to improve it

cturtle2• 3 years ago

Maybe you compiled in Debug rather than a Release mode? There is also definitely enough time before Zig reaches 1.0 to improve things.

fbdab103• 3 years ago

I 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• 3 years ago

If 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• 3 years ago

One 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• 3 years ago

I 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…

synergy204• 3 years ago

i 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.

badrabbit• 3 years ago

Nim 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?

Zig now has built-in HTTP server and client in std

Related Stories