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

Zig: Pointer Stability for ArrayLists

ziglang.org

Post reply on HN
Print view View original

71–80 of 91 posts

Re: Zig: Pointer Stability for ArrayLists

#71

Post by csande17 »

mirashii wrote: post #67
amluto wrote: post #7

This seems weak. In a language like Rust, the compiler will “lock” the pointers for you, and you can’t forget. In a language like C++ (and presumably Zig), one could, in theory at least, have the iterators and slices that reference the storage of a dynamic array hold some sort of lock that pins the storage. But this API requires the programmer to remember to lock the pointers and also requires the programmer to keep…

To make matters worse, there’s also a weaker documentation problem. Where should one learn that they need to do this? zig.guide’s page on ArrayList doesn’t mention it. https://ziglang.org/documentation/master/std/#std.ArrayList doesn’t mention it, https://ziglang.org/documentation/master/std/#std.ArrayList doesn’t mention it at the top level, just a method in the midst of dozens of other methods. I honestly don’t kno…

The devlog is the very first place changes get written about when they land in Zig's master branch (and sometimes even before!), so presumably zig.guide will mention this change once it actually makes it into a release.

Re: Zig: Pointer Stability for ArrayLists

#72

Post by delamon »

duped wrote: post #21
pron wrote: post #16

Earlier quoted context omitted.

I reach for a low-level language only when I want low-level control over what operations happen and when, what memory is used and when etc.. At present, no language offers me this control and safety at the same time. With Rust, when I need such control (which is always, otherwise I would use a higher-level language), I need to give up safety, anyway, at which point I have no safety and the complexity of a language th…

What are some examples of things you "always" need that require unsafe Rust?

Objects belonging to multiple double-linked lists at the same time. Easily done with intrusive lists. Safe rust would require Rc/Arc: penalty both on memory usage and cpu time.

Re: Zig: Pointer Stability for ArrayLists

#73

Post by weinzierl »

afdbcreid wrote: post #37
pron wrote: post #16

Earlier quoted context omitted.

I reach for a low-level language only when I want low-level control over what operations happen and when, what memory is used and when etc.. At present, no language offers me this control and safety at the same time. With Rust, when I need such control (which is always, otherwise I would use a higher-level language), I need to give up safety, anyway, at which point I have no safety and the complexity of a language th…

