7 ms·

I always like innovations in programming tooling. To me zig sounds like a system language written by system programmers, while rust is more influenced from FP a

I always like innovations in programming tooling. To me zig sounds like a system language written by system programmers, while rust is more influenced from FP and webdev communities, which is reflected in both tooling and language. To people asking why zig when there's rust, both are nice in different ways.

kristoff_it 6y ago
I think Zig will reserve a few interesting surprises also in the webdev world, it just needs a bit more time to get there.
- sam0x17 6y ago
  If anything, Zig will have much fewer restrictions (no borrow checker) than Rust when it comes to web dev, once Zig matures to the point where there is a good standard HTTP client and server implementation and a package manager. I'm a fan of Rust for things like a missile control system or a stock exchange, but not, say, writing a CRM. I'd gladly write a CRM in Zig however, given the proper library support and tooling. Why? productivity. In my experience it just takes 2-3x longer to get the same thing done in Rust vs. something like Zig/Crystal/Go and certainly vs. Ruby/Python/etc. For extremely mission critical code, this is fine, but for most startups I would argue it probably isn't appropriate. Definitely staying tuned as Zig develops.
  - ikskuh 6y ago
    One experience i can share with Zig and webdev is this: I was writing a emulator (and later: a compiler) in Zig which was originally written for PC. But i got the idea that hosting this stuff on the web page would be cool, so i learned how to do Wasm. The result was for both project a glue file with ~150 LOC Zig and ~150 JS and both compiler and emulator ran in the browser, and porting both projects took less than an afternoon of time.
    - sam0x17 6y ago
      Very cool. In my case, I have my eye on Zig as the target language for some web framework ideas I've had for a while, and I'm just waiting for some library maturity at this point before I get started.
  - johnnycerberus 6y ago
    While I like what Rust is trying to achieve, I would never use something that is not formally proven. There are many, many other static analysis tools in the C and Ada world that can achieve exactly the same thing. They imply less risk, they are way more mature (~40 yo) and have bigger communities around them. Zig is a better C and C++. It should be used accordingly. It will do well in game servers, simulation servers and real-time systems that don't require hard safety constraints. Bonus points for Zig, it is a simple language and because of its nature it will be easy to build tooling around it to prove properties.
    - sam0x17 6y ago
      Agreed that Rust has a bit of an odd fit -- it is in many ways a bit too onerous for day-to-day things like CRMs and web dev, but for the real scenarios where you want formal verification, you can of course also use actual formal methods and get a much higher degree of certainty perhaps. It is well suited for OS and driver dev though, which is arguably the target use case.
      - jorangreef 6y ago
        "It is well suited for OS and driver dev though" Rust is brilliant, but for drivers, I would go for a language with OOM safety and strict static allocation, especially for embedded environments.
    - viraptor 6y ago
      > that can achieve exactly the same thing That's a bold claim. What's the C formal validator which automatically handles both memory management and concurrency in source of any size within seconds/minutes? (Without making the source its own dialect rather than C)
      - sam0x17 6y ago
        True, I'm familiar with ones in Java but not in C/C++. Having written a leak / double free detector for C, I have to say, you can only do so much statically and that wouldn't give me peace of mind exactly.
  - skohan 6y ago
    Where does the extra productivity in Zig come from in your experience? I haven't worked with it, but my understanding is that memory management is manual and explicit, which tends to come with some cognitive overhead. If Zig has a good solution for this I would be curious how it achieves it.
    - dnautics 6y ago
      Defer and errdefer help make the memory handling dead easy.
