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

231–240 of 247 posts

Re: Zig and Rust

#231

Post by _0w8t »

Dwedit wrote: post #196
_0w8t wrote: post #166

Earlier quoted context omitted.

The problem with GC is that when it does give problems, there are no good choices. One either spends time trying to tune available knobs to hide the problem or rewrite application to try to reuse objects etc. turning the initial nice architecture into spaghetti mess. I very much prefer for this reason reference counting. Yes, time can be wasted fighting leaks through cycles, one still have avalanches of releases prob…

The real downside to reference counting is concurrency. If the Reference Counter lives in one Core A's L1/L2 cache, then Core B needs to write to the reference count, the cache line is invalidated, and Core A needs to re-fetch it again. You get two cores fighting over the cache line. Everything still works correctly, but it causes some delays if each core is constantly updating the reference counter. One workaround i…

Apple mostly solved that problem in their silicon. But thread-private counters is a good solution for other platforms.

Re: Zig and Rust

#232

Post by snek_case »

titzer wrote: post #127
kaba0 wrote: post #120

Earlier quoted context omitted.

JIT compilers don’t actually need that low-level programming, and compilers in general use memory in a very haphazard way so they are likely better off with a GC. In fact, you probably loose way more by not being able to write as many/great optimizations in a low-level language than what you lose on a slight overhead — e.g. Java’s Graal JIT compiler is nowadays performing better (written in Java itself) than the “ori…

I second that; there is nothing inherent about a JIT that requires low-level memory tricks, except that last step of making the machine code executable and callable. I'm not sure that Rust is a good fit for optimizing compilers, either. E.g. most compiler IRs are fundamentally graph-based and use unrestricted cycles. TurboFan in V8 uses arena-style allocation, as do most of the JITs in other JSVMs, mostly because man…

Firstly, an arena-based allocator is a custom allocator, which is something most programmers never need to touch and probably don't know even know about. It is a "low-level memory trick".

Secondly, we were talking about how Zig makes allocation first-class. This is a prime use case: specifying your own custom arena-based allocator.

Re: Zig and Rust

#233

Post by Yoric »

kaba0 wrote: post #172
Yoric wrote: post #169

Earlier quoted context omitted.

To clarify, I have actually coded a bit in Haskell and I have actually released open-source code in SML/NJ, a commercial application in OCaml and worked (as a very minor contributor) on industrial code in Coq. But if I have to start a new industrial project, I will most likely use Rust, because it is easier to hire and because there is lots of momentum in the Rust ecosystem, which means that there are crates for just…

> which means that there are crates for just about everything There is definitely momentum, but it doesn’t make Rust’s ecosystem big relative to the top 5 in any way.

Absolutely.

Re: Zig and Rust

#234

Post by Yoric »

tome wrote: post #216
ben0x539 wrote: post #158

Earlier quoted context omitted.

I know this is facile, and it's speaking as someone with a lot more enthusiasm about than expertise with Haskell, but whenever I write some toy Haskell code and have to think about "remember to close this file handle before the end of this block" or "make sure not to use this file handle outside this block (because we just used a combinator to close it)", I'm baffled that Rust has mostly figured out that whole class…

> I'm baffled that Rust has mostly figured out that whole class of problem before Haskell Have you heard of `withFile`? https://www.stackage.org/haddock/lts-20.16/base-4.16.4.0/Sys...

