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

Zig as an alternative to writing unsafe Rust

zackoverflow.dev

Post reply on HN
Print view View original

161–170 of 230 posts

Re: Zig as an alternative to writing unsafe Rust

#161

Post by burntsushi »

hitekker wrote: post #160
mustache_kimono wrote: post #157

Earlier quoted context omitted.

I've actually read the full comment you're referencing and your take absolutely mischaracterizes what was said. Whether your take is malicious or merely reckless, I don't know, but I do know your take is the precise opposite of what was said. Others can read the entire comment themselves[0], but the pertinent part re: this individual discussing 'unsafe' can be found in the second graph: "[W]hen you're learning new th…

[flagged]

Congrats. You're the first person I know of to accuse me of dog whistling. Being "extremely online" for about two decades now, I'd say that's pretty damn good. So what am I dog whistling exactly? That people shouldn't use 'unsafe'? Lol. Wow, I really came out swinging! pats self on back

I am actually teaching my toddler how to use a knife. So I'm not sure how that follows...

The GP is right. My comment was sincere and means the exact opposite of what you accuse me of "implying" or "dog whistling."

Re: Zig as an alternative to writing unsafe Rust

#162

Post by Tarq0n »

pie_flavor wrote: post #50
DeathArrow wrote: post #45

Earlier quoted context omitted.

Writing data structures is trivial in C/C++.

As long as you don't care about UB or edge cases. Every time Rust makes something hard, it's forcing you to handle an edge case up front.

Not strictly true. Rust makes things hard by making you design within the limitations of the borrow checker, and some of those are accidental, not a necessary edge case.

Re: Zig as an alternative to writing unsafe Rust

#163

Post by Narishma »

ilrwbwrkhv wrote: post #24
ok123456 wrote: post #9

This pretty much mirrors my experience. Rust is the inverse of Perl: It makes the easy stuff hard. Writing basic data structures isn't a niche, esoteric edge case. There may be a crate that "solves" what you're trying to do. But does it rely on the std---(i.e., is it unusable for systems programming)? Is it implemented making gratuitous copies of data everywhere? Does it have a hideous interface which will then pollu…

On top of that Rust might be the ugliest modern language.

That's entirely subjective. I personally find Zig, Nim and even Go much uglier than Rust.

Re: Zig as an alternative to writing unsafe Rust

#164

Post by alphanullmeric »

stouset wrote: post #37
ilrwbwrkhv wrote: post #24

Earlier quoted context omitted.

On top of that Rust might be the ugliest modern language.

People keep saying this and I just do not get it . It's just… not that bad?

No arrow operator, no default args, no named parameters, no structure defaults and instead the incredibly verbose ..Default::default() + a trait impl as a substitute, no variadics, overall weak generics compared to C++ and a huge reliance on macros, etc etc. Rust programmers address this by calling everything rust does poorly an antipattern, ie. the “why would you do that” card.

Re: Zig as an alternative to writing unsafe Rust

#165

Post by Tarq0n »

bxparks wrote: post #98
malcolmstill wrote: post #81

Earlier quoted context omitted.

