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

51–60 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#51

Post by coldtea »

mseri wrote: post #37
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 peopl…

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

Why would it "get stale"? It doesn't get stale in Golang.

If anything, being part of the standard library is a greater assurance for more eyes going into it, and not having it get stale, as opposed to the language having 5-6 half-abandoned third party libs...

Re: Assorted Thoughts on Zig and Rust

#52

Post by kzrdude »

k__ wrote: post #44
pizza234 wrote: post #38

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

You're right, but I find Rusts concepts/keywords also a bit confusing. I know what a class and what an interface is, but Rust doesn't have these. It has a struct, which is kinda like a class without methods? It has a trait, which is kinda like an interface but with implementations for methods? It has ... implementations... which kinda make a struct to a class, but not really. I don't mean to hate here, but these are…

Once understood, even taken together, none of those have as many rules baked into one concept as "class" does; each is simple.

Re: Assorted Thoughts on Zig and Rust

#53

Post by kzrdude »

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

Why a http server in the standard library? It's quite likely to end up where Python 3's http.server module is: "Don't use this in production". So when can I then use it? It's mostly a party trick of a module, then.

Re: Assorted Thoughts on Zig and Rust

#54

Post by cesarb »

coder543 wrote: post #40
creata wrote: post #23

Earlier quoted context omitted.

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.

Annoyingly, .into() is mostly useless for array indexing, since even when you're compiling for a 64-bit machine (and thus x[my_u32.into()] would be perfectly fine) it's only defined for up to u16 (because you might want the same multi-megabyte code to also work in a tiny microcontroller). If you don't want to use x[my_u32 as usize], you are forced to use x[my_u32.try_into().unwrap()], or just use usize everywhere (of course, you could also use traits to create your own .into_usize() and use it everywhere).

Re: Assorted Thoughts on Zig and Rust

#55

Post by flohofwoe »

pizza234 wrote: post #38

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

> Complaining on pattern matching?

I've read that as a (minor) complaint that Zig doesn't have Rust's pattern matching, not that there's anything wrong with pattern matching (and that Zig's switch still does 90% of what the author uses Rust's pattern matching for).

Re: Assorted Thoughts on Zig and Rust

#56

Post by selfmodruntime »

creata wrote: post #41
twic wrote: post #24

Earlier quoted context omitted.

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

The obvious solution is that the standard library would provide both options wherever appropriate, just like Rust has `borrow` and `borrow_mut`, `raw_entry` and `raw_entry_mut`, etc. You might be able to save some of this pain with some polymorphism, as some people suggest[0] for `&` and `&mut`, too. It might also be a good idea to look at the standard library of Idris 2[1] — it has linear types and garbage collectio…

There would at least need to be some kind of interface of gc and non-gc methods. I would welcome any academic papers on this idea.

Re: Assorted Thoughts on Zig and Rust

#58

Post by kzrdude »

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

It is annoying since in relationship to bounds checking, we could write a non-surprising automatic conversion - given array length type and index type, we'd need to cast to the bigger of the two and make the bound check. But it doesn't mesh well with the fact that all but primitive indexing are implemented in the library, and is not built in.

Re: Assorted Thoughts on Zig and Rust

#59

Post by Ygg2 »

jmull wrote: post #48
pizza234 wrote: post #38

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

> the author was overwhelmed It strikes me that you start off meaning to rebut the author's point and end up supporting it.

Well, by that logic, Java is overwhelming if you dive right into Aspect oriented programming, the Atomics and Multi-threaded Java.

I don't consider myself an expert in Rust, but hell, the borrow checker was always helpful. I.e. even if it prohibited a sound program, it explained its reasoning at length. It was easy to fix the issue even if it came.

Macros are meta programming, of course they are hard. And even then, there are ways around. Like cargo-expand, it makes procedural macros easier to reason about.

Re: Assorted Thoughts on Zig and Rust

#60

Post by flohofwoe »

monocasa wrote: post #39
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…

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, b…

I agree (I think), Rust is more like C++ and less like C in that it provides mechanisms to enforce certain "custom rules" in bigger code bases and teams via language constructs. Those same mechanisms which help organizing big code bases written by big teams often increase friction in smaller codebases and teams.

In C one has to be very disciplined about this type of stuff and needs to put much more thought into module API design (for instance to enforce memory management rules), because the language itself is extremely "freestyle".

Post reply on HN