35 ms·

Zig and Rust

238 points by avinassh 4y ago

olodus 4y ago
Probably just a small miss, but in the first section the author refers to stack space limitations possibly hit when calling malloc. That should probably refer to heap space. Or if it is stack space they meant then maybe not malloc but rather stack allocations / function calls.
- olodus 4y ago
  Besides that little inaccuracy I very much agree with most things in the article and think it brings up good points. Specifically the part about allocator handling is a huge thing for me. Having the allocator be a global thing has always been a bit of a cheat imo and it solves so many memory issues just to remove that part. And opens up some optimization possibilities ad well. I do agree with some of zigs Cons that you bring up as well. Currently I have really been into Linear types and feel like that would be the perfect "simple" type-based memory safety zig could incorporate without making it too c++ complicated. But at the same time I don't know if it would work with its comptime and maybe it too would compromise on the simpleness of the language. I don't know.
- jamincan 4y ago
  I think he's referring to the fact that as a function, calls to malloc result in a new stack frame.
- messe 4y ago
  I think they’re actually referring the stack usage from the function call itself (the creation of a new stack frame). I believe the point the author is making is that while it’s common to check the return value of malloc to see if heap allocation was successful, it’s comparatively rare to do any analysis of stack usage to verify that none of your function calls are going to cause a stack overflow.
  - monocasa 4y ago
    Rust at least will stack probe to trigger any guard pages upon allocation.
camdenreslink 4y ago
The rust-analyzer guy now writes Zig full time?
- eatonphil 4y ago
  > I now find myself writing Zig full-time Seemed pretty clear to me. :)
- O_H_E 4y ago
  Yeah that made me wow too! He's gonna have a wild career.
- Ygg2 4y ago
  Yes, he found a job writing Zig.
fnordpiglet 4y ago
This sort of convinced me to stay away from Zig
- avinassh 4y ago
  can you elaborate why
  - lucasyvas 4y ago
    Not the parent, but Zig being much easier to use unsafely is not a good thing IMO. Rust tries to pave a path for all types of developers to eventually learn how to write performant code safely in a way that integrates cleanly. This is a much more practical need for the programming community at this time. I have to agree with the parent - I was interested in looking at Zig eventually, but after reading this I am not. They seem to have much more different philosophies than I expected, and Zig's does not resonate. The author's summary really sums it up nicely. I don't need a language that prides itself on being a bit more dangerous in exchange for some extra control.
    - nindalf 4y ago
      Agree with everything you've said. > I don't need a language This, but the bigger issue is that I don't think I can be trusted with such a sharp tool. I'm just aware of my own limitations, and I think I'd better stick to safe languages.
      - xedrac 4y ago
        I don't want to need to be trusted. And I don't want to have to trust others so much. I want my tools to tell me I, or someone on my team, did something stupid.
        fnordpiglet 4y ago
        Even better, to not be allowed to do something stupid.
