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

81–90 of 247 posts

Re: Zig and Rust

#81

Post by [deleted] »

sramsay wrote: post #79
netbioserror wrote: post #20

Still not convinced that memory semantics are critical in the vast majority of domains. Incredibly fast speeds can be achieved with simple GC and RC for short-running programs, and programs with sustained runtimes can rely on generational GC. These methods have the advantage of nearly eliminating the need for memory semantics, leaving only business logic behind. The best example might be Nim, which drastically reduce…

I completely agree with what you're saying here and wonder every day why Nim hasn't taken over the world. People seem not to realize that Nim not only has a "pluggable" gc system (so you can pick the gc that makes sense for your use case), but also allows you to turn the gc off . As in, no gc (which is exactly what you need in certain very narrow situations).

[deleted]

Re: Zig and Rust

#82

Post by netbioserror »

sramsay wrote: post #79
netbioserror wrote: post #20

Still not convinced that memory semantics are critical in the vast majority of domains. Incredibly fast speeds can be achieved with simple GC and RC for short-running programs, and programs with sustained runtimes can rely on generational GC. These methods have the advantage of nearly eliminating the need for memory semantics, leaving only business logic behind. The best example might be Nim, which drastically reduce…

I completely agree with what you're saying here and wonder every day why Nim hasn't taken over the world. People seem not to realize that Nim not only has a "pluggable" gc system (so you can pick the gc that makes sense for your use case), but also allows you to turn the gc off . As in, no gc (which is exactly what you need in certain very narrow situations).

One of these days I'll be able to try embedded Nim with no GC. I want to see what its arena allocation semantics are like.

Re: Zig and Rust

#83

Post by gabereiser »

I'm learning zig myself after several years of doing rust and golang (I still use golang a lot).

I particularly like the quote >"Because even if you and I both know how to write memory safe C, it’s very hard for us to have an interface boundary where we can agree about who does what."

This is still a huge issue in many domains, in many languages. Do you throw the contract out the window on responsibility because you lean on your GC? Or do you make it explicit on who owns what when you don't have a GC. If I allocate a struct as part of my ABI to give to you, the application developer, am I clear on who's responsible for freeing the struct? Do I provide a function for that or do I call it out as gospel for using the library? I wish we didn't have to have these fights.

Re: Zig and Rust

#84

Post by fnordpiglet »

xedrac wrote: post #37
nindalf wrote: post #30

Earlier quoted context omitted.

Agree with everything you've said. > I don't need a language This, but the bigger issue is that I don't think I can be trusted with such a sharp tool. I'm just aware of my own limitations, and I think I'd better stick to safe languages.

I don't want to need to be trusted. And I don't want to have to trust others so much. I want my tools to tell me I, or someone on my team, did something stupid.

Even better, to not be allowed to do something stupid.

Re: Zig and Rust

#85

Post by mr_00ff00 »

AnIdiotOnTheNet wrote: post #36
MrBuddyCasino wrote: post #29

Earlier quoted context omitted.

> I think unless you have some precise needs about memory allocation, and want to control exactly where when and how memory is allocated, it is hard to argue in favour of Zig. I do have a hard time to think of use cases other than embedded microcontroller work where that matters nowadays. That said, I suspect that while they could have written TigerBeetle in Rust (no_std does not assume the existence of an allocator)…

> I do have a hard time to think of use cases other than embedded microcontroller work where that matters nowadays. People keep saying things like this and software keeps getting more bloated and shittier. It is difficult to believe there isn't a correlation.

I might be misreading this comment, but the answer to bloated software is not writing all of it in rust/C++/zig.

The reasons for bloat is not garage collection.

Re: Zig and Rust

#86

Post by fnordpiglet »

avinassh wrote: post #7
fnordpiglet wrote: post #6

This sort of convinced me to stay away from Zig

can you elaborate why

Essentially the other comments capture my view. Speed and memory safety with a rigorous type and language system that disallows unsafe operations unless explicitly marked as such is worth a lot. I don’t think this means zig is worthless, and I see a lot of utility in a fast to write lower cognitive load language that offers the same speed and memory efficiency at the cost of runtime safety, but I don’t trust myself or other programmers to do a good enough job. Memory safety bugs are just so difficult to reason about most of the time that I find the compile time safety mechanisms worth whatever overhead they impose, to a point. Rust is far from reaching that point and is generally easy to develop very complex stuff very quickly. So, after reading the article (I’m more familiar with rust than zig, so it was very informative) it led me to conclude it’ll be fun to learn zig but I don’t think it’ll be useful for Serious Stuff.

Re: Zig and Rust

#87

Post by csnover »

> Zig forces you to pass the allocator in, so you might as well think about the most appropriate one!

I really feel like this is an underappreciated aspect of some of the more complained-about constraints that these newer languages place on programmers.

Like an i32, the default allocator will do a reasonable thing most of the time, but having to think about each allocation (is this short-lived or long-lived? is it actually necessary to do a heap allocation at all here? do you actually want GC?) makes code better and pushes the programmer to improve their ability to rationalise about what they’re actually doing in ways that provide tangible benefits.

By way of comparison, when I started writing Rust I was very frustrated by all the explicit conversions, but eventually realised that it (a) forces me to actually stop and think about what the most natural type is for a given value, and (b) also makes it clearer where the natural boundaries are between components. In my experience, if there’s a lot of conversion going on within a function or module, it’s usually not because the language is ‘too verbose’. Instead, it’s because the API boundaries are in the wrong places, and the language has helped to reveal this by making doing the wrong thing harder.

Re: Zig and Rust

#88

Post by yawaramin »

nindalf wrote: post #13

This title is almost perfectly designed to do well on HN, but it's definitely worth reading in it's entirety. Some highlights for me: - The author sees Rust and Zig in different niches. When Rust was created it didn't need to specialise because there were no languages like Rust. It was free to be a general purpose language targeting multiple domains. But that's not the case for Zig. He sees Zig shining at writing sys…

> He sees Zig shining at writing systems software that requires low level control.

Honestly don't see why we would need to specialize this use case to a different language altogether when Rust already has `unsafe`.

Re: Zig and Rust

#89

Post by rektide »

steveklabnik wrote: post #43
rektide wrote: post #34

Earlier quoted context omitted.

> I remember reading his original proposal for why Rust should ditch their existing LSP effort (called Rust Language Server) and start afresh with a completely new. And he was 100% right. Where can I read more about this? What ended up happening?

https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html was the announcement of the replacement, and talks about it a little bit: > RLS was introduced by RFC 1317 and development was very active from 2016 through 2019. However, the architecture of RLS has several limitations that can make it difficult to provide low-latency and high-quality responses needed for an interactive environment. > rust-analyzer uses a fu…

Very cool. Thanks for the links & write up!

Re: Zig and Rust

#90

Post by pron »

> we don’t have a reliability-oriented high-level programming language with a good quality of implementation (modern ML, if you will)

Java is fairly popular, I hear.

Post reply on HN