- higerordermap 6y ago
  I don't think zig is very well suited for / should target web dev. There a GC'd language with modern features should do best. Imagine OCaml but modern and great tooling. That would be easy for developers, more productive to write, less type errors, also more productive because of IDE support, and much faster than current crop of scripting languages. Sadly, there is a vacuum for such a language. Go is too gruntwork and minor details, Rust is designed for high reliability system programming, Zig is designed as sytem language in spirit of C, OCaml is archaic and does not seem to improve by much. The hopes in this area are Nim - Nice python-like syntax, but feels a little unpolished, metaprogramming may be hindrance to IDE tooling and code readability on large codebases. Crystal - Ruby like syntax and stdlib. LLVM compilation, very young language, no windows support, and (personal opinion) I think some work can be done on performance of idiomatic code. OCaml - there is not much manpower behind it. All those Reason XYZ attempts to provide javascript syntax over it don't seem to have gotten traction. Tooling is pretty good considering how obscure language is. They might need a modern interface to toolchain, and an optimizing compiler seems to be being worked on. La k of multicore is often cited as a drawback but it is being worked on, and Python doesn't do multicore either, I don't think multicore matters to 90% of people doing webdev. F# - Would be nice if it was not confined to .NET ecosystem and had good native compilation story.
  - kristoff_it 6y ago
    >There a GC'd language with modern features should do best. There's still a market for more performant and predictable networked services. It's a bit too early for a full-fledged post explaining the feature in detail, but as far as I know Zig is the only language that can do async/await and at the same time ensure that when memory limits are reached, the system still behaves correctly (i.e. you can preallocate upfront the memory you need to instantiate a coroutine and, if that fails, you can gracefully return a 500 http error code). Serious webdev is out there, and when SREs talk about the importance of predictability and low-variance in metrics, they aren't (just) writing content for marketing purposes.
    - higerordermap 6y ago
      Yeah but majority of webdev is not that, right?
pjmlp 6y ago
I just dislike the way stuff gets imported const std = @import("std"). Too much require.js look alike.
- someziguser 6y ago
  In Zig the source files you are importing are implicitly structs. Personally I find it better to keep it consistent, declaring it like any other struct with the use of a built-in function. I don't think there's any advantage to turning it to a typical module import statement given the underlying semantics.
  - pjmlp 6y ago
    So Zig won't support binary libraries?
    - ifreund 6y ago
      It already does, dynamic linking is orthogonal to @import() semantics.
oshea64bit 6y ago
Maybe this is an ignorant question, but how exactly is Rust influenced by web dev? I don't see how the aspects that make Rust popular (ownership, lifetimes, strong type system etc.) contribute much to web dev in particular. Languages used for the web like JS, Python, Ruby seem popular precisely because they abstract lower-level details.
- swsieber 6y ago
  There's definitely influence from the package manager side. There's probably also the influence on the push for a strong WASM story.
- mjtlittle 6y ago
  Rust is heavily funded and maintained by Mozilla for use in Firefox's engine, Servo
  - deleted 6y ago
    [deleted]
  - Ar-Curunir 6y ago
    Working on a browser is not “web dev”, at least wrt how “web dev” is defined by many parts of the software community. (Web dev is a totally cool and difficult engineering thing to do, it’s just disjoint from browser dev) Anyway, Rust design is no longer influenced in any significant way by Servo, and most Rust contributors are not Mozillians
  - exikyut 6y ago
    AFAIK no it isn't anymore, it was one of the biggest teams jettisoned by Mozilla manglement in the layoffs a few weeks ago (So, everyone promptly hyperfocused on how to bootstrap the Rust Foundation in a hurry)
aidenn0 6y ago
That's interesting because the people I've seen that are part of the zig foundation all have some sort of web-adjacent background; I know Andrew has mentioned working at OKCupid, and the author of this post worked at Redis. To some degree, this is probably just because that's where the money is (A quick look at Andrew's blog shows lots of non-web stuff for personal projects prior to Zig), but the gravity of a day-job is fairly strong. I'm a systems programmer by day, but my github profile indicates mostly web and common-lisp related things; I definitely look at my tools through that lens. The fact that I can get assembly-level profiling of my common lisp code is one of the things that keeps me on lisp vs. other dynamic languages. For all the above reasons (and of course the obvious ones as well), it's a very positive sign for Zig that Andrew's day-job now is working on Zig. As a systems programmer, I do find it exciting, though I lack the time to spend on it currently (my first foray ran into a compiler bug after having written less than 100 LoC, which may have been coincidental, but certainly discouraged me from spending more time with it).
- runevault 6y ago
  Andrew worked at OKC, but I seem to recall their backend being written in C++so he isn't exactly a "traditional" webdev for the late 2010s/2020s.
  - pjmlp 6y ago
    But it was quite traditional in the 2000's, see ATLServer.