MrBuddyCasino 4y ago
> Collections are not parametrized by an allocator, like in C++ or (future) Rust. What does he mean by this?
- Georgelemental 4y ago
  My understanding is, instead of the allocator being a generic parameter of the type, it's a value you pass to the constructor.
  - tialaramex 4y ago
    The crucial trick is that it's not just the constructor, it's everywhere which might allocate. Rust's proposed allocator API (what the article calls future Rust) takes an allocator for constructors, but the effect is the type parameter is just inferred during construction, the same way if you say OK, make me a Vec of this array of Strings, Rust infers the Vec's type Vec<String>. Zig's standard library provides both conventional compound structures like those I described for Rust, and "Unmanaged" variants in which you must provide an allocator every time you do anything which might allocate, so e.g. addOne on ArrayListUnmanaged requires the allocator, which it will only actually use if adding a single element to the ArrayList exceeded its current capacity. It will assume this is the correct allocator to de-allocate the old backing storage and allocate new storage, so you can't use this design to move from one allocator to another. Interestingly Zig's ensureTotalCapacity not only avoids the problem of C++ reserve where it destroys the amortized growth behaviour, but it actually insists on exponential growth even if that considerably outstrips the growth requested. Say we've got 15 Foozles in an ArrayList with capacity 16 (or Rust's Vec or C++ std::vector). We know we want to put 20 more foozles in, for a total of 35, although maybe more. Rust's Vec says OK, reserve(20), we were thinking of next growing from 16 to 32, but 35 won't fit in 32, so 35 it is. Capacity becomes 35. Popular C++ std::vector implementations likewise will pick 35 here. But Zig's ArrayList says 16 + 8 + 8 = 32 not big enough, try 32 + 16 + 8 = 56. Capacity becomes 56!
- steveklabnik 4y ago
  Psuedo-Rust code here, showing off both styles. Parameterized by an allocator: struct Foo<T, A: Allocator> { // ... } impl<T, A> Foo<T, A> { fn new() -> Foo<T, A> { // do something to make a new foo, calling functions via A } } contrast with "an allocator is passed in explicitly to every method which actually needs to allocate." struct Foo<T> { // ... } impl<T> Foo<T> { fn new<A: Allocator>(a: A) -> Foo<T> { // do something to make a new foo, calling functions via A } } (EDIT: "new" was a bad choice for me to pick here, see the child comment that uses 'put' instead; I was not trying to suggest that the allocator only parameterizes a constructor, but any call that would need to allocate.)
scythe 4y ago
>Erlang style, where we embrace failability of both hardware and software and explicitly design programs to be resilient to partial faults. >SQLite style, where we overcome an unreliable environment at the cost of rigorous engineering. I don't think that the way this contrast is illustrated is nearly as helpful as the author intended it to be. Based on my prior knowledge of Erlang and SQLite, I can reconstruct the idea that the difference is that Erlang tries to build a "reliability layer" below the software, while SQLite builds lots of checks and self-correction into the software. But if I didn't already know that, the quoted lines would leave me hopelessly confused.
- deleted 4y ago
  [deleted]
- mats852 4y ago
  And also the billions of tests they run against every builds! https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html I enjoyed the CoRecursive podcast with Richard Hipp, it's fascinating. https://corecursive.com/066-sqlite-with-richard-hipp/#billions-of-tests https://corecursive.com/066-sqlite-with-richard-hipp/#billio...
nindalf 4y ago
This title is almost perfectly designed to do well on HN, but it's definitely worth reading in it's entirety. Some highlights for me: - The author sees Rust and Zig in different niches. When Rust was created it didn't need to specialise because there were no languages like Rust. It was free to be a general purpose language targeting multiple domains. But that's not the case for Zig. He sees Zig shining at writing systems software that requires low level control - where unsafe code is a necessity and fine grained control over allocation is a blessing. - The author was the original author of rust-analyzer, the LSP for Rust. I remember reading his original proposal for why Rust should ditch their existing LSP effort (called Rust Language Server) and start afresh with a completely new. And he was 100% right. He knows what he's talking about when it comes to IDE experiences for languages. I hope the Zig developers listen to what he's suggesting here. - "Rust is a language for building modular software ... the core of what Rust is doing: it provides you with a language to precisely express the contracts between components, such that components can be integrated in a machine-checkable way." That is a good description of Rust. Rust allows you to confidently assemble a program that works well, even if you have to collaborate with hundreds of other programmers to create it. - "Zig is about perfection. It is a very sharp, dangerous, but, ultimately, more flexible tool." Makes sense, but this tells me that I probably lack the skill to write correct Zig. - Comment by the author on reddit (https://www.reddit.com/r/rust/comments/123jpry/comment/jdv9xyg/?context=1 https://www.reddit.com/r/rust/comments/123jpry/comment/jdv9x...) about advantages that Zig has is illuminating. Again, none of these appeal to me, but these are great to have in the right use case. - In a different comment on reddit (https://reddit.com/r/Zig/comments/123jpia/blog_post_zig_and_rust/jdvb087/?context=1 https://reddit.com/r/Zig/comments/123jpia/blog_post_zig_and_...) he said "Until release-safe guarantees the absence of UB, I wouldn't be ready to recommend Zig as a general-purpose language." Which is fair, but it's still early days for Zig, years to go before 1.0. It's entirely possible that this behaviour could come to be. I think the author's article makes a compelling case that Rust and Zig can both co-exist and succeed.
- formerly_proven 4y ago
  Zig feels like a good match for replacing C on microcontrollers because it permits “hold my beer” shenanigans and memory management is less of an issue. Zig metaprogramming also seems like a better match for these environments - think about how much nicer you could do stuff like qmk -, the Rust embedded stuff seems quite painful in comparison. Haven’t tried this yet, it’s on my perennial todo list and when I touch this stuff I usually want to get something done. I also imagine you’ll have to do everything yourself with Zig here, while Rust does have a lot of HAL crates.
infogulch 4y ago
> That’s the core of what Rust is doing: it provides you with a language to precisely express the contracts between components, such that components can be integrated in a machine-checkable way. That's a nice description of rust.
crop_rotation 4y ago
I tried zig after reading so many HN articles and I am not impressed. You have to remember to free after each allocation. The language is supposed to be simple, yet there exist try, catch, defer, errdefer. Rust enums make defining errors so simple with arbitrary payload. Using data structures in rust is much nicer. I think unless you have some precise needs about memory allocation, and want to control exactly where when and how memory is allocated, it is hard to argue in favour of Zig. The allocation control is very nice if you need it though.
- renox 4y ago
  > I tried zig after reading so many HN articles and I am not impressed. You have to remember to free after each allocation. You write like it was a something surprising, but you know Zig is often described as a replacement for C..
- MrBuddyCasino 4y ago
  > I think unless you have some precise needs about memory allocation, and want to control exactly where when and how memory is allocated, it is hard to argue in favour of Zig. I do have a hard time to think of use cases other than embedded microcontroller work where that matters nowadays. That said, I suspect that while they could have written TigerBeetle in Rust (no_std does not assume the existence of an allocator), it would have been more difficult.
  - AnIdiotOnTheNet 4y ago
    > I do have a hard time to think of use cases other than embedded microcontroller work where that matters nowadays. People keep saying things like this and software keeps getting more bloated and shittier. It is difficult to believe there isn't a correlation.
    - mr_00ff00 4y ago
      I might be misreading this comment, but the answer to bloated software is not writing all of it in rust/C++/zig. The reasons for bloat is not garage collection.
netbioserror 4y ago
Still not convinced that memory semantics are critical in the vast majority of domains. Incredibly fast speeds can be achieved with simple GC and RC for short-running programs, and programs with sustained runtimes can rely on generational GC. These methods have the advantage of nearly eliminating the need for memory semantics, leaving only business logic behind. The best example might be Nim, which drastically reduces GC pressure over Java or Go by stack allocating and passing immutably by value wherever it can. No gigantic runtime to link against! I've been able to make fast, safe programs so quickly with Nim that it promptly ended my Rust fascination phase. Kernels, realtime software on rockets, and Facebook- or Discord-scale backends seem like good fits for Rust, but I'm not convinced it should be used almost anywhere else. Looking at the sheer volume of memory logic in Zig and Rust, I have to ask: "Why do we continue doing this to ourselves?"
- jackmott42 4y ago
  You can get the idea that a GC has minimal impact on performance when you just look at things like how fast the GC runs, or what % of time is spent in GC, but that only represents a portion of performance implications, there are lots of indirect effects: 1. More memory is used, which means more CPU cache evictions happen 2. There will be things the language won't let you do, because it is garbage collected 3. There will be extra FFI costs, like when making OS calls or calling into other languages 4. There will be cultural tendencies, if a language uses GC, the people who designed it and used it are less likely to be interested in compromising other things for extreme performance. Example: If a linq query has overhead in C#, and they have to make a breaking change to eliminate it, they will not. In Rust if an iterator is slower than what hand coded C would be, its a bug, and every effort will be made to fix it if possible. That said, it is still the case that most programs aren't penalized by GC much. But people do still work on operating systems, games, databases, video editing tools and such where getting great performance is really important.
  - deleted 4y ago
    [deleted]
  - TylerE 4y ago
nevi-me 4y ago
I think writing a language full-time is a given or necessity if you've been hired to work on software that uses it. Unless you've had prior experience and can continue tinkering with other things. It's cool that matklad's moved to such an interesting project. I saw TigerBeetle a few months back, and thought that it's interesting to build a double-entry DB. As an accountant who's built double-entry systems into 'normal' SQL DBs, I find this an interesting enough concept that I'm now intrigued to try it out. Perhaps the year is still young enough for me to finally learn Zig while I go through their repo. It might also help me with the awkward knowledge gap that still exists between Rust FFI (in that I seldom know what I'm doing) and C.
WhereIsTheTruth 4y ago
The only advantage Zig has is its ability to consume C/C++ as it ships with clang That's about it, the language is too verbose and sometimes not enough verbose with all these .{} you need to always look at the documentation to remember what this does, this is time consuming and does useless context switches Last time i tried to build their language server to use in my editor, and i was surprised it took an eternity to compile, similar to rust here, i was hoping it would do better I love the build.zig feature, you stick to 1 language, there is no json/yaml/toml/xml BS, it's very refreshing to see Cons: - erognomics - slow to compile - verbose but sometimes not (.{}) Pros: - builtin C/C++ compiler - build.zig - files are structs - lazy compilation model (you can write platform specific code very easily without bloating your project)
- stephc_int13 4y ago
  I tend to agree with most of your remarks. Zig would clearly be a better choice than Rust to replace C. Zig is also better than C in some ways, but worse in others, this is frustrating. The trick is that most of the good parts are either transient QoL improvements (such as the build system) or guard rails to avoid costly mistakes (no macros, explicit memory management) but the drawbacks (annoying syntax, peculiarities, probably trying to do too much) seems to be long-lasting daily annoyances. I am waiting for 1.0 and also for Jai.
henry_viii 4y ago
I think we should take into consideration AI assistants like ChatGPT when discussing Zig vs. Rust. Differences between Zig and Rust: 1) Zig is memory-unsafe and thread-unsafe whereas Rust isn't. 2) Zig is easier to learn whereas Rust isn't. 3) Zig isn't stable yet whereas Rust is. ChatGPT can help with Rust: https://news.ycombinator.com/item?id=33872369 https://news.ycombinator.com/item?id=33872369 However ChatGPT can't help with Zig since Zig hasn't stabilized yet. Features like for-loops (introduced in 2022) aren't familiar to ChatGPT since ChatGPT's cut-off date is 2021.
meindnoch 4y ago
Happy to see the tide turning from Rust towards Zig. I think 2023 is going to be a pivotal year in this space!
- Klonoar 4y ago
  Not entirely sure how you got that impression from the article.
