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.
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.
> 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).
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.
> I think having something built in is wrong, if it can be a library
I'm split on this one. This sort of "axiomatic" philosophy of programming is fairly common, and it's not hard to see why; it just feels right, intuitively, for everything to be built out of a tiny set of simple constructs. It's really empowering to know that, if you understand those constructs, you can (in principle) understand any program. Lisp and Urbit are extreme examples of this.
But to everything, there is a price, and here the price is paid in performance, tooling, and readability. Reified builtins can offend our sensibilities, but they are easier to optimize, permit deeper tooling, and require less cognitive overhead.
Ultimately, I think it's a man/machine distinction. It's like...lined paper. Printers don't need paper to be lined in order to "write" in straight lines. A human, if they're being really careful, doesn't either -- but it sure helps. Lined paper is designed by meatbags, for meatbags. The question to ask is, who's doing the writing? I don't know offhand, but I'd guess that lined paper is far less common now than it was 50 years ago. Maybe in 50 years, it will be similarly uncommon to see programming languages designed around arbitrary human sensibilities. But even after that, I think most humans will continue to prefer arbitrary languages.
Not a rust programmer - but this seems odd. Map/filter/reduce are high level abstractions that describe most common operations you want to perform on sequence. It's non-trivial to infer from loop code (you need to scan at least multiple lines to confirm it's actually "just a map" or "just a filter", especially when you have more complex operation chains etc. and the mutable imperative nature of the code makes it even harder to reason about - more potential edge cases).
This is exactly the kind of stuff I don't want to do manually and expect the compiler to do at (near) zero cost - how can you "overuse" this ?
Rust was developed for a core systems programming task: writing a browser. Yes, there is lots of influence from PL research, but I fail to see how the community is FP oriented.
Re your points about toolchain: Rust is also developing a non-LLVM backend, and is one of the better compilers for incremental compilation
>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.
Probably that Zig is a systems programming language from/for people who understand and appreciate C - not C++/FP/etc...
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).
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.
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.
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.
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.
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.
Rust's borrow checking algorithm has been formally proven for a subset of the full language. Although this is one of those places where intuition is adequate to show the value, i.e. of enforcing exclusive mutability. After all, the intuition and implementation came before the proof (as is often the case).
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)
I don't think we can call it "automatic handling", you just play by the borrow checker's rules. Automatic are the garbage collectors but not Rust's model.
One company that I've worked for used generators, they were specifying the model with a DSL and they generated the code based on that. Can't give more information about that but there are others doing the same (SpaceX and NASA). Rust is very good for people that don't have the resources and money to throw at or are working in an industry where they don't need a certification, for example I have friends at Amazon in Romania that build Firecracker, a virtual machine that is supposed to improve the safety story on AWS Lambda.
And as an answer for your second question, at what cost? Also we don't know if Rust gets the scaling right. The compiler is already slow for the size of projects we already have.
There's a bit of disjoint between what those tools do and they what Rust does. Rust provides something different - you write the source in standard code and get a sound app. Verifiers can't do that with C. You essentially either write a parallel list of annotations or generate the app from another language. It's a valid approach, but that's why I objected to "exactly the same thing".
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.
There is work to get Rust qualified for safety critical domains [1]. Someone else pointed out that parts of the borrow checker have been formally proven already. Still a long road ahead, but I'm glad people are looking at it.
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.
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.
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.
> There a GC'd language with modern features should do best.
I predict that there will be a paradigm shift away from GC in the next round of languages. I suspect what will win for something like web-dev will be a language with static memory management like Rust, but at a higher level, with slightly more tolerance for abstractions of non-zero cost.
I predict that GC languages will prevail and adopt affine types for advanced users to code application hot paths, like D, Swift, Chapel among others are pursuing.
I think this is in general the right call, but I would prefer seeing the adoption of a more general substructural type system implementation and the inclusion of uniqueness types. It would not add that much complexity when the use case is specifically limited to advanced users and the obvious trade offs in syntax increase and annotations are limited to those that want/need it.
>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.
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.