Note that a `Handle` can escape from `withFile` (unless perhaps this library has been updated to use linear types, I haven't followed Haskell in a while).

That being said, even without linear types, it's much harder to accidentally leak a scoped value in Haskell than in most other programming languages, as the leak shows up in the type signature.

/pedantic

Re: Zig and Rust

#235

Post by tome »

Yoric wrote: post #234
tome wrote: post #216

Earlier quoted context omitted.

> I'm baffled that Rust has mostly figured out that whole class of problem before Haskell Have you heard of `withFile`? https://www.stackage.org/haddock/lts-20.16/base-4.16.4.0/Sys...

Note that a `Handle` can escape from `withFile` (unless perhaps this library has been updated to use linear types, I haven't followed Haskell in a while). That being said, even without linear types, it's much harder to accidentally leak a scoped value in Haskell than in most other programming languages, as the leak shows up in the type signature. /pedantic

> Note that a `Handle` can escape from `withFile`

Yes, this is true. If someone really wanted they could write a version that didn't using an ST-like type variable trick. I guess it hasn't been considered sufficiently necessary.

Re: Zig and Rust

#236

Post by netbioserror »

nindalf wrote: post #227
netbioserror wrote: post #160

Earlier quoted context omitted.

I think your comment can actually help me clarify what I meant. My perception is that there is a rift between what domains Rust is targeting versus what audience is actually hyped about Rust. When I look to the C++ world and the embedded/realtime systems industry, what I see is lots of discussion about Carbon and herb Sutter's CppFront. I don't see as much Rust discussion. When I look to the JavaScript/webdev/fullsta…

Rust solves a problem for people who only know GC languages - performance. They see their developer tools rewritten in Rust to great success. Examples include ruff for Python, turborepo and turbo build for JS. These tools are worth adopting because they're much faster than what came before them. Therefore Rust is worth learning to build things where performance matters. For C and C++ developers, the value prop isn't…

Part of my purpose with my OP was pointing out that the limiting factor for performance is not GC. When developers are coming from JavaScript and Python, the dominating performance factors are interpreting and dynamic typing. For native-compiled GC languages like Nim, Go, and D, GC only becomes an issue when it interferes with deterministic runtime constraints (RC, bounded GC, and arena allocation fix this), or when the GC is subject to lots of allocations and enormous pressure (which Nim minimizes).

Which is why I find it weird that webdevs are hyped about Rust: They're using it in an enormous number of publicly distributed applications where a native-compiled GC language would be a clearly better long-term choice.

Re: Zig and Rust

#237

Post by j-james »

netbioserror wrote: post #98
klyrs wrote: post #69

Earlier quoted context omitted.

> Still not convinced that memory semantics are critical in the vast majority of domains. This is okay. Zig is not targeting the vast majority of domains. It targets the low-level, performance-critical domain that C occupies. It would be a great language to write a compiler/interpreter for a higher-level language that has the bells and whistles that you want.

It's still bizarre though that Rust is capturing such ridiculous mindshare. I suspect it has a lot to do with web developers being plugged into Mozilla, and Mozilla spending quite a lot on Rust development and marketing. And Zig may be being roped into it. It seems to be a temporary low-level programming zeitgeist driven by YouTube and Reddit recommendation algorithms to an audience that has never done it and probabl…

While I love Nim, another reason for Rust's success (aside from its type system, general good language design, and zero-cost memory safety) is that the tooling is ridiculously good, probably the best of any language I've used, sans maybe Java. Nim's tooling is improving but still has a ways to go - I still occasionally get orphaned langserver processes, and while the langserver itself is pretty good, it's nowhere near the level of what rust-analyzer can do. Especially with error messages and (automatic) refactoring.

Re: Zig and Rust

#238

Post by j-james »

netbioserror wrote: post #115
ibiza wrote: post #99

Earlier quoted context omitted.

That's a a compelling argument: GC/RC w/ stack allocation where possible. I associate GC w/ pointer chasing and the unavoidable L1, L2, L3 cache trashing that goes w/ it. To what extent is this possible? Does Nim have LTOs that rewrite memory handling across compilation units? I'm guessing no, and instead it's local & one-off, rather than something one can bank on.

https://zevv.nl/nim-memory/ Local variables (also called automatic variables) are the default method by which Nim stores your variables and data. Nim will reserve space for your variable on the stack, and it will stay there as long as it is in scope. In practice, this means that the variable will exist as long as the function in which it is declared does not return. As soon as the function returns the stack unwinds a…

Do note that this was written before Nim's new runtime, ARC/ORC, became stable! The author has been working on a companion guide to the new runtime that goes over how it manages to be efficient with reference counting, but it's (very) much a work in progress.

Re: Zig and Rust

#239

Post by einarr »

kristoff_it wrote: post #110
EVa5I7bHFq9mnYK wrote: post #106

>> When we call malloc, we just hope that we have enough stack space for it, we almost never check. Does Rust or Zig's malloc allocate on stack? Those millennials.

It's a function, when you call it, it allocates a frame on the stack.

True. But the author mentions malloc, it just sounds like he's using "stack" instead of "heap" by mistake.

Re: Zig and Rust

#240

Post by einarr »

einarr wrote: post #239
kristoff_it wrote: post #110

Earlier quoted context omitted.

It's a function, when you call it, it allocates a frame on the stack.

True. But the author mentions malloc, it just sounds like he's using "stack" instead of "heap" by mistake.

I see, it was a deliberate choice: https://old.reddit.com/r/Zig/comments/123jpia/blog_post_zig_...
Post reply on HN