anonyfox 4y ago
May someone chime in between that and make a quick 3-way comparison with Golang? I already know Rust and shipped nontrivial stuff, but I need something simpler that average developers can pickup quickly to produce performant+parallel code and be able to crosscompile+ship a single binary. (The last point already ruled out Crystal which has a poor crosscompilation story as well as insanely long compile times for nontrivial stuff = bad DX)
- pizza234 4y ago
  The main topic of the article is about resource management (ie. allocation), which is automatic in Golang, so a comparison wouldn't make much sense in this context. Additionally, a requirement of the project is: > On the engineering side of things, we are building a reliable, predictable system. And predictable means really predictable. Rather than reigning in sources of non-determinism, we build the whole system from the ground up from a set of fully deterministic, hand crafted components. which rules out garbage collected languages (also see the design document here: https://github.com/tigerbeetledb/tigerbeetle/blob/fe09404d465df46b2bdfc017633eff37b4ab2343/docs/DESIGN.md https://github.com/tigerbeetledb/tigerbeetle/blob/fe09404d46...).
- eatonphil 4y ago
  It takes a while to understand allocations in Go. There are obvious ones like `make()` and `new()` and `append()` (though this one doesn't always allocate depending on the capacity of the thing you pass to append, I think). There are less obvious ones (if you don't have experience thinking about it) like string appending and "casting" between `string` and `[]byte`. I think it's also tricky to figure out when escape analysis goes wrong and you're accidentally heap allocating things you didn't need to. You develop an awareness of these aspects if you do performance-sensitive code in Go. But in Zig all allocations are explicit so you can't really accidentally have allocations. On the other hand, you have to manually manage memory in Zig. Unlike Rust, Zig has no builtin atomic reference counting. So memory management in Rust and Go are "easier" if you don't want to be aware of memory allocations. Memory management in Zig is "easier" if you need to be aware of memory allocations. And neither Zig nor Go are as strict as Rust about ownership so it's "easier" to express internally-mutable datastructures in Zig or Go (see "Entirely Way Too Many Linked Lists" [0]). Whereas it's easier to be sure you haven't screwed up ownership in Rust compared to Zig. In Go you don't have to worry since the GC will not let ownership be a problem. [0] https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/
haberman 4y ago
> First, I think Zig’s strength lies strictly in the realm of writing “perfect” systems software. It is a relatively thin slice of the market, but it is important. This resonates with me. This is exactly why I use C today, and why Zig appeals to me.
- mustache_kimono 4y ago
  This definition of "perfect" might be counterintuitive for those that haven't read the piece. The idea is there might some ideal memory allocation scenario that Rust doesn't do "perfectly" that you can theoretically do better in Zig, which I buy. Most particularly, my experience with arenas and defer drop is -- they aren't always perfectly easy in Rust. But this definition of perfection tends to ignore all the manual, boilerplate memory management you have to do in the interim, that you may still mess up in some subtle way.
  - haberman 4y ago
    > Most particularly, my experience with arenas and defer drop is -- they aren't always perfectly easy in Rust. That is my experience also: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html https://blog.reverberate.org/2021/12/19/arenas-and-rust.html I was hoping the borrow checker would perfectly check arena lifetimes. And it does, but it requires that your types have lifetime parameters. That makes logical sense, but my experience attempting to actually use a type with a lifetime parameter is that it is so painful as to not be practical in a low-level library.
    - mustache_kimono 4y ago
      "Why is Rust’s 'Bump' not' Sync'?" was exactly the issue I was thinking of. Thanks for writing this. Seriously, a must read!
MrBuddyCasino 4y ago
This is easily lost in the noise, but Matklad wrote a good comparison between Rust and Zig which is worth linking to, highlighting Zig's strengths: https://www.reddit.com/r/rust/comments/123jpry/comment/jdv9xyg/ https://www.reddit.com/r/rust/comments/123jpry/comment/jdv9x...
childintime 4y ago
Zig appeals to the “lone genius hackers”. I'd read this as the folks that like to know all the code in their code base, as is typical for embedded or moderate size projects. Folks that do not need (and resent) the abstractions made for every use case under the sun, which to them only ends up making the code harder to read and to comprehend. Though Rust does an admirable job, and things are much better than for OOP languages, it's still a behemoth. Take a (any) small project, and the amount of dependencies upon dependencies explodes. A project easily takes up 1GB on disk, and it is impossible to know exactly what has been pulled in, or why. How much of this code actually ends up in the binary? It feels like a small fraction, like 5% (or even 1%), but that 95% is there and causes breakage. Now you have to debug something that's literally out of your world. It's not Rust, its the build. No matter how small the actual issue is, you are not qualified to find it. Note that Zig's build system provides the exact opposite experience. Errors are always relevant, and can (therefore) always be solved. In summary Rust takes away the helicopter view. Yes, in return it provides an unparalleled level of assurances, it really is magic. But I find myself returning to the roots, and Zig feels tasty. I bet Chatgpt will then handily convert the project, when done, to Rust, faster than I ever could.
- nindalf 4y ago
  You don’t need to pull in dependencies if you don’t want to. But if you do, the contracts on ownership enforced by the compiler allows the software to compose better.
  - childintime 4y ago
    You're a Rust zealot? The point still stands: for lots of projects 95% of the code pulled in is not actually used, but is still cause for breakage. Of the worst kind, because it has nothing to do with the problem being solved. Sorry, but the build system just gave up, for no good reason at all. Only total perfection is acceptable to Rust, and that is also it's Achilles heel, well exemplified by this case. Now Rust could change and be more flexible, and I would have great faith in its leadership to find a way, if not for people like you, who charge ahead on a straw man and ex-communicate.