> With Rust, when I need such control (which is always, otherwise I would use a higher-level language), I need to give up safety, anyway, at which point I have no safety and the complexity of a language that offers safety. This is a very, very, very common claim. And unfortunately I have no other way to describe it other than a strawman. In 95% (at least) of the application that need systems programming (not to talk…

In addition to that, even unsafe Rust is not like C. It disables a limited set of checks, but Rust's type system, ownership model and bounds checks remain in force.

Not to mention the availability of advanced tooling like MIRI.

Re: Zig: Pointer Stability for ArrayLists

#74

Post by pron »

afdbcreid wrote: post #37
pron wrote: post #16

Earlier quoted context omitted.

I reach for a low-level language only when I want low-level control over what operations happen and when, what memory is used and when etc.. At present, no language offers me this control and safety at the same time. With Rust, when I need such control (which is always, otherwise I would use a higher-level language), I need to give up safety, anyway, at which point I have no safety and the complexity of a language th…

> With Rust, when I need such control (which is always, otherwise I would use a higher-level language), I need to give up safety, anyway, at which point I have no safety and the complexity of a language that offers safety. This is a very, very, very common claim. And unfortunately I have no other way to describe it other than a strawman. In 95% (at least) of the application that need systems programming (not to talk…

> you have at most 20% (wildly overestimating) of code that needs to be unsafe

Obviously, but that doesn't help me if the complexity in the unsafe parts is made worse, while the safety helps the parts where little help is needed. It's not like the danger in a C program is spread evenly, either.

> but will benefit from the performance

Not so much. Safe Rust is faster than Python and Go for sure, but is, on average, about as fast as Java and C#; sometimes faster, sometimes slower.

Re: Zig: Pointer Stability for ArrayLists

#75

Post by afdbcreid »

pron wrote: post #74
afdbcreid wrote: post #37

Earlier quoted context omitted.

> With Rust, when I need such control (which is always, otherwise I would use a higher-level language), I need to give up safety, anyway, at which point I have no safety and the complexity of a language that offers safety. This is a very, very, very common claim. And unfortunately I have no other way to describe it other than a strawman. In 95% (at least) of the application that need systems programming (not to talk…

> you have at most 20% (wildly overestimating) of code that needs to be unsafe Obviously, but that doesn't help me if the complexity in the unsafe parts is made worse, while the safety helps the parts where little help is needed. It's not like the danger in a C program is spread evenly, either. > but will benefit from the performance Not so much. Safe Rust is faster than Python and Go for sure, but is, on average, ab…

> Obviously, but that doesn't help me if the complexity in the unsafe parts is made worse, while the safety helps the parts where little help is needed. It's not like the danger in a C program is spread evenly, either.

The complexity is made worse for specific, isolated, encapsulated and reusable code, while all other code becomes significantly safer? That's a deal I'll take at any time. And again, empirical evidence proves that to work.

> Not so much. Safe Rust is faster than Python and Go for sure, but is, on average, about as fast as Java and C#; sometimes faster, sometimes slower.

Nonsense. In all benchmarks I saw Rust is significantly faster than C# and Java, sometimes up to 2x-3x, and about on par with C++ (can be a few percents slower but that depends on many things). In fact Go is closer most of the time.

Re: Zig: Pointer Stability for ArrayLists

#76

Post by Meneth »

csande17 wrote: post #71
mirashii wrote: post #67

Earlier quoted context omitted.

To make matters worse, there’s also a weaker documentation problem. Where should one learn that they need to do this? zig.guide’s page on ArrayList doesn’t mention it. https://ziglang.org/documentation/master/std/#std.ArrayList doesn’t mention it, https://ziglang.org/documentation/master/std/#std.ArrayList doesn’t mention it at the top level, just a method in the midst of dozens of other methods. I honestly don’t kno…

The devlog is the very first place changes get written about when they land in Zig's master branch (and sometimes even before!), so presumably zig.guide will mention this change once it actually makes it into a release.

Ideally, the documentation changes would have been merged together with the code changes.

In practice, Zig has very poor documentation overall.

Re: Zig: Pointer Stability for ArrayLists

#77

Post by Meneth »

frmdstryr wrote: post #19
amluto wrote: post #7

This seems weak. In a language like Rust, the compiler will “lock” the pointers for you, and you can’t forget. In a language like C++ (and presumably Zig), one could, in theory at least, have the iterators and slices that reference the storage of a dynamic array hold some sort of lock that pins the storage. But this API requires the programmer to remember to lock the pointers and also requires the programmer to keep…

Do any languages have a notion of "relative pointers"? So in the example if instead of appending "line" as ptr & len, it'd instead be appending an offset & len which could in theory be used to safely compute the actual location even with relocations.

C++ has pointers to members.

https://en.cppreference.com/cpp/language/pointer

Re: Zig: Pointer Stability for ArrayLists

#78

Post by steveklabnik »

weinzierl wrote: post #73
afdbcreid wrote: post #37

Earlier quoted context omitted.

> With Rust, when I need such control (which is always, otherwise I would use a higher-level language), I need to give up safety, anyway, at which point I have no safety and the complexity of a language that offers safety. This is a very, very, very common claim. And unfortunately I have no other way to describe it other than a strawman. In 95% (at least) of the application that need systems programming (not to talk…

In addition to that, even unsafe Rust is not like C. It disables a limited set of checks, but Rust's type system, ownership model and bounds checks remain in force. Not to mention the availability of advanced tooling like MIRI.

It does not disable any checks at all. It adds some unchecked features. All checked features are checked all the time.

Re: Zig: Pointer Stability for ArrayLists

#79

Post by uecker »

slopinthebag wrote: post #34
pron wrote: post #16

Earlier quoted context omitted.

I reach for a low-level language only when I want low-level control over what operations happen and when, what memory is used and when etc.. At present, no language offers me this control and safety at the same time. With Rust, when I need such control (which is always, otherwise I would use a higher-level language), I need to give up safety, anyway, at which point I have no safety and the complexity of a language th…

But the point of unsafe {} in Rust is not that you should never use it, it's that it creates a clear boundary between code that is safe and the code that needs that lower level control. In other languages, everything is inside an unsafe block. If everything you do requires such low level control over every allocation and access, it sounds like you should be using assembly.

While I think this is a good idea, I think this the importance is massively exaggerated. Not everything in other languages is unsafe, there are also different features one can distinguish where some are safe and some are not. It is not as clearly labelled and a set of features one must screen for instead of one keyword, but pretending this then makes it everything unsafe is disingenuous. At the same time, the distinction is Rust is also not always that clear, as the correctness of the unsafe block may depend on logic outside of the block while soundness of the safe parts may be compromised by issues in the unsafe blocks.

Re: Zig: Pointer Stability for ArrayLists

#80

Post by Rendello »

metaltyphoon wrote: post #53
Rendello wrote: post #14

Aside: one Zig (syntax) feature that I really missed in Rust is shown in the second code block, namely prefixed multi-line string literals à la: const text = \\This is a long comment \\But I can split it among lines arbitrarily \\And keep my indentation. ; I've started using the Rust macro library `docstr` [1], which does the same thing: const TEXT: &'static str = docstr!( /// Now I can do it in Rust, too. /// I pref…

C# solves this so elegantly string text = """ This is a long comment But I can split it And keep my indentation. """;

I believe the prefixed literals are a direct response to this style of multiline string. The style you showed is pretty common in a programming languages, but language implementers are faces with a tradeoff:

- Keep the initial indentation for each line in the string literal; or

- Track the indentation level and attempt to remove the whitespace for each line.

For a lot of strings, extra whitespace doesn't matter (eg. SQL), but when you don't want it, you end up removing the indentation in the string literal, and having a string like this:

    fn f() {
        text = "This is a decent way to format strings,
    but surely it could be a little nicer indentation-wise,
    right?";
        print(text);
    }
The prefixed lines have the disadvantage of being a pain to use if your editor doesn't have nice multi-line editing like Vim or Sublime. But I think it's a nice option when it's available.
Post reply on HN