simias 6y ago
Can you explain what you have in mind exactly? I'm very much a system programmer and very much not a webdev and I'm basically in love with Rust, so I'm not really sure why you feel that way. I admit that I don't know much about Zig and it does seem like a very interesting language, but at a glance it seems to me like the type system is significantly weaker than Rust's (which may be a good thing for compile times). For instance I see that they have special syntax for optional types (?) and for error handling (try/catch) when Rust can implement those using basic language constructs (Option<T> and Result<T, E>). Sure Rust also has the "?" sugar to make error bubbling nicer (like try in Zig) but it's just sugar, it doesn't do anything you can't do with normal Rust code (hence the older try! macro). More generally I'm not really sold on their implementation of generics. It's the main reason I never gave Go a chance and Zig's version don't seem a whole lot better as far as I can tell. Rust's generics are complex and incur significant compilation overhead but they're also incredibly powerful.
- alexnask 6y ago
  > Rust's generics are complex and incur significant compilation overhead but they're also incredibly powerful. Zig doesn't have generics in the strictest sense of the word. What it provides is compile time execution and types as first class values at compile time. You can write arbitrary compile time code that generates any type you wish, either with the traditional syntax or by using the @Type builtin (for example if you wish to generate a struct with fields that are defined by parsing some protobuf code, or w/e your heart desires, it is easily achievable).
- higerordermap 6y ago
  a strong type system in itself doesn't cause slowness in compiler. A large part of time is spent in code generator. Rustc produces lot of LLVM IR and it is mentioned there is some technical debt there. For systems languages I don't think dynamic dispatch instead of monomorphization is not the right way to implement generics. And zig doesn't seem to be doing dynamic dispatch either. It shouldn't affect the amount of code produced. The difference between rust and zig generics is difference between simplicity and rigour. And I think having something built in is wrong, if it can be a library. Now library-instead-of-language-feature can lead to longer compile times and less friendly error messages. There are lot of tradeoff in language design. Now that rust culture is formed largely of web / FP developers, it may indeed promote a template heavy, macro heavy programming style, which may lead to significantly longer compiles. For example, a struct based CLI flag parsing library instead of a simpler one, or map-filter chains instead of for loops. These may produce significant amount of generic expansions, and thus harm debug builds speed and compile times when overused. It also makes alternative implementations hard because the optimizer needs to be very good. > Can you explain what you have in mind exactly? Ok this is already long comment. Zig and Go leadership seems to be more focused on details of toolchain. For example this development, and zig cc. Zig also utilizes caching very well and focuses a lot on interop. That's impressive for a project at this scale. The focus on compilation speeds so much to create another backend is another example. Rust is more about PLT and language/ tooling ergonomics. Cargo and popularity of VSCode among rust developers for example. Not saying any of these are bad. Barring some overexcitement from rust community (I personally dislike that overexcitement), these new compiled languages are all very nice to have.
whyever 6y ago
IIRC, Zig was partially born out of Andrew's frustration with Rust.
- moldavi 6y ago
  Really? Would love to hear more!

kristoff_it 6y ago

I think Zig will reserve a few interesting surprises also in the webdev world, it just needs a bit more time to get there.

sam0x17 6y ago
If anything, Zig will have much fewer restrictions (no borrow checker) than Rust when it comes to web dev, once Zig matures to the point where there is a good standard HTTP client and server implementation and a package manager. I'm a fan of Rust for things like a missile control system or a stock exchange, but not, say, writing a CRM. I'd gladly write a CRM in Zig however, given the proper library support and tooling. Why? productivity. In my experience it just takes 2-3x longer to get the same thing done in Rust vs. something like Zig/Crystal/Go and certainly vs. Ruby/Python/etc. For extremely mission critical code, this is fine, but for most startups I would argue it probably isn't appropriate. Definitely staying tuned as Zig develops.
- ikskuh 6y ago
  One experience i can share with Zig and webdev is this: I was writing a emulator (and later: a compiler) in Zig which was originally written for PC. But i got the idea that hosting this stuff on the web page would be cool, so i learned how to do Wasm. The result was for both project a glue file with ~150 LOC Zig and ~150 JS and both compiler and emulator ran in the browser, and porting both projects took less than an afternoon of time.
  - sam0x17 6y ago
    Very cool. In my case, I have my eye on Zig as the target language for some web framework ideas I've had for a while, and I'm just waiting for some library maturity at this point before I get started.