Ciantic 4y ago
For those reading only the beginning, one could think that Matt is endorsing Zig over Rust. It's not that, from the article: > It’s not true that rewriting a Rust program in Zig would make it simpler. On the contrary, I expect the result to be significantly more complex (and segfaulty). I noticed that a lot of Zig code written in “let’s replace RAII with defer” style has resource-management bugs. I also have read Matt's "Hard Mode Rust", and I think there needs to be a better way. Why can't we have flexible language that can span both styles of allocating resources? I also wonder what TigerBeetle would look like if it were written in Rust using the "Hard Mode".
- fanf2 4y ago
  “Matt” is not his name https://matklad.github.io/about.html https://matklad.github.io/about.html
gavinhoward 4y ago
In addition to the semantics, part of which I tried to understand and failed [1], Zig also has a problem with compiler bugs. In that same post, my very first example ran into a compiler bug. This is not reassuring. (Though to be fair, I've run into more compiler bugs than most do: one in GCC, one in Clang. Maybe I'm just unlucky.) That, combined with the fact that the bug was still not fixed last I checked, Zig's security bug policy is to consider them non-security bugs until 1.0, and it is still not 1.0 makes me wonder why anyone would choose it for a major project to run in production. That was TigerBeetle's first and biggest mistake. [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-colors/ https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
gabereiser 4y ago
I'm learning zig myself after several years of doing rust and golang (I still use golang a lot). I particularly like the quote >"Because even if you and I both know how to write memory safe C, it’s very hard for us to have an interface boundary where we can agree about who does what." This is still a huge issue in many domains, in many languages. Do you throw the contract out the window on responsibility because you lean on your GC? Or do you make it explicit on who owns what when you don't have a GC. If I allocate a struct as part of my ABI to give to you, the application developer, am I clear on who's responsible for freeing the struct? Do I provide a function for that or do I call it out as gospel for using the library? I wish we didn't have to have these fights.
csnover 4y ago
> Zig forces you to pass the allocator in, so you might as well think about the most appropriate one! I really feel like this is an underappreciated aspect of some of the more complained-about constraints that these newer languages place on programmers. Like an i32, the default allocator will do a reasonable thing most of the time, but having to think about each allocation (is this short-lived or long-lived? is it actually necessary to do a heap allocation at all here? do you actually want GC?) makes code better and pushes the programmer to improve their ability to rationalise about what they’re actually doing in ways that provide tangible benefits. By way of comparison, when I started writing Rust I was very frustrated by all the explicit conversions, but eventually realised that it (a) forces me to actually stop and think about what the most natural type is for a given value, and (b) also makes it clearer where the natural boundaries are between components. In my experience, if there’s a lot of conversion going on within a function or module, it’s usually not because the language is ‘too verbose’. Instead, it’s because the API boundaries are in the wrong places, and the language has helped to reveal this by making doing the wrong thing harder.
- kaba0 4y ago
  Ad absurdum that would make assembly a better choice — we can just as well reason about better register allocation strategies. I think the fundamental abstraction level is very important to get right. Of course it depends on the problem domain, and it might just make sense for Zig to expose explicitly allocators everywhere, but maybe some implicitly passed allocator when not otherwise specified could be a better trade off (correct me if it is a thing)
pron 4y ago
> we don’t have a reliability-oriented high-level programming language with a good quality of implementation (modern ML, if you will) Java is fairly popular, I hear.
- c-cube 4y ago
  Calling Java a modern ML is a bit of a stretch :-). It's getting sum types, I hear, but it still has null, and it's not really the feeling of a nice expression oriented Hindley-Milner language. If anything scala 3 might be a closer candidate.
  - kaba0 4y ago
    It already has sum types. Pattern matching on them is not yet finalized, but the ADTs itself is.
    - weatherlight 4y ago
      let us know when Java's type system is sound, and can be completely inferred.
0xfedbee 4y ago
TLDR: Zig bad (like C), Rust good. Not surprised to see an article like this from a core Rust member after two positive articles for Zig on HN frontpage. Gotta keep that strong hold on HN!
- Ygg2 4y ago
  It seems you didn't really read the article. Nor do you have any ideas who core Rust members are.
EVa5I7bHFq9mnYK 4y ago
>> When we call malloc, we just hope that we have enough stack space for it, we almost never check. Does Rust or Zig's malloc allocate on stack? Those millennials.
- kristoff_it 4y ago
  It's a function, when you call it, it allocates a frame on the stack.
  - einarr 4y ago
    True. But the author mentions malloc, it just sounds like he's using "stack" instead of "heap" by mistake.
    - einarr 4y ago
      I see, it was a deliberate choice: https://old.reddit.com/r/Zig/comments/123jpia/blog_post_zig_and_rust/jdvj1bx/ https://old.reddit.com/r/Zig/comments/123jpia/blog_post_zig_...
  - EVa5I7bHFq9mnYK 4y ago
    In our times malloc always allocated on heap, not on stack. But things are different now, I guess.
lr1970 4y ago
From the linked article > When we call malloc, we just hope that we have enough stack space for it, we almost never check. malloc allocates on heap, not stack.
- steveklabnik 4y ago
  This comment from the author elaborates on what he meant here: https://old.reddit.com/r/Zig/comments/123jpia/blog_post_zig_and_rust/jdvj1bx/ https://old.reddit.com/r/Zig/comments/123jpia/blog_post_zig_...
avgcorrection 4y ago
tl;dr: author finally gradudated to becoming a lone genius hacker.
legerdemain 4y ago
Not a particularly deep comment, but... matklad (the author) created, essentially, the entirety of the modern Rust developer experience. He is the original author and biggest contributor to both rust-analyzer and Intellij Rust. If someone this central to the Rust world has switched to writing Zig full time, and not for boring, pragmatic reasons either, a little seed of doubt about the long-term stability of Rust as a professional community begins to grow in my heart.
- molodec 4y ago
  Grayson Hoare who created Rust has been working on Swift language in the last few years at Apple. People change jobs, there is nothing wrong with that. Rust is a community driven project, and the community will keep building. IntelliJ Rust plugin has not stopped evolving since matklad left. matklad may found a new interesting project that happened to be using zig. He didn't say he left Rust community
