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

141–150 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#141

Post by selfmodruntime »

sacado2 wrote: post #73
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…

> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds. Put everything you don't want to manage into Rcs, RefCells, Boxes and the like, and you'll more or less feel like you're using a (verbose) GCed language (with a loss of performance and safety as a natural consequence). > I enjoy Rust and have been writ…

RefCells and Boxes just throw the same errors at runtime instead of compile time.

Re: Assorted Thoughts on Zig and Rust

#142

Post by pron »

mwcampbell wrote: post #138
pron wrote: post #67

> As long as all unsafe code obeys the aliasing and lifetime rules, rust protects completely against UAF. Zig has little protection. ... now. The goal is to have full protection against UAF (in safe-mode only, of course).

> (in safe-mode only, of course) Then it seems to me that Rust still has an advantage, in that it offers full protection of UAF with zero runtime overhead.

That's like saying that a helicopter clearly has the advantage over a car in that it can fly. True, that's an advantage, but you don't get to just pick the advantages -- they come in a package. That package is better overall only if the advantage comes at no additional cost and has no associated downsides. I, for one, think Rust's advantages comes with a hefty price tag, and can have negative effects even on correctness compared to Zig. However, it's hard to intuit which of the approaches is better for correctness; only time and empirical observation will tell.

Re: Assorted Thoughts on Zig and Rust

#143

Post by [deleted] »

steveklabnik wrote: post #99
mumblemumble wrote: post #97

Earlier quoted context omitted.

> 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 developmen…

[deleted]

Re: Assorted Thoughts on Zig and Rust

#144

Post by _u9xp »

gameswithgo wrote: post #124
_u9xp wrote: post #121

Zig has very little focus on safety and has had several regressions related to security and correctness, most of which Andrew has said he doesn't care about as much. This concerns me greatly. The discord community operates like a cult (sound familiar, Rust community?) and any criticisms or anything not exuberantly positive results in a flame war. I saw all of that happen several times so far with the community and it…

Every language has overzealous fans, when a language is new this is likely a largely percentage of the community. If you use that as a reason to avoid a language you will likely just end up avoiding new languages.

See my other comment. It's more the fact Andrew stepped into the conversation himself and just said "be nice" instead of addressing security concerns, just fueling the flame war even more.

A response to a security concern should never be "fuck off".

Re: Assorted Thoughts on Zig and Rust

#145

Post by vips7L »

CyberRabbi wrote: post #129
_u9xp wrote: post #121

Zig has very little focus on safety and has had several regressions related to security and correctness, most of which Andrew has said he doesn't care about as much. This concerns me greatly. The discord community operates like a cult (sound familiar, Rust community?) and any criticisms or anything not exuberantly positive results in a flame war. I saw all of that happen several times so far with the community and it…

No offense intended at all but I had a similar experience with the zig community.

I had the opposite experience. They were welcoming and helped me solve some very off the beaten path issues.

Re: Assorted Thoughts on Zig and Rust

#146

Post by _u9xp »

vips7L wrote: post #145
CyberRabbi wrote: post #129

Earlier quoted context omitted.

No offense intended at all but I had a similar experience with the zig community.

I had the opposite experience. They were welcoming and helped me solve some very off the beaten path issues.

They're fine if you don't bring up criticisms. God help your soul if you do.

Re: Assorted Thoughts on Zig and Rust

#147

Post by dnautics »

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…

I don't think that people complain about Go's simplicity. People complain about the hamfistedness of Go's simplicity. The downstream effects of it include, for example the wat that you handle JSON in Go.

But there are a lot of quite frankly crazy choices, like making (milliseconds) an integer type that is incompatible with numbers. This means to multiply an time with a non-constant integer, you have to cast an integer to millisecond type first, then multiply. Which breaks the brain of a scientist like me and makes me want to throw my computer out the window.

My daily driver is Elixir, and it's not impossible to jump into totally foreign code and debug it. In fact, just the other day I did an interview where the 20 minute technical problem was drilling down from the frontend into the backend of a new-to-me system and finding the logic bug in a database query that was causing the wrong data to be surfaced.

Re: Assorted Thoughts on Zig and Rust

#148

Post by dna_polymerase »

drcode wrote: post #126
_u9xp wrote: post #121

Zig has very little focus on safety and has had several regressions related to security and correctness, most of which Andrew has said he doesn't care about as much. This concerns me greatly. The discord community operates like a cult (sound familiar, Rust community?) and any criticisms or anything not exuberantly positive results in a flame war. I saw all of that happen several times so far with the community and it…

Any new language project in 2020, for good or ill, is going to be highly opinionated and self-select for people who share similar views on language design. When someone comes along on their discord and says "you need to have this security and correctness issue that I care about deeply fixed yesterday" you really can't be surprised if not everyone shares your urgency- There are probably other languages/communities tha…

Yes, a bit of tribalism seems to be ingrained in every online community these days. That clashes with a lot of people having pretty high expectations for code provided for free to them.

Re: Assorted Thoughts on Zig and Rust

#149

Post by steveklabnik »

selfmodruntime wrote: post #141
sacado2 wrote: post #73

Earlier quoted context omitted.

> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds. Put everything you don't want to manage into Rcs, RefCells, Boxes and the like, and you'll more or less feel like you're using a (verbose) GCed language (with a loss of performance and safety as a natural consequence). > I enjoy Rust and have been writ…

RefCells and Boxes just throw the same errors at runtime instead of compile time.

(RefCell yes, but box no)

Re: Assorted Thoughts on Zig and Rust

#150

Post by rhodysurf »

martinhath wrote: post #65
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…

> Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the need for macros emerges by itself, then learning them is a natural part of the process. But even then, nobody is forced to write any. Macros in Rust aren't only confusing for beginners, because it has a completely different syntax (well, at least macro_rules! does; idk about proc macros) than the one you use fo…

On top of that... you have to use proc macros to do any kind of annoying repetitive implementation of traits. But to do that, you have to add another crate, then you have to possibly make another crate if you want to share any code with the proc macro implementations and the actual library.

I understand why it is this way but it is very much not ergonomic

Post reply on HN