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

21–30 of 247 posts

Re: Zig and Rust

#21

Post by MrBuddyCasino »

steveklabnik wrote: post #14
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…

Thanks for the example. I wasn't aware this is something that was planned for Rust, seems like a pretty large breaking change. Interesting!

Re: Zig and Rust

#22

Post by fweimer »

steveklabnik wrote: post #14
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…

I understood the comment to be more about some way to parameterize allocators on a per-type basis for standard library types, and not a specific mechanism.

C++ nowadays has stateful allocators (e.g., allocate in this specific pool please). With that, even the variant with a type parameter on the type benefits from a constructor argument that specifies an allocator object explicitly.

And I don't think the type-parameter-on-functions-only approach can be made safe for immutable data structures because the allocators used for allocation and deallocation must match. And the appropriate allocator needs to be known at Drop time anyway.

Re: Zig and Rust

#23

Post by mats852 »

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…

And also the billions of tests they run against every builds!

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/#billio...

Re: Zig and Rust

#24

Post by formerly_proven »

nindalf wrote: post #13

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

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.

Re: Zig and Rust

#25

Post by nevi-me »

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.

Re: Zig and Rust

#26

Post by epage »

steveklabnik wrote: post #14
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…

Having dealt with the brittleness of mixed-allocator code in C/C++, I much prefer library designs that ensure I'm using the right allocator in the right place.

Re: Zig and Rust

#27

Post by steveklabnik »

MrBuddyCasino wrote: post #21
steveklabnik wrote: post #14

Earlier quoted context omitted.

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…

Thanks for the example. I wasn't aware this is something that was planned for Rust, seems like a pretty large breaking change. Interesting!

Nothing is breaking! The change isn't a move to a zig-like style, but instead, that in today's Rust, you have

  struct Foo {
      // ...
  }
and not

  struct Foo {
      // ...
  }
This isn't breaking because there is a default type provided for A.

The handwave is over "Today's Rust", as this machinery has already landed, in a sense, it's just not really possible to use with the standard library because the allocator API isn't fully stable.

Here's an actual example: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html See that "A = Global"?

Re: Zig and Rust

#28

Post by WhereIsTheTruth »

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)

Re: Zig and Rust

#29

Post by MrBuddyCasino »

crop_rotation wrote: post #19

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

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

Re: Zig and Rust

#30

Post by nindalf »

lucasyvas wrote: post #15
avinassh wrote: post #7

Earlier quoted context omitted.

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

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.

Post reply on HN