- johnnycerberus 6y ago
  While I like what Rust is trying to achieve, I would never use something that is not formally proven. There are many, many other static analysis tools in the C and Ada world that can achieve exactly the same thing. They imply less risk, they are way more mature (~40 yo) and have bigger communities around them. Zig is a better C and C++. It should be used accordingly. It will do well in game servers, simulation servers and real-time systems that don't require hard safety constraints. Bonus points for Zig, it is a simple language and because of its nature it will be easy to build tooling around it to prove properties.
  - sam0x17 6y ago
    Agreed that Rust has a bit of an odd fit -- it is in many ways a bit too onerous for day-to-day things like CRMs and web dev, but for the real scenarios where you want formal verification, you can of course also use actual formal methods and get a much higher degree of certainty perhaps. It is well suited for OS and driver dev though, which is arguably the target use case.
    - jorangreef 6y ago
      "It is well suited for OS and driver dev though" Rust is brilliant, but for drivers, I would go for a language with OOM safety and strict static allocation, especially for embedded environments.
  - viraptor 6y ago
    > that can achieve exactly the same thing That's a bold claim. What's the C formal validator which automatically handles both memory management and concurrency in source of any size within seconds/minutes? (Without making the source its own dialect rather than C)
    - sam0x17 6y ago
      True, I'm familiar with ones in Java but not in C/C++. Having written a leak / double free detector for C, I have to say, you can only do so much statically and that wouldn't give me peace of mind exactly.
- skohan 6y ago
  Where does the extra productivity in Zig come from in your experience? I haven't worked with it, but my understanding is that memory management is manual and explicit, which tends to come with some cognitive overhead. If Zig has a good solution for this I would be curious how it achieves it.
  - dnautics 6y ago
    Defer and errdefer help make the memory handling dead easy.
higerordermap 6y ago
I don't think zig is very well suited for / should target web dev. There a GC'd language with modern features should do best. Imagine OCaml but modern and great tooling. That would be easy for developers, more productive to write, less type errors, also more productive because of IDE support, and much faster than current crop of scripting languages. Sadly, there is a vacuum for such a language. Go is too gruntwork and minor details, Rust is designed for high reliability system programming, Zig is designed as sytem language in spirit of C, OCaml is archaic and does not seem to improve by much. The hopes in this area are Nim - Nice python-like syntax, but feels a little unpolished, metaprogramming may be hindrance to IDE tooling and code readability on large codebases. Crystal - Ruby like syntax and stdlib. LLVM compilation, very young language, no windows support, and (personal opinion) I think some work can be done on performance of idiomatic code. OCaml - there is not much manpower behind it. All those Reason XYZ attempts to provide javascript syntax over it don't seem to have gotten traction. Tooling is pretty good considering how obscure language is. They might need a modern interface to toolchain, and an optimizing compiler seems to be being worked on. La k of multicore is often cited as a drawback but it is being worked on, and Python doesn't do multicore either, I don't think multicore matters to 90% of people doing webdev. F# - Would be nice if it was not confined to .NET ecosystem and had good native compilation story.
- kristoff_it 6y ago
  >There a GC'd language with modern features should do best. There's still a market for more performant and predictable networked services. It's a bit too early for a full-fledged post explaining the feature in detail, but as far as I know Zig is the only language that can do async/await and at the same time ensure that when memory limits are reached, the system still behaves correctly (i.e. you can preallocate upfront the memory you need to instantiate a coroutine and, if that fails, you can gracefully return a 500 http error code). Serious webdev is out there, and when SREs talk about the importance of predictability and low-variance in metrics, they aren't (just) writing content for marketing purposes.
  - higerordermap 6y ago
    Yeah but majority of webdev is not that, right?

pjmlp 6y ago

I just dislike the way stuff gets imported const std = @import("std"). Too much require.js look alike.

someziguser 6y ago
In Zig the source files you are importing are implicitly structs. Personally I find it better to keep it consistent, declaring it like any other struct with the use of a built-in function. I don't think there's any advantage to turning it to a typical module import statement given the underlying semantics.
- pjmlp 6y ago
  So Zig won't support binary libraries?
  - ifreund 6y ago
    It already does, dynamic linking is orthogonal to @import() semantics.

oshea64bit 6y ago

Maybe this is an ignorant question, but how exactly is Rust influenced by web dev? I don't see how the aspects that make Rust popular (ownership, lifetimes, strong type system etc.) contribute much to web dev in particular. Languages used for the web like JS, Python, Ruby seem popular precisely because they abstract lower-level details.

swsieber 6y ago
There's definitely influence from the package manager side. There's probably also the influence on the push for a strong WASM story.
mjtlittle 6y ago
Rust is heavily funded and maintained by Mozilla for use in Firefox's engine, Servo
- deleted 6y ago
  [deleted]
- Ar-Curunir 6y ago
  Working on a browser is not “web dev”, at least wrt how “web dev” is defined by many parts of the software community. (Web dev is a totally cool and difficult engineering thing to do, it’s just disjoint from browser dev) Anyway, Rust design is no longer influenced in any significant way by Servo, and most Rust contributors are not Mozillians
