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

221–230 of 247 posts

Re: Zig and Rust

#221

Post by Tarq0n »

netbioserror wrote: post #149
wyldfire wrote: post #108

Earlier quoted context omitted.

> It's still bizarre though that Rust is capturing such ridiculous mindshare. I don't think it's that bizarre. The two big headline features that bring Rust such popularity are: #1 "70% of bugs are memory-safety bugs" [1] and Rust can help solve those, and #2 C/C++ have a couple of package manager solutions - none of which have critical mass and Rust "comes with" cargo. Those two make me really eager to continue expe…

> This is some weird gatekeep-y kinda thing. Most of us didn't start out with low-level programming. Wouldn't it have been odd and frustrating for someone to tell your younger self that you have "never written C and probably never will"? I'm not making any sorts of demands about who should be able to program at a low level, but I'm being realistic about who will. I have an intuition that I do not think is unreasonabl…

People bounce off of systems programming because C/C++ is hard. Rust's focus on ergonomics, error management, tooling and learning resources actually makes people want to try again.

Re: Zig and Rust

#222

Post by Tarq0n »

DeathArrow wrote: post #76
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…

The good thing about Nim is that you can chose between several garbage collection algorithms, use no garbage collector at all and do manual memory management or allocate without freeing if the program is short lived and doesn't use much memory. Also having a C interface is great since you can use any C library.

How different are these options from each other, syntactically and semantically? Do i need to know all of them to read library code?

Re: Zig and Rust

#223

Post by pjmlp »

spacechild1 wrote: post #212
pjmlp wrote: post #210

Earlier quoted context omitted.

Depends on what kind of lifetimes, yes C++ doesn't do Rust like lifetimes check, at least not without help from static analysis. However C++23 has introduced compiler aware functions to start specific lifetimes out of raw memory pools. https://en.cppreference.com/w/cpp/language/lifetime

If you mean std::launder, this has been around since C++17. (Not that I ever had to use it :-)

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p25...

Re: Zig and Rust

#224

Post by spacechild1 »

pjmlp wrote: post #223
spacechild1 wrote: post #212

Earlier quoted context omitted.

If you mean std::launder, this has been around since C++17. (Not that I ever had to use it :-)

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p25...

Thanks for the link! I got confused because your cppreference link only talks about std::launder.

I did not know about std::start_lifetime_as. Looks very useful! It's crazy that it took so long. Considering that one of the primary design goals of C++ was backwards compatibility with C (too a large extent), I always found it crazy that malloc'ing objects would be undefined behavior. In practice, this has always worked, though. At least now we have a standard-blessed way to do these kind of things.

As a side note, does this mean that you can finally cast an array of bytes to an object pointer (e.g. for deserialization) without violating strict-aliasing rules? The usage example in section 1.2 of the linked paper seems to imply this, but it does not mention aliasing anywhere...

Re: Zig and Rust

#225

Post by spacechild1 »

spacechild1 wrote: post #214
Animats wrote: post #174

Earlier quoted context omitted.

The lifetime of the space can be different, but must enclose, the objects created in that space. C++ doesn't track lifetimes. Such a separation is only useful in specific situations, such as the one the original article mentions. It could be useful in avionics or industrial control, where you often avoid memory pools and have arrays of specific kinds of objects instead.

> C++ doesn't track lifetimes. Of course, C++ does not have lifetimes (in the Rust sense), but your original claim was that C++ does not seperate allocation from construction. > Such a separation is only useful in specific situations, such as the one the original article mentions. It is actually quite common. You don't even have to reach for advanced things like memory/object pools. For example, if you want to implem…

EDIT

> but your original claim was that C++ does not seperate allocation from construction.

At least that's how I interpreted it.

Re: Zig and Rust

#226

Post by kajaktum »

lenkite wrote: post #188
herbstein wrote: post #187

Earlier quoted context omitted.

> Comment from that issue: "For example, ElasticSearch returns a 8,683KB document, I deser it into Value and the next RAM reading gives me delta of 98,484KB of RAM use. That's more than 10x the original size." I think this is misleading. `serde_json` is designed to parse JSON documents directly into your user-defined structs. Thus the raw `Value` type isn't optimized for direct manipulation. That said, what do you ex…

Yes, I fully understand how enum variants are implemented under the hood. My point was in response to the enthusiastic use of enum variants which generally causes excessive memory to be consumed for even moderate inputs. Folks are surprised by this and then re-write their code to avoid enum variants or use pointer tagging. Enum variants should come with a STRICT warning in the Rust book and Rust reference that their…

How else would you implement tagged union? Rust already optimize away the discriminant when its Option

Re: Zig and Rust

#227

Post by nindalf »

netbioserror wrote: post #160
kaba0 wrote: post #152

Earlier quoted context omitted.

Rust is the first low-level language that actually solves a fundamental problem of low-level programming. I don’t see why is it surprising that it gains weight. Zig, while I appreciate many of its design goals and definitely has some novel ideas, is “just” a better C.

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 so clearly defined. Sure it's possible that Rust code they write might have fewer bugs. But if they think they're the sort of developer that doesn't write bugs, then what does Rust do for them? Just slows them down. I won't get into whether they're right or wrong to feel the way they do.

There's also an element of the former group being more open to learning and adopting new tools. The latter group is more likely to say "if it ain't broke, I don't need to learn a new thing".

Re: Zig and Rust

#228

Post by pjmlp »

spacechild1 wrote: post #224
pjmlp wrote: post #223

Earlier quoted context omitted.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p25...

Thanks for the link! I got confused because your cppreference link only talks about std::launder. I did not know about std::start_lifetime_as. Looks very useful! It's crazy that it took so long. Considering that one of the primary design goals of C++ was backwards compatibility with C (too a large extent), I always found it crazy that malloc'ing objects would be undefined behavior. In practice, this has always worked…

I guess this is also interesting to watch,

"Taking a Byte Out of C++ - Avoiding Punning by Starting Lifetimes - CppCon 2022"

https://www.youtube.com/watch?v=pbkQG09grFw

Re: Zig and Rust

#229

Post by cmrdporcupine »

gpderetta wrote: post #218
cmrdporcupine wrote: post #132

Earlier quoted context omitted.

Indeed, having played with doing compiler / parser / transformation type work (for relational query transformation, etc) in Rust, and got stuck in a maze of borrow-checker disasters around the tree of references... what I'd say is: this kind of thing is actually better done in a higher level statically typed garbage collected language. For myself, I'd use a mature functional something like OCaml/StandardML or a Lisp…

Still major compilers and optimizers are written in C and now C++. GCC was written in C with a custom GC. They have moved to C++ and, as as far as I understand, doing more and more with RAII instead of GC (turns out that peak memory usage is a major factor in compiler performance)

That's fair, and I'm not a compiler engineer so I'll avoid making authoritative claims :-). But a C/C++ compiler is a whole thing, with some pretty intense performance requirements, wouldn't you say?

Mainly I was speaking from the experience of trying to write more complicated parser & tree transformation pieces in Rust and finding the ownership stuff a hassle.

Re: Zig and Rust

#230

Post by renox »

crop_rotation wrote: post #19

I tried zig after reading so many HN articles and I am not impressed. You have to remember to free after each allocation. The language is supposed to be simple, yet there exist try, catch, defer, errdefer. Rust enums make defining errors so simple with arbitrary payload. Using data structures in rust is much nicer. I think unless you have some precise needs about memory allocation, and want to control exactly where w…

> I tried zig after reading so many HN articles and I am not impressed. You have to remember to free after each allocation.

You write like it was a something surprising, but you know Zig is often described as a replacement for C..

Post reply on HN