There are a number of sources of noise in rust, but the one I find most annoying (because it's also so common) is the double colon. My current theory is that it's because the colon is the same height as lowercase letters. If you end up with a long::run::of::module::names, I find it all just blurs into one.

That is a very interesting observation. I am starting to have a similar distaste for the visual noise caused by the ':' in my fully type-annotated Python code. This is particularly noticeable after spending a few weeks writing Golang, then going back to my Python code. The Go code feels far cleaner syntactically and visually.

I wonder if this could be ameliorated through font choice and highlighting.

Re: Zig as an alternative to writing unsafe Rust

#166

Post by xcdzvyn »

dureuill wrote: post #131
malcolmstill wrote: post #115

Earlier quoted context omitted.

To be honest that's the major one for me. Someone else has mentioned lifetime annotations, but those uncommon enough that I don't find it much of an issue. If I was to think about it: comparing rust to zig, zig benefits a lot from error and optional types having their own syntax rather than being treated like any other type. For example a return type of: Result , Error>> in rust is rendered (mostly) equivalently in z…

i'm curious, how do you specify the error type in the zig version?

ErrorType!usize

Re: Zig as an alternative to writing unsafe Rust

#167

Post by tialaramex »

foldr wrote: post #140
rom-antics wrote: post #77

Earlier quoted context omitted.

If you want compact, use an array of tuples: const foos = [("foo", 1, "bar"), ("foo", 1, "bar"), ...]; for (str1, num, str2) in &foos { // ... } For a proper struct you have to name the fields, because otherwise refactoring the fields could cause struct instances to silently get out of sync with the definition.

>otherwise refactoring the fields could cause struct instances to silently get out of sync with the definition. Having to name the fields is only part of the pain. You also have to redundantly repeat the struct name. I don't see any fundamental reason why something like this shouldn't be valid: let foo: [MyStruct; _] = [{a: "foo", b: 1, c: "amp"}, {a: "bar", b: 1, c: "fff"}, {a: "amp", b: 1, c: "aaa"} ]; I can see th…

You can use map() to turn an array of tuples into an array of structures. Unfortunately at time of writing the optimiser doesn't do a great job on this, so if you're making an array of several thousand of something, or an array of things which are themselves very large, this might have unacceptable performance, but in cases where I have say a modest N values and I want N structures based on those values...

  fn make_struct(x: (&str, u8, &str)) -> MyStruct {
     MyStruct { a: x.0, b: x.1, c: x.2 }
  }

  let foo = [("foo", 1, "amp"), ("bar", 1, "fff"), ("amp", 1, "aaa")]
    .map(make_struct);
[I have not actually compiled this code, but it should do roughly what you meant]

Re: Zig as an alternative to writing unsafe Rust

#168

Post by tialaramex »

no_wizard wrote: post #109
foldr wrote: post #66

Earlier quoted context omitted.

One random thing that bugs me about Rust's syntax is array initialization. In Go I can initialize an array (or strictly speaking a slice) of structs like this: var foo []my_struct = {{"foo", 1, "bar"}, {"foo", 1, "bar}, ...} This is often useful in tests (where each struct value represents a test case). Rust doesn't seem to offer any similarly compact initialization syntax for arrays or Vecs. You have to write some a…

you'll have to forgive me, but isn't this why there should be a `::new()` callable attached to the struct? I'm really new at Rust, but that was my takeaway, e.g. `String` has `String::new()`

The convention of providing a new() function isn't relevant here, that name isn't magic, the Rust compiler doesn't care whether it exists, and it won't cause Rust to do anything special with tuples (or any other data structure) that happen to have a similar shape.

String::new() just makes you an empty String, which, since an empty String doesn't own any storage and doesn't contain anything, is very cheap (and indeed constant evaluable), likewise Vec::new() makes an empty Vec.

What your parent commenter wants is for Rust to make the appropriate MyStruct, but without them needing to say MyStruct each time, which would have worked in e.g. C or Go.

Re: Zig as an alternative to writing unsafe Rust

#169

Post by tialaramex »

foldr wrote: post #138
guipsp wrote: post #73

Earlier quoted context omitted.

Do you mean the vec! macro?

It doesn't let you drop redundant struct tags, as far as I can tell.

I think you're right, although mentioning a macro does suggest another option here, you could write a macro which transforms [{foo1, "bar1", baz1}, {foo2, "bar2", baz2}] into the named structure version.

Since it's a macro there's no impact on runtime performance, but on the other hand it's more work to debug it. Learning declarative macros in Rust is much nicer and safer than learning C macros, but nowhere near as powerful as Rust's horribly unsafe proc macros.

Re: Zig as an alternative to writing unsafe Rust

#170

Post by stouset »

Asooka wrote: post #129
stouset wrote: post #37

Earlier quoted context omitted.

People keep saying this and I just do not get it . It's just… not that bad?

My biggest peeve is types on the right. I would say that C is "humanistic" in its type declarations, while Rust and the rest of Pascal's lineage are "mechanistic". Concretely, look at this: int foo(int a, float b); vs fn foo(a: i32, b: f32) -> i32; In Rust's case you're specifying to the machine what the thing is, i.e. "I am declaring a function called foo. The function has a first parameter called a, of type i32, ..…

I'll simply say that you are the first person I've seen come to the defense of C's inside-out variable syntax.
Post reply on HN