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

Assorted Thoughts on Zig and Rust

scattered-thoughts.net

Post reply on HN
Print view View original

91–100 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#91

Post by [deleted] »

gridlockd wrote: post #85
johnisgood wrote: post #29

Earlier quoted context omitted.

> The comptime feature is probably the most exciting thing I've seen in a while Just please do not make the mistake of believing that it is unique to Zig. Factor brings the best of Forth and Lisp together, so meta-programming or extending the language is possible quite easily, for example. You could extend the syntax or add constructs pretty easily, and so forth. Anyways, an example can be found here: https://rosetta…

> Just please do not make the mistake of believing that it is unique to Zig. Factor brings the best of Forth and Lisp together... What is unique to Zig is that it has these features without bringing together "the best of Forth and Lisp". Sometimes, just being pedestrian is a virtue.

[deleted]

Re: Assorted Thoughts on Zig and Rust

#92

Post by mcherm »

q3k wrote: post #72
rob74 wrote: post #49

Earlier quoted context omitted.

This reminds me of the (by now) old saying that code is more often read than written - sure, you're not forced to write macros, but if you use macros (or more exotic features), you force the developers who read your code to become familiar with (possibly arcane) features that they maybe would have never used (or needed). That's why I think Go's approach to not try to be "everybody's darling" by implementing every con…

As coined by Google engineers: software engineering is programming integrated over time. Languages that are paragons of cutting edge PL research unfortunately tend to forget that. Go’s simplicity tends to be brought up as a negative trait (dumb language, dumb users, etc) mostly by those who weren’t yet woken up by a page that required them to quickly read, debug and fix things. Or even jump into another team’s codeba…

> Go’s simplicity tends to be brought [...] mostly by those who weren’t yet woken up by a page that required them to quickly read, debug and fix things. Or even jump into another team’s codebase to do the same thing. Last thing on your mind then is the type safety and elegance of a language.

Actually, type safety can be quite useful in such a context: it allows the person who designed the types in use to enforce certain restrictions on the developer who is hurriedly adding code to an unfamiliar codebase, thus reducing the requirement for that developer to understand larger issues in the system.

Re: Assorted Thoughts on Zig and Rust

#93

Post by steveklabnik »

mtzet wrote: post #83
steveklabnik wrote: post #77

Earlier quoted context omitted.