- exikyut 6y ago
  AFAIK no it isn't anymore, it was one of the biggest teams jettisoned by Mozilla manglement in the layoffs a few weeks ago (So, everyone promptly hyperfocused on how to bootstrap the Rust Foundation in a hurry)

aidenn0 6y ago

That's interesting because the people I've seen that are part of the zig foundation all have some sort of web-adjacent background; I know Andrew has mentioned working at OKCupid, and the author of this post worked at Redis. To some degree, this is probably just because that's where the money is (A quick look at Andrew's blog shows lots of non-web stuff for personal projects prior to Zig), but the gravity of a day-job is fairly strong. I'm a systems programmer by day, but my github profile indicates mostly web and common-lisp related things; I definitely look at my tools through that lens. The fact that I can get assembly-level profiling of my common lisp code is one of the things that keeps me on lisp vs. other dynamic languages. For all the above reasons (and of course the obvious ones as well), it's a very positive sign for Zig that Andrew's day-job now is working on Zig. As a systems programmer, I do find it exciting, though I lack the time to spend on it currently (my first foray ran into a compiler bug after having written less than 100 LoC, which may have been coincidental, but certainly discouraged me from spending more time with it).

runevault 6y ago
Andrew worked at OKC, but I seem to recall their backend being written in C++so he isn't exactly a "traditional" webdev for the late 2010s/2020s.
- pjmlp 6y ago
  But it was quite traditional in the 2000's, see ATLServer.

simias 6y ago

Can you explain what you have in mind exactly? I'm very much a system programmer and very much not a webdev and I'm basically in love with Rust, so I'm not really sure why you feel that way. I admit that I don't know much about Zig and it does seem like a very interesting language, but at a glance it seems to me like the type system is significantly weaker than Rust's (which may be a good thing for compile times). For instance I see that they have special syntax for optional types (?) and for error handling (try/catch) when Rust can implement those using basic language constructs (Option<T> and Result<T, E>). Sure Rust also has the "?" sugar to make error bubbling nicer (like try in Zig) but it's just sugar, it doesn't do anything you can't do with normal Rust code (hence the older try! macro). More generally I'm not really sold on their implementation of generics. It's the main reason I never gave Go a chance and Zig's version don't seem a whole lot better as far as I can tell. Rust's generics are complex and incur significant compilation overhead but they're also incredibly powerful.

alexnask 6y ago
> Rust's generics are complex and incur significant compilation overhead but they're also incredibly powerful. Zig doesn't have generics in the strictest sense of the word. What it provides is compile time execution and types as first class values at compile time. You can write arbitrary compile time code that generates any type you wish, either with the traditional syntax or by using the @Type builtin (for example if you wish to generate a struct with fields that are defined by parsing some protobuf code, or w/e your heart desires, it is easily achievable).
higerordermap 6y ago
a strong type system in itself doesn't cause slowness in compiler. A large part of time is spent in code generator. Rustc produces lot of LLVM IR and it is mentioned there is some technical debt there. For systems languages I don't think dynamic dispatch instead of monomorphization is not the right way to implement generics. And zig doesn't seem to be doing dynamic dispatch either. It shouldn't affect the amount of code produced. The difference between rust and zig generics is difference between simplicity and rigour. And I think having something built in is wrong, if it can be a library. Now library-instead-of-language-feature can lead to longer compile times and less friendly error messages. There are lot of tradeoff in language design. Now that rust culture is formed largely of web / FP developers, it may indeed promote a template heavy, macro heavy programming style, which may lead to significantly longer compiles. For example, a struct based CLI flag parsing library instead of a simpler one, or map-filter chains instead of for loops. These may produce significant amount of generic expansions, and thus harm debug builds speed and compile times when overused. It also makes alternative implementations hard because the optimizer needs to be very good. > Can you explain what you have in mind exactly? Ok this is already long comment. Zig and Go leadership seems to be more focused on details of toolchain. For example this development, and zig cc. Zig also utilizes caching very well and focuses a lot on interop. That's impressive for a project at this scale. The focus on compilation speeds so much to create another backend is another example. Rust is more about PLT and language/ tooling ergonomics. Cargo and popularity of VSCode among rust developers for example. Not saying any of these are bad. Barring some overexcitement from rust community (I personally dislike that overexcitement), these new compiled languages are all very nice to have.

whyever 6y ago

IIRC, Zig was partially born out of Andrew's frustration with Rust.

moldavi 6y ago
Really? Would love to hear more!