- brundolf 4y ago
  The post is about how the languages serve different purposes, and he just happens to be working on a project now that he believes benefits more from Zig. Nowhere does he make broad-strokes statements about Rust's (or Zig's) fate

238 points by avinassh 4y ago

Probably just a small miss, but in the first section the author refers to stack space limitations possibly hit when calling malloc. That should probably refer to heap space. Or if it is stack space they meant then maybe not malloc but rather stack allocations / function calls.

olodus 4y ago
Besides that little inaccuracy I very much agree with most things in the article and think it brings up good points. Specifically the part about allocator handling is a huge thing for me. Having the allocator be a global thing has always been a bit of a cheat imo and it solves so many memory issues just to remove that part. And opens up some optimization possibilities ad well. I do agree with some of zigs Cons that you bring up as well. Currently I have really been into Linear types and feel like that would be the perfect "simple" type-based memory safety zig could incorporate without making it too c++ complicated. But at the same time I don't know if it would work with its comptime and maybe it too would compromise on the simpleness of the language. I don't know.
jamincan 4y ago
I think he's referring to the fact that as a function, calls to malloc result in a new stack frame.
messe 4y ago
I think they’re actually referring the stack usage from the function call itself (the creation of a new stack frame). I believe the point the author is making is that while it’s common to check the return value of malloc to see if heap allocation was successful, it’s comparatively rare to do any analysis of stack usage to verify that none of your function calls are going to cause a stack overflow.
- monocasa 4y ago
  Rust at least will stack probe to trigger any guard pages upon allocation.

camdenreslink 4y ago

The rust-analyzer guy now writes Zig full time?

eatonphil 4y ago
> I now find myself writing Zig full-time Seemed pretty clear to me. :)
O_H_E 4y ago
Yeah that made me wow too! He's gonna have a wild career.
Ygg2 4y ago
Yes, he found a job writing Zig.

fnordpiglet 4y ago

This sort of convinced me to stay away from Zig

avinassh 4y ago
can you elaborate why
- lucasyvas 4y ago
  Not the parent, but Zig being much easier to use unsafely is not a good thing IMO. Rust tries to pave a path for all types of developers to eventually learn how to write performant code safely in a way that integrates cleanly. This is a much more practical need for the programming community at this time. I have to agree with the parent - I was interested in looking at Zig eventually, but after reading this I am not. They seem to have much more different philosophies than I expected, and Zig's does not resonate. The author's summary really sums it up nicely. I don't need a language that prides itself on being a bit more dangerous in exchange for some extra control.
  - nindalf 4y ago
    Agree with everything you've said. > I don't need a language This, but the bigger issue is that I don't think I can be trusted with such a sharp tool. I'm just aware of my own limitations, and I think I'd better stick to safe languages.
    - xedrac 4y ago
      I don't want to need to be trusted. And I don't want to have to trust others so much. I want my tools to tell me I, or someone on my team, did something stupid.
      - fnordpiglet 4y ago
        Even better, to not be allowed to do something stupid.

MrBuddyCasino 4y ago

> Collections are not parametrized by an allocator, like in C++ or (future) Rust. What does he mean by this?

Georgelemental 4y ago
My understanding is, instead of the allocator being a generic parameter of the type, it's a value you pass to the constructor.
- tialaramex 4y ago
  The crucial trick is that it's not just the constructor, it's everywhere which might allocate. Rust's proposed allocator API (what the article calls future Rust) takes an allocator for constructors, but the effect is the type parameter is just inferred during construction, the same way if you say OK, make me a Vec of this array of Strings, Rust infers the Vec's type Vec<String>. Zig's standard library provides both conventional compound structures like those I described for Rust, and "Unmanaged" variants in which you must provide an allocator every time you do anything which might allocate, so e.g. addOne on ArrayListUnmanaged requires the allocator, which it will only actually use if adding a single element to the ArrayList exceeded its current capacity. It will assume this is the correct allocator to de-allocate the old backing storage and allocate new storage, so you can't use this design to move from one allocator to another. Interestingly Zig's ensureTotalCapacity not only avoids the problem of C++ reserve where it destroys the amortized growth behaviour, but it actually insists on exponential growth even if that considerably outstrips the growth requested. Say we've got 15 Foozles in an ArrayList with capacity 16 (or Rust's Vec or C++ std::vector). We know we want to put 20 more foozles in, for a total of 35, although maybe more. Rust's Vec says OK, reserve(20), we were thinking of next growing from 16 to 32, but 35 won't fit in 32, so 35 it is. Capacity becomes 35. Popular C++ std::vector implementations likewise will pick 35 here. But Zig's ArrayList says 16 + 8 + 8 = 32 not big enough, try 32 + 16 + 8 = 56. Capacity becomes 56!
steveklabnik 4y ago
Psuedo-Rust code here, showing off both styles. Parameterized by an allocator: struct Foo<T, A: Allocator> { // ... } impl<T, A> Foo<T, A> { fn new() -> Foo<T, A> { // do something to make a new foo, calling functions via A } } contrast with "an allocator is passed in explicitly to every method which actually needs to allocate." struct Foo<T> { // ... } impl<T> Foo<T> { fn new<A: Allocator>(a: A) -> Foo<T> { // do something to make a new foo, calling functions via A } } (EDIT: "new" was a bad choice for me to pick here, see the child comment that uses 'put' instead; I was not trying to suggest that the allocator only parameterizes a constructor, but any call that would need to allocate.)

scythe 4y ago

>Erlang style, where we embrace failability of both hardware and software and explicitly design programs to be resilient to partial faults. >SQLite style, where we overcome an unreliable environment at the cost of rigorous engineering. I don't think that the way this contrast is illustrated is nearly as helpful as the author intended it to be. Based on my prior knowledge of Erlang and SQLite, I can reconstruct the idea that the difference is that Erlang tries to build a "reliability layer" below the software, while SQLite builds lots of checks and self-correction into the software. But if I didn't already know that, the quoted lines would leave me hopelessly confused.

deleted 4y ago
[deleted]
mats852 4y ago
And also the billions of tests they run against every builds! https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html I enjoyed the CoRecursive podcast with Richard Hipp, it's fascinating. https://corecursive.com/066-sqlite-with-richard-hipp/#billions-of-tests https://corecursive.com/066-sqlite-with-richard-hipp/#billio...

nindalf 4y ago

This title is almost perfectly designed to do well on HN, but it's definitely worth reading in it's entirety. Some highlights for me: - The author sees Rust and Zig in different niches. When Rust was created it didn't need to specialise because there were no languages like Rust. It was free to be a general purpose language targeting multiple domains. But that's not the case for Zig. He sees Zig shining at writing systems software that requires low level control - where unsafe code is a necessity and fine grained control over allocation is a blessing. - The author was the original author of rust-analyzer, the LSP for Rust. I remember reading his original proposal for why Rust should ditch their existing LSP effort (called Rust Language Server) and start afresh with a completely new. And he was 100% right. He knows what he's talking about when it comes to IDE experiences for languages. I hope the Zig developers listen to what he's suggesting here. - "Rust is a language for building modular software ... the core of what Rust is doing: it provides you with a language to precisely express the contracts between components, such that components can be integrated in a machine-checkable way." That is a good description of Rust. Rust allows you to confidently assemble a program that works well, even if you have to collaborate with hundreds of other programmers to create it. - "Zig is about perfection. It is a very sharp, dangerous, but, ultimately, more flexible tool." Makes sense, but this tells me that I probably lack the skill to write correct Zig. - Comment by the author on reddit (https://www.reddit.com/r/rust/comments/123jpry/comment/jdv9xyg/?context=1 https://www.reddit.com/r/rust/comments/123jpry/comment/jdv9x...) about advantages that Zig has is illuminating. Again, none of these appeal to me, but these are great to have in the right use case. - In a different comment on reddit (https://reddit.com/r/Zig/comments/123jpia/blog_post_zig_and_rust/jdvb087/?context=1 https://reddit.com/r/Zig/comments/123jpia/blog_post_zig_and_...) he said "Until release-safe guarantees the absence of UB, I wouldn't be ready to recommend Zig as a general-purpose language." Which is fair, but it's still early days for Zig, years to go before 1.0. It's entirely possible that this behaviour could come to be. I think the author's article makes a compelling case that Rust and Zig can both co-exist and succeed.

formerly_proven 4y ago
Zig feels like a good match for replacing C on microcontrollers because it permits “hold my beer” shenanigans and memory management is less of an issue. Zig metaprogramming also seems like a better match for these environments - think about how much nicer you could do stuff like qmk -, the Rust embedded stuff seems quite painful in comparison. Haven’t tried this yet, it’s on my perennial todo list and when I touch this stuff I usually want to get something done. I also imagine you’ll have to do everything yourself with Zig here, while Rust does have a lot of HAL crates.

infogulch 4y ago

> That’s the core of what Rust is doing: it provides you with a language to precisely express the contracts between components, such that components can be integrated in a machine-checkable way. That's a nice description of rust.

crop_rotation 4y ago

I tried zig after reading so many HN articles and I am not impressed. You have to remember to free after each allocation. The language is supposed to be simple, yet there exist try, catch, defer, errdefer. Rust enums make defining errors so simple with arbitrary payload. Using data structures in rust is much nicer. I think unless you have some precise needs about memory allocation, and want to control exactly where when and how memory is allocated, it is hard to argue in favour of Zig. The allocation control is very nice if you need it though.

renox 4y ago
> I tried zig after reading so many HN articles and I am not impressed. You have to remember to free after each allocation. You write like it was a something surprising, but you know Zig is often described as a replacement for C..
MrBuddyCasino 4y ago
> I think unless you have some precise needs about memory allocation, and want to control exactly where when and how memory is allocated, it is hard to argue in favour of Zig. I do have a hard time to think of use cases other than embedded microcontroller work where that matters nowadays. That said, I suspect that while they could have written TigerBeetle in Rust (no_std does not assume the existence of an allocator), it would have been more difficult.
- AnIdiotOnTheNet 4y ago
  > I do have a hard time to think of use cases other than embedded microcontroller work where that matters nowadays. People keep saying things like this and software keeps getting more bloated and shittier. It is difficult to believe there isn't a correlation.
  - mr_00ff00 4y ago
    I might be misreading this comment, but the answer to bloated software is not writing all of it in rust/C++/zig. The reasons for bloat is not garage collection.

netbioserror 4y ago

Still not convinced that memory semantics are critical in the vast majority of domains. Incredibly fast speeds can be achieved with simple GC and RC for short-running programs, and programs with sustained runtimes can rely on generational GC. These methods have the advantage of nearly eliminating the need for memory semantics, leaving only business logic behind. The best example might be Nim, which drastically reduces GC pressure over Java or Go by stack allocating and passing immutably by value wherever it can. No gigantic runtime to link against! I've been able to make fast, safe programs so quickly with Nim that it promptly ended my Rust fascination phase. Kernels, realtime software on rockets, and Facebook- or Discord-scale backends seem like good fits for Rust, but I'm not convinced it should be used almost anywhere else. Looking at the sheer volume of memory logic in Zig and Rust, I have to ask: "Why do we continue doing this to ourselves?"

jackmott42 4y ago
You can get the idea that a GC has minimal impact on performance when you just look at things like how fast the GC runs, or what % of time is spent in GC, but that only represents a portion of performance implications, there are lots of indirect effects: 1. More memory is used, which means more CPU cache evictions happen 2. There will be things the language won't let you do, because it is garbage collected 3. There will be extra FFI costs, like when making OS calls or calling into other languages 4. There will be cultural tendencies, if a language uses GC, the people who designed it and used it are less likely to be interested in compromising other things for extreme performance. Example: If a linq query has overhead in C#, and they have to make a breaking change to eliminate it, they will not. In Rust if an iterator is slower than what hand coded C would be, its a bug, and every effort will be made to fix it if possible. That said, it is still the case that most programs aren't penalized by GC much. But people do still work on operating systems, games, databases, video editing tools and such where getting great performance is really important.
- deleted 4y ago
  [deleted]
- TylerE 4y ago

nevi-me 4y ago

I think writing a language full-time is a given or necessity if you've been hired to work on software that uses it. Unless you've had prior experience and can continue tinkering with other things. It's cool that matklad's moved to such an interesting project. I saw TigerBeetle a few months back, and thought that it's interesting to build a double-entry DB. As an accountant who's built double-entry systems into 'normal' SQL DBs, I find this an interesting enough concept that I'm now intrigued to try it out. Perhaps the year is still young enough for me to finally learn Zig while I go through their repo. It might also help me with the awkward knowledge gap that still exists between Rust FFI (in that I seldom know what I'm doing) and C.

WhereIsTheTruth 4y ago

The only advantage Zig has is its ability to consume C/C++ as it ships with clang That's about it, the language is too verbose and sometimes not enough verbose with all these .{} you need to always look at the documentation to remember what this does, this is time consuming and does useless context switches Last time i tried to build their language server to use in my editor, and i was surprised it took an eternity to compile, similar to rust here, i was hoping it would do better I love the build.zig feature, you stick to 1 language, there is no json/yaml/toml/xml BS, it's very refreshing to see Cons: - erognomics - slow to compile - verbose but sometimes not (.{}) Pros: - builtin C/C++ compiler - build.zig - files are structs - lazy compilation model (you can write platform specific code very easily without bloating your project)

stephc_int13 4y ago
I tend to agree with most of your remarks. Zig would clearly be a better choice than Rust to replace C. Zig is also better than C in some ways, but worse in others, this is frustrating. The trick is that most of the good parts are either transient QoL improvements (such as the build system) or guard rails to avoid costly mistakes (no macros, explicit memory management) but the drawbacks (annoying syntax, peculiarities, probably trying to do too much) seems to be long-lasting daily annoyances. I am waiting for 1.0 and also for Jai.

henry_viii 4y ago

I think we should take into consideration AI assistants like ChatGPT when discussing Zig vs. Rust. Differences between Zig and Rust: 1) Zig is memory-unsafe and thread-unsafe whereas Rust isn't. 2) Zig is easier to learn whereas Rust isn't. 3) Zig isn't stable yet whereas Rust is. ChatGPT can help with Rust: https://news.ycombinator.com/item?id=33872369 https://news.ycombinator.com/item?id=33872369 However ChatGPT can't help with Zig since Zig hasn't stabilized yet. Features like for-loops (introduced in 2022) aren't familiar to ChatGPT since ChatGPT's cut-off date is 2021.

meindnoch 4y ago

Happy to see the tide turning from Rust towards Zig. I think 2023 is going to be a pivotal year in this space!

Klonoar 4y ago
Not entirely sure how you got that impression from the article.

anonyfox 4y ago

May someone chime in between that and make a quick 3-way comparison with Golang? I already know Rust and shipped nontrivial stuff, but I need something simpler that average developers can pickup quickly to produce performant+parallel code and be able to crosscompile+ship a single binary. (The last point already ruled out Crystal which has a poor crosscompilation story as well as insanely long compile times for nontrivial stuff = bad DX)

pizza234 4y ago
The main topic of the article is about resource management (ie. allocation), which is automatic in Golang, so a comparison wouldn't make much sense in this context. Additionally, a requirement of the project is: > On the engineering side of things, we are building a reliable, predictable system. And predictable means really predictable. Rather than reigning in sources of non-determinism, we build the whole system from the ground up from a set of fully deterministic, hand crafted components. which rules out garbage collected languages (also see the design document here: https://github.com/tigerbeetledb/tigerbeetle/blob/fe09404d465df46b2bdfc017633eff37b4ab2343/docs/DESIGN.md https://github.com/tigerbeetledb/tigerbeetle/blob/fe09404d46...).
eatonphil 4y ago
It takes a while to understand allocations in Go. There are obvious ones like `make()` and `new()` and `append()` (though this one doesn't always allocate depending on the capacity of the thing you pass to append, I think). There are less obvious ones (if you don't have experience thinking about it) like string appending and "casting" between `string` and `[]byte`. I think it's also tricky to figure out when escape analysis goes wrong and you're accidentally heap allocating things you didn't need to. You develop an awareness of these aspects if you do performance-sensitive code in Go. But in Zig all allocations are explicit so you can't really accidentally have allocations. On the other hand, you have to manually manage memory in Zig. Unlike Rust, Zig has no builtin atomic reference counting. So memory management in Rust and Go are "easier" if you don't want to be aware of memory allocations. Memory management in Zig is "easier" if you need to be aware of memory allocations. And neither Zig nor Go are as strict as Rust about ownership so it's "easier" to express internally-mutable datastructures in Zig or Go (see "Entirely Way Too Many Linked Lists" [0]). Whereas it's easier to be sure you haven't screwed up ownership in Rust compared to Zig. In Go you don't have to worry since the GC will not let ownership be a problem. [0] https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/

haberman 4y ago

> First, I think Zig’s strength lies strictly in the realm of writing “perfect” systems software. It is a relatively thin slice of the market, but it is important. This resonates with me. This is exactly why I use C today, and why Zig appeals to me.

mustache_kimono 4y ago
This definition of "perfect" might be counterintuitive for those that haven't read the piece. The idea is there might some ideal memory allocation scenario that Rust doesn't do "perfectly" that you can theoretically do better in Zig, which I buy. Most particularly, my experience with arenas and defer drop is -- they aren't always perfectly easy in Rust. But this definition of perfection tends to ignore all the manual, boilerplate memory management you have to do in the interim, that you may still mess up in some subtle way.
- haberman 4y ago
  > Most particularly, my experience with arenas and defer drop is -- they aren't always perfectly easy in Rust. That is my experience also: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html https://blog.reverberate.org/2021/12/19/arenas-and-rust.html I was hoping the borrow checker would perfectly check arena lifetimes. And it does, but it requires that your types have lifetime parameters. That makes logical sense, but my experience attempting to actually use a type with a lifetime parameter is that it is so painful as to not be practical in a low-level library.
  - mustache_kimono 4y ago
    "Why is Rust’s 'Bump' not' Sync'?" was exactly the issue I was thinking of. Thanks for writing this. Seriously, a must read!

MrBuddyCasino 4y ago

This is easily lost in the noise, but Matklad wrote a good comparison between Rust and Zig which is worth linking to, highlighting Zig's strengths: https://www.reddit.com/r/rust/comments/123jpry/comment/jdv9xyg/ https://www.reddit.com/r/rust/comments/123jpry/comment/jdv9x...

childintime 4y ago

Zig appeals to the “lone genius hackers”. I'd read this as the folks that like to know all the code in their code base, as is typical for embedded or moderate size projects. Folks that do not need (and resent) the abstractions made for every use case under the sun, which to them only ends up making the code harder to read and to comprehend. Though Rust does an admirable job, and things are much better than for OOP languages, it's still a behemoth. Take a (any) small project, and the amount of dependencies upon dependencies explodes. A project easily takes up 1GB on disk, and it is impossible to know exactly what has been pulled in, or why. How much of this code actually ends up in the binary? It feels like a small fraction, like 5% (or even 1%), but that 95% is there and causes breakage. Now you have to debug something that's literally out of your world. It's not Rust, its the build. No matter how small the actual issue is, you are not qualified to find it. Note that Zig's build system provides the exact opposite experience. Errors are always relevant, and can (therefore) always be solved. In summary Rust takes away the helicopter view. Yes, in return it provides an unparalleled level of assurances, it really is magic. But I find myself returning to the roots, and Zig feels tasty. I bet Chatgpt will then handily convert the project, when done, to Rust, faster than I ever could.

nindalf 4y ago
You don’t need to pull in dependencies if you don’t want to. But if you do, the contracts on ownership enforced by the compiler allows the software to compose better.
- childintime 4y ago
  You're a Rust zealot? The point still stands: for lots of projects 95% of the code pulled in is not actually used, but is still cause for breakage. Of the worst kind, because it has nothing to do with the problem being solved. Sorry, but the build system just gave up, for no good reason at all. Only total perfection is acceptable to Rust, and that is also it's Achilles heel, well exemplified by this case. Now Rust could change and be more flexible, and I would have great faith in its leadership to find a way, if not for people like you, who charge ahead on a straw man and ex-communicate.

Ciantic 4y ago

For those reading only the beginning, one could think that Matt is endorsing Zig over Rust. It's not that, from the article: > It’s not true that rewriting a Rust program in Zig would make it simpler. On the contrary, I expect the result to be significantly more complex (and segfaulty). I noticed that a lot of Zig code written in “let’s replace RAII with defer” style has resource-management bugs. I also have read Matt's "Hard Mode Rust", and I think there needs to be a better way. Why can't we have flexible language that can span both styles of allocating resources? I also wonder what TigerBeetle would look like if it were written in Rust using the "Hard Mode".

fanf2 4y ago
“Matt” is not his name https://matklad.github.io/about.html https://matklad.github.io/about.html

gavinhoward 4y ago

In addition to the semantics, part of which I tried to understand and failed [1], Zig also has a problem with compiler bugs. In that same post, my very first example ran into a compiler bug. This is not reassuring. (Though to be fair, I've run into more compiler bugs than most do: one in GCC, one in Clang. Maybe I'm just unlucky.) That, combined with the fact that the bug was still not fixed last I checked, Zig's security bug policy is to consider them non-security bugs until 1.0, and it is still not 1.0 makes me wonder why anyone would choose it for a major project to run in production. That was TigerBeetle's first and biggest mistake. [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-colors/ https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...

gabereiser 4y ago

I'm learning zig myself after several years of doing rust and golang (I still use golang a lot). I particularly like the quote >"Because even if you and I both know how to write memory safe C, it’s very hard for us to have an interface boundary where we can agree about who does what." This is still a huge issue in many domains, in many languages. Do you throw the contract out the window on responsibility because you lean on your GC? Or do you make it explicit on who owns what when you don't have a GC. If I allocate a struct as part of my ABI to give to you, the application developer, am I clear on who's responsible for freeing the struct? Do I provide a function for that or do I call it out as gospel for using the library? I wish we didn't have to have these fights.

csnover 4y ago

> Zig forces you to pass the allocator in, so you might as well think about the most appropriate one! I really feel like this is an underappreciated aspect of some of the more complained-about constraints that these newer languages place on programmers. Like an i32, the default allocator will do a reasonable thing most of the time, but having to think about each allocation (is this short-lived or long-lived? is it actually necessary to do a heap allocation at all here? do you actually want GC?) makes code better and pushes the programmer to improve their ability to rationalise about what they’re actually doing in ways that provide tangible benefits. By way of comparison, when I started writing Rust I was very frustrated by all the explicit conversions, but eventually realised that it (a) forces me to actually stop and think about what the most natural type is for a given value, and (b) also makes it clearer where the natural boundaries are between components. In my experience, if there’s a lot of conversion going on within a function or module, it’s usually not because the language is ‘too verbose’. Instead, it’s because the API boundaries are in the wrong places, and the language has helped to reveal this by making doing the wrong thing harder.

kaba0 4y ago
Ad absurdum that would make assembly a better choice — we can just as well reason about better register allocation strategies. I think the fundamental abstraction level is very important to get right. Of course it depends on the problem domain, and it might just make sense for Zig to expose explicitly allocators everywhere, but maybe some implicitly passed allocator when not otherwise specified could be a better trade off (correct me if it is a thing)

pron 4y ago

> we don’t have a reliability-oriented high-level programming language with a good quality of implementation (modern ML, if you will) Java is fairly popular, I hear.

c-cube 4y ago
Calling Java a modern ML is a bit of a stretch :-). It's getting sum types, I hear, but it still has null, and it's not really the feeling of a nice expression oriented Hindley-Milner language. If anything scala 3 might be a closer candidate.
- kaba0 4y ago
  It already has sum types. Pattern matching on them is not yet finalized, but the ADTs itself is.
  - weatherlight 4y ago
    let us know when Java's type system is sound, and can be completely inferred.

0xfedbee 4y ago

TLDR: Zig bad (like C), Rust good. Not surprised to see an article like this from a core Rust member after two positive articles for Zig on HN frontpage. Gotta keep that strong hold on HN!

Ygg2 4y ago
It seems you didn't really read the article. Nor do you have any ideas who core Rust members are.

EVa5I7bHFq9mnYK 4y ago

>> When we call malloc, we just hope that we have enough stack space for it, we almost never check. Does Rust or Zig's malloc allocate on stack? Those millennials.

kristoff_it 4y ago
It's a function, when you call it, it allocates a frame on the stack.
- einarr 4y ago
  True. But the author mentions malloc, it just sounds like he's using "stack" instead of "heap" by mistake.
  - einarr 4y ago
    I see, it was a deliberate choice: https://old.reddit.com/r/Zig/comments/123jpia/blog_post_zig_and_rust/jdvj1bx/ https://old.reddit.com/r/Zig/comments/123jpia/blog_post_zig_...
- EVa5I7bHFq9mnYK 4y ago
  In our times malloc always allocated on heap, not on stack. But things are different now, I guess.

lr1970 4y ago

From the linked article > When we call malloc, we just hope that we have enough stack space for it, we almost never check. malloc allocates on heap, not stack.

steveklabnik 4y ago
This comment from the author elaborates on what he meant here: https://old.reddit.com/r/Zig/comments/123jpia/blog_post_zig_and_rust/jdvj1bx/ https://old.reddit.com/r/Zig/comments/123jpia/blog_post_zig_...

avgcorrection 4y ago

tl;dr: author finally gradudated to becoming a lone genius hacker.

legerdemain 4y ago

Not a particularly deep comment, but... matklad (the author) created, essentially, the entirety of the modern Rust developer experience. He is the original author and biggest contributor to both rust-analyzer and Intellij Rust. If someone this central to the Rust world has switched to writing Zig full time, and not for boring, pragmatic reasons either, a little seed of doubt about the long-term stability of Rust as a professional community begins to grow in my heart.

molodec 4y ago
Grayson Hoare who created Rust has been working on Swift language in the last few years at Apple. People change jobs, there is nothing wrong with that. Rust is a community driven project, and the community will keep building. IntelliJ Rust plugin has not stopped evolving since matklad left. matklad may found a new interesting project that happened to be using zig. He didn't say he left Rust community
brundolf 4y ago
The post is about how the languages serve different purposes, and he just happens to be working on a project now that he believes benefits more from Zig. Nowhere does he make broad-strokes statements about Rust's (or Zig's) fate