(By the way, Hacker News doesn't support markdown; indent your code by two spaces, rather than using fences. https://news.ycombinator.com/formatdoc ) Just a few small things: > This is a huge one for me, and I really don't understand why Rust didn't jump on this earlier. Doing this well is not easy. Exposing a full language at compile time isn't a difficult feature, but doing compile-time execution in a sound, safe w…

> Doing this well is not easy Does this also apply to the in-language build system? Given both Rust and Zig's ergonomics, it just seems so brilliantly simple (at least in hindsight) to let the build system be a library. Is it just coincidence that I've only heard of this approach for zig and Jonathan Blow's language, or is there a technical reason this is more difficult than it seems?

I don't know enough about Zig's build system, or Jai's, to be able to talk about their approach intelligently.

Re: Assorted Thoughts on Zig and Rust

#94

Post by detaro »

flohofwoe wrote: post #64
coldtea wrote: post #51

Earlier quoted context omitted.

> I am still torn about this. I can see the usefulness of it from python and go, but I also fear that it brings an unnecessary large maintenance burden. Http standards are evolving and soon the implementation will get stale, Why would it "get stale"? It doesn't get stale in Golang. If anything, being part of the standard library is a greater assurance for more eyes going into it, and not having it get stale, as oppos…

Keep in mind that a HTTP server is only useful for a subset of users, it might be an "obvious" requirement for you, but it definitely isn't for me ;) Features like this should go into libraries, but not the standard library. When looking for a Go or Python alternative, Zig doesn't immediately come to mind TBH. Also: Go (or python) has no UI system or 3D API wrapper in the standard library, but those are (probably) us…

Python has Tk bindings in the standard library at least, which are usable if you just want "an GUI" quickly.

Re: Assorted Thoughts on Zig and Rust

#95

Post by ffdjjjffjj »

Shorel wrote: post #63
selfmodruntime wrote: post #10

I enjoy Rust and have been writing it for quite some time. However, I feel like server side languages still have a long way to go. Client-side languages in comparison have been only growing better (one could make a lot of negative points about TypeScript and node in general, but the ecosystem is a joy to work with). I feel like this is because people have accepted C and C++ with their respective pain points for close…

Fast, garbage collected with plans to add a borrow checker: dlang. It is an absolute joy to write code in D. Only downside is people complaining it has garbage collection.

Has there been much progress with the D borrow checker? It always comes up in these threads but it seems to still be missing some key features (parameterized lifetimes for example). What’s the timeline for this landing in some form of “non-experimental”?

Re: Assorted Thoughts on Zig and Rust

#96

Post by pornel »

pizza234 wrote: post #38

I think this an argument like the following is not really meaningful: > Most of this difference is not related to lifetimes. Rust has patterns, traits, dyn, modules, declarative macros, procedural macros, derive, associated types, annotations, cfg, cargo features, turbofish, autoderefencing, deref coercion etc Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the ne…

As someone with lots of Rust experience I agree with the author. Rust has more concepts that users need to learn. It's not gratuitous/accidental complexity. Each of these features is IMHO pretty well designed and useful, but nevertheless Rust does have a larger toolbox.

It's not necessarily bad. Do you prefer to put more effort into your program before it compiles, or debug it after it's up an running? Do you want a static guarantee, or do you trust yourself to get it right? These are fair trade-offs.

Re: Assorted Thoughts on Zig and Rust

#97

Post by mumblemumble »

steveklabnik wrote: post #71
lambda_dn wrote: post #11

I think Zig's biggest advantage is that it's just C without the warts, or footguns as is said in the Zig world. The comptime feature is probably the most exciting thing I've seen in a while. I've looked at Rust and feel it's more of a competitor to C++, Java and C#. Whereas Zig is C done right.

"Rust is a competitor to C++, not C" is a meme, and there's some truth there, but I don't think it's all that accurate. I know lots of folks who prefer C to C++, but still like Rust. I do think that these sorts of language comparisons are useful, but they don't always generalize. Partially this is because what a language means to each person can vary. As long as they're understood in a very coarse grained way, I thin…

> I know lots of folks who prefer C to C++, but still like Rust.

I'm one of those people, and, while I have yet to use Rust or Zig for any real work, at least so far I also see Rust as being more directly a competitor to C++, and Zig as the more direct competitor to C.

Or perhaps I should say analogue. Because, it's true, I might choose Rust over C. I'm even tentatively planning to, for one project that's still in the idea phase, and that I would normally have wanted to do in C. Though that's not really because I see Rust as being more C-like. It's more that I see choosing Rust as being perhaps more likely to be worth the extra effort than I've found to be the case for C++.

Re: Assorted Thoughts on Zig and Rust

#98

Post by moomin »

gridlockd wrote: post #85
johnisgood wrote: post #29

Earlier quoted context omitted.

> The comptime feature is probably the most exciting thing I've seen in a while Just please do not make the mistake of believing that it is unique to Zig. Factor brings the best of Forth and Lisp together, so meta-programming or extending the language is possible quite easily, for example. You could extend the syntax or add constructs pretty easily, and so forth. Anyways, an example can be found here: https://rosetta…

> Just please do not make the mistake of believing that it is unique to Zig. Factor brings the best of Forth and Lisp together... What is unique to Zig is that it has these features without bringing together "the best of Forth and Lisp". Sometimes, just being pedestrian is a virtue.

But comptime is kind of LISP's unique feature, it's just called macros.

EDIT: In fairness, Zig's presentation is pretty likeable. You can do a comptime expression pretty trivially in LISP, a comptime parameter or block would require actual effort.

Re: Assorted Thoughts on Zig and Rust

#99

Post by steveklabnik »

mumblemumble wrote: post #97
steveklabnik wrote: post #71

Earlier quoted context omitted.

"Rust is a competitor to C++, not C" is a meme, and there's some truth there, but I don't think it's all that accurate. I know lots of folks who prefer C to C++, but still like Rust. I do think that these sorts of language comparisons are useful, but they don't always generalize. Partially this is because what a language means to each person can vary. As long as they're understood in a very coarse grained way, I thin…

> I know lots of folks who prefer C to C++, but still like Rust. I'm one of those people, and, while I have yet to use Rust or Zig for any real work, at least so far I also see Rust as being more directly a competitor to C++, and Zig as the more direct competitor to C. Or perhaps I should say analogue. Because, it's true, I might choose Rust over C. I'm even tentatively planning to, for one project that's still in th…

Yes, it also can matter what you even mean by "competitor." Some people take it to mean "similarity in language features." Others can take it to mean "would I choose it as a substitute." Some take it to mean "would I choose it as a substitute for this specific domain or project."

I've seen this play out a number of times. "Rust cannot compete with C, because C is too entrenched in embedded." "I do embedded development in Rust, so it can." "Well, I work with these chips that Rust can't target yet, so it can't, for me." None of these statements are incorrect, but they can lead to huge back-and-forths.

Words are hard.

Re: Assorted Thoughts on Zig and Rust

#100

Post by patrec »

moomin wrote: post #98
gridlockd wrote: post #85

Earlier quoted context omitted.

> Just please do not make the mistake of believing that it is unique to Zig. Factor brings the best of Forth and Lisp together... What is unique to Zig is that it has these features without bringing together "the best of Forth and Lisp". Sometimes, just being pedestrian is a virtue.

But comptime is kind of LISP's unique feature, it's just called macros. EDIT: In fairness, Zig's presentation is pretty likeable. You can do a comptime expression pretty trivially in LISP, a comptime parameter or block would require actual effort.

No. There is a real difference between staged computation of the type that zig has and macros in common lisp, scheme/rust have (so much for lisp's uniqueness BTW). In common lisp you can do completely arbitrary computation at compile- (or read-)time in zig you cannot and crucially you are also not responsible for manually ordering the "stages". E.g. in common lisp you have use eval-when to make sure that stuff is available at the right phase, whereas zig works out the dependency for you.
Post reply on HN