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

Assorted Thoughts on Zig and Rust

scattered-thoughts.net

Post reply on HN
Print view View original

31–40 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#31

Post by selfmodruntime »

twic wrote: post #24
selfmodruntime wrote: post #10

I enjoy Rust and have been writing it for quite some time. However, I feel like server side languages still have a long way to go. Client-side languages in comparison have been only growing better (one could make a lot of negative points about TypeScript and node in general, but the ecosystem is a joy to work with). I feel like this is because people have accepted C and C++ with their respective pain points for close…

> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds. I remain to be convinced that this is possible. Rust's ownership model exerts huge design pressure on its standard library. There are some parts that just wouldn't work without ownership (like guards), and many that are far less ergonomic than they cou…

Well, the idea would be that references and values alike could be marked to be excluded from the garbage collector and then used in a borrowed way. If you want to interface with the garbage collector, you have to do so in an explicit way. However, I have no idea how to do so.

Re: Assorted Thoughts on Zig and Rust

#32

Post by johncolanduoni »

twic wrote: post #24
selfmodruntime wrote: post #10

I enjoy Rust and have been writing it for quite some time. However, I feel like server side languages still have a long way to go. Client-side languages in comparison have been only growing better (one could make a lot of negative points about TypeScript and node in general, but the ecosystem is a joy to work with). I feel like this is because people have accepted C and C++ with their respective pain points for close…

> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds. I remain to be convinced that this is possible. Rust's ownership model exerts huge design pressure on its standard library. There are some parts that just wouldn't work without ownership (like guards), and many that are far less ergonomic than they cou…

I think it would need to have a GC like Go’s that allows arbitrary interior pointers. Then most of the standard library could continue to take references, which would be allowed to point to GC or non-GC memory. There isn’t too much in the standard library that wants you to pass things to it to take ownership of that make sense to be shared. For example, the buffered reader structure wants ownership of the file it’s reading from, but it’s not like it’s going to make sense to read the same file descriptor at the same time it’s being read by the buffered reader.

I think the bigger problem is that GC pointers will have to work like Rust’s reference counted pointers do today, meaning you need to use mutexes, read-write locks, etc. to mutate anything behind them. Most shared-memory GC languages allow free data races on all member variables, and just provide unordered atomicity to prevent you from being able to cause a race that writes a bad pointer somewhere. Changing that would be a much stronger mismatch, and as long as that’s the case you’re still not going to be able to write Rust code like you would Java or C#.

Re: Assorted Thoughts on Zig and Rust

#33

Post by teleforce »

weinzierl wrote: post #4
the_mitsuhiko wrote: post #2

I quite honestly wonder sometimes why Rust excited me so much when I first started using it, but I do not get such excitement from Zig. Nowadays it's very easy to be excited about Rust because it demonstrated that ownership works but when I started using it, there was still garbage collection etc. Zig looks really cool but it feels like it has a high chance of being a niche language. Rust never felt like that.

While Zig is an awesome project I feel a little bit the same. My two cents are that it is because Zig, as innovative as it is, has nothing that other languages couldn't copy or assimilate. With Rust it is a different story, because the ownership model cannot be plugged into other languages without changing them fundamentally. My prediction is similar to yours that Zig will be an important research project but not go…

D language is currently experimenting the ownership model made popular by Rust/Cyclone and similar to Zig it has excellent CTFE support:

https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...

Re: Assorted Thoughts on Zig and Rust

#34

Post by teleforce »

twic wrote: post #24
selfmodruntime wrote: post #10

I enjoy Rust and have been writing it for quite some time. However, I feel like server side languages still have a long way to go. Client-side languages in comparison have been only growing better (one could make a lot of negative points about TypeScript and node in general, but the ecosystem is a joy to work with). I feel like this is because people have accepted C and C++ with their respective pain points for close…

> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds. I remain to be convinced that this is possible. Rust's ownership model exerts huge design pressure on its standard library. There are some parts that just wouldn't work without ownership (like guards), and many that are far less ergonomic than they cou…

>I remain to be convinced that this is possible.

Check out D language with default GC and the ongoing effort opt-in ownership model:

https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...

Re: Assorted Thoughts on Zig and Rust

#35

Post by AnIdiotOnTheNet »

twic wrote: post #30
flohofwoe wrote: post #15

Earlier quoted context omitted.

Rust and Zig target different audiences though. It's often been said before, but Rust is mainly a C++ replacement, while Zig is mainly a C replacement. I have switched from C++ as my default-language to C a few years ago, and having dabbled a bit in both, I feel a lot more attracted to Zig than Rust for future projects (and mostly for the same reasons why I switched from C++ to C). If Zig can settle in the niche that…

> If Zig can settle in the niche that C is used for today That niche is "code that needs to be portable to any system with a C compiler", or "... to a particular system that only has a C compiler" so i am not sure it can. There are lots of projects using C that aren't in that niche, but i don't believe there is a good reason for any of them to be using C over C++ these days. It's either history, inertia, or Luddism.

Zig has high interoperability with C and plans to have a C backend as well.

https://github.com/ziglang/zig/issues/3772

Re: Assorted Thoughts on Zig and Rust

#36

