Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig and Rust

matklad.github.io

Post reply on HN
Print view View original

11–20 of 247 posts

Re: Zig and Rust

#11

Post by messe »

olodus wrote: post #2

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.

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.

Re: Zig and Rust

#12

Post by scythe »

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

Re: Zig and Rust

#13

Post by nindalf »

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

Re: Zig and Rust

#14

Post by steveklabnik »

MrBuddyCasino wrote: post #8

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

Psuedo-Rust code here, showing off both styles.

Parameterized by an allocator:

  struct Foo {
      // ...
  }

  impl Foo {
      fn new() -> Foo {
          // 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 {
      // ...
  }

  impl Foo {
      fn new(a: A) -> Foo {
          // 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.)

Re: Zig and Rust

#15

Post by lucasyvas »

avinassh wrote: post #7
fnordpiglet wrote: post #6

This sort of convinced me to stay away from Zig

can you elaborate why

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.

Re: Zig and Rust

#16

Post by infogulch »

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

Re: Zig and Rust

#17

Post by estebank »

avinassh wrote: post #7
fnordpiglet wrote: post #6

This sort of convinced me to stay away from Zig

can you elaborate why

> - Rust is about compositional safety, its a more scalable language than Scala.

> - Zig is about perfection. It is a very sharp, dangerous, but, ultimately, more flexible tool.

Depending on project, experience, goals, team composition and personality, reading these two bullet points you're very likely to gravitate much more towards one or the other, and potentially feel rejection towards the other.

Re: Zig and Rust

#18

Post by [deleted] »

scythe wrote: post #12

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

[deleted]

Re: Zig and Rust

#19

Post by crop_rotation »

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.

Re: Zig and Rust

#20

Post by netbioserror »

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

Post reply on HN