Post by kazagistar »

the_mitsuhiko wrote: post #2

I quite honestly wonder sometimes why Rust excited me so much when I first started using it, but I do not get such excitement from Zig. Nowadays it's very easy to be excited about Rust because it demonstrated that ownership works but when I started using it, there was still garbage collection etc. Zig looks really cool but it feels like it has a high chance of being a niche language. Rust never felt like that.

For me its easy: haskell was cool for more obvious reasons but a bit much, and rust felt like an interesting yet practical very strongly typed language.

Re: Assorted Thoughts on Zig and Rust

#37

Post by mseri »

latch wrote: post #12

Looks like there's active work going into it (1) (2), but Zig's lack of built-in http library has been a showstopper for me. I've had a few small side projects I wanted to do which involved exposing an API. (1) https://github.com/ziglang/zig/issues/910 (2) https://github.com/ziglang/zig/issues/2007

I am still torn about this. I can see the usefulness of it from python and go, but I also fear that it brings an unnecessary large maintenance burden.

Http standards are evolving and soon the implementation will get stale, being in the standard library there will be need to updated it and possibly maintain backwards compatibility, even when it becomes clear that a new design may be a better option. So, suddenly people will start using new, often better, libraries but you need to keep find workforce to maintain the old stdlib http library.

That is mostly why I keep thinking that it would be better to have it as a separate library, with an easy-to-use package manager to discover and use it.

Re: Assorted Thoughts on Zig and Rust

#38

Post by pizza234 »

I think this an argument like the following is not really meaningful:

> Most of this difference is not related to lifetimes. Rust has patterns, traits, dyn, modules, declarative macros, procedural macros, derive, associated types, annotations, cfg, cargo features, turbofish, autoderefencing, deref coercion etc

Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the need for macros emerges by itself, then learning them is a natural part of the process. But even then, nobody is forced to write any.

Dyn is also a very obvious concept to anybody who knows a bit of OO-programming in lower-level languages (e.g. C++). The choice to make dynamic dispatching explicit is arguable, but ultimately, although making it explicit is (AFAIK) Rust-specific, the concept itself isn't.

Complaining on pattern matching? C'mon :-) It's a bit like a Python programmer complaining that Golang has a switch/case.

I don't argue that Rust is hard or not, but it seems to me that the author was overwhelmed, and complained about everything, even simple things.

In my experience, in the Rust learning process (and programming experience), all the concepts above are dwarfed by the headaches induced by the borrow checker.

> Zig has it's own implementation of standard OS APIs which means that linking libc is completely optional. Among other things, this means that zig can generate very small binaries which might give it an edge for wasm where download/startup times matter a lot.

I'm curious about the details of this. Rust has `no_std`, however, it seems that in Zig, this is more (in a way) granular?

Re: Assorted Thoughts on Zig and Rust

#39

Post by monocasa »

flohofwoe wrote: post #15
weinzierl wrote: post #4

Earlier quoted context omitted.

While Zig is an awesome project I feel a little bit the same. My two cents are that it is because Zig, as innovative as it is, has nothing that other languages couldn't copy or assimilate. With Rust it is a different story, because the ownership model cannot be plugged into other languages without changing them fundamentally. My prediction is similar to yours that Zig will be an important research project but not go…

Rust and Zig target different audiences though. It's often been said before, but Rust is mainly a C++ replacement, while Zig is mainly a C replacement. I have switched from C++ as my default-language to C a few years ago, and having dabbled a bit in both, I feel a lot more attracted to Zig than Rust for future projects (and mostly for the same reasons why I switched from C++ to C). If Zig can settle in the niche that…

The more I use Rust, the more it doesn't remind me of C++, but instead the C structure of larger projects. C (and really any language probably) kinda feels like a different language with each few orders of magnitude in code size. Rust feels a lot like forcing the structure of 10KLOC to 1MLOC C projects to me with sane defaults and more powerful versions of the same abstractions.

We're not using string based macros, but hygenic macros.

We're not using goto error, but instead RAII.

We're not guessing if a function returns 0 or 1 on success and if the big struct we passed in as a pointer is valid on either of those, we're using an ADT that makes it clear.

Slices mean everyone aren't reimplementing 1000 morphs of the same buffer struct.

And the deeper separation between code and data that the fat pointers give you and how the more you go down OO principles, the less idiomatic it feels, really feels more like a giant C codebase than a C++ one to me.

Re: Assorted Thoughts on Zig and Rust

#40

Post by coder543 »

creata wrote: post #23
IshKebab wrote: post #18

> Both languages will insert implicit casts between primitive types whenever it is safe to do so, and require explicit casts otherwise. I think Rust always requires explicit casts. It's a bit annoying tbh - especially for array indexing - indexing with a u8, u16 or u32 should always be fine but you still have to do `as usize`.

You can also write `as _` most of the time. Edit: But as the reply below says, please don't.

Which is not recommended, because it could silently truncate if _ is a smaller type, or later becomes one as the code is edited over time.

Much better to use ::from() or into() for numeric type conversions, which are only implemented for types that are guaranteed to fit the value, unless you know that truncation is perfectly fine behavior in a particular instance... which it rarely actually is.

Post reply on HN