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

Type resolution redesign, with language changes to taste

ziglang.org

Post reply on HN
Print view View original

241–250 of 284 posts

Re: Type resolution redesign, with language changes to taste

#241

Post by thezipcreator »

CyberDildonics wrote: post #226
gf000 wrote: post #220

Earlier quoted context omitted.

But even the solutions would be so trivial - have a separate 'prod' compiler flag. With that, make these errors, without make these warnings. Problem solved, everyone happy.

You are right of course, the solution is trivial. They also made a carriage return crash the compiler so it wouldn't work with any default text files on windows, then they blamed the users for using windows (and their windows version of the compiler!). It's not exactly logic land, there is a lot of dogma and ideology instead of pragmatism. Some people would even reply how they were glad it made life difficult for win…

I'm not sure why you shouldn't make your compiler accept CRs (weird design decision), but fixing it on the user-side isn't exactly hard either. I don't know an editor that doesn't have an option for using LF vs CRLF.

The unused variable warning is legitimately really annoying though and has me inserting `_ = x;` all over the place and then forgetting to delete it, which is imo way worse than just... having it be a warning.

Re: Type resolution redesign, with language changes to taste

#242

Post by thezipcreator »

CyberDildonics wrote: post #155
weebull wrote: post #72

Earlier quoted context omitted.

Two different philosophical approaches with Zig and Rust. - Zig: Let's have a simple language with as few footguns as possible and make good code easy to write. However we value explicitness and allow the developer to do anything they need to do. C interoperability is a primary feature that is always available. We have run time checks for as many areas of undetermined behaviour as we can. - Rust: let's make the compi…

as few footguns as possible There are no destructors so all the memory ownership footguns are still there.

sure, but when I've written zig this has never been an issue for me. `defer` makes memory management really easy.

If you want to auto-generate destructors, zig has really good comptime features that can let you do that.

Re: Type resolution redesign, with language changes to taste

#243

Post by thezipcreator »

cultab wrote: post #77
bsaul wrote: post #75

Earlier quoted context omitted.

i wonder what makes go more modern than java, in terms of features.

The tooling and dependency management probably

I still don't understand how they managed to make a build system as bad as Gradle. It's like they tried to make it as horrible as possible to use.

Re: Type resolution redesign, with language changes to taste

#244

Post by MrResearcher »

h4ch1 wrote: post #2

I would really like to hear from people using Zig in production/semi-serious applications; where software stability is important. How's your experience with the constantly changing language? How're your update/rewrite cycles looking like? Are there cases where packages you may use fall behind the language? I know Bun's using zig to a degree of success, was wondering how the rest were doing.

Running a ~20Kloc 0.16 Zig in prod, compiled and deployed as DebugSafe. No issues, superstable. This was rewrite of Node.js/Typescript computation module, and we chose Zig over Rust due to better support for f128. Zig/DebugSafe is approximately twice faster than TypeScript/Node.js 25 for our purpose, with approximately 70% less memory consumption. We were not impacted by WriterGate and other recent scandals much because we primarily rely on libc, and we don't use much of Zig's I/O standard lib.

Zig has a better support for sqlite/JSON serialization (everything is strongly typed and validated) than Node.js, so that was a plus as well.

Zig minuses are well known: lack of syntax sugar for closures/lambdas/vtable, which makes it hard to isolate layers of code for independent development.

We use Arcs (atomic reference counting) with resource scopes (bumper allocators) extensively, so memory safety is not a concern despite aggressively multithreading logic. The default allocator automatically detects memory leaks, use-after-free, etc so we are planning to continue running it in DebugSafe indefinitely. We tried switching to ReleaseFast and gained about 25%, which is not that much faster to lose memory safety guarantees.

Re: Type resolution redesign, with language changes to taste

#245

Post by kristianp »

thezipcreator wrote: post #243
cultab wrote: post #77

Earlier quoted context omitted.

The tooling and dependency management probably

I still don't understand how they managed to make a build system as bad as Gradle. It's like they tried to make it as horrible as possible to use.

Yes, every time I fire up an old Android project it needs to download 500MB just for gradle upgrades. It's nuts.

Re: Type resolution redesign, with language changes to taste

#246

Post by simonask »

pjmlp wrote: post #223
estebank wrote: post #194

Earlier quoted context omitted.

If you define success for Rust as "everything is written in Rust", then Rust will never be successful. The project also doesn't pursue success in those terms, so it is like complaining about how bad a salmon is at climbing trees.

That is however how the Rust Evangelism Strike Force does it all the time, hence these kind of remarks I tend to do. C++ is good for some things regardless of its warts due to ecosystem, and Rust is better in some other ones, like being much safer by default. Both will have to coexist in decades to come, but we have this culture that doesn't accept matches that end in a draw, it is all about being in the right tribe.

So... Like, what? Do you agree that there is no technical reason for LLVM to be written in C++ over Rust?

Have you considered that you perhaps do more damage to the conversation by having it with this hypothetical strike force instead of the people that are actually involved in the conversation? Whose feelings are you trying to protect? What hypocrisy are you trying to expose? Is the strike force with us in the room right now?

Re: Type resolution redesign, with language changes to taste

#247

Post by simonask »

dnautics wrote: post #183
simonask wrote: post #140

Earlier quoted context omitted.

"More safety than C" is an incredibly low bar. These are hygiene features, which is great, but Rust offers a paradigm shift. It's an entirely different ballpark.

negative. For example bounds checking is turned on by default in Zig, which prevents classes of overflow safety errors.

I don't think you've necessarily understood the scope and impact of the borrow checker. Bounds checking is just a sane default (hygiene), not a game changer.

Re: Type resolution redesign, with language changes to taste

#248

Post by pjmlp »

simonask wrote: post #246
pjmlp wrote: post #223

Earlier quoted context omitted.

That is however how the Rust Evangelism Strike Force does it all the time, hence these kind of remarks I tend to do. C++ is good for some things regardless of its warts due to ecosystem, and Rust is better in some other ones, like being much safer by default. Both will have to coexist in decades to come, but we have this culture that doesn't accept matches that end in a draw, it is all about being in the right tribe.

So... Like, what? Do you agree that there is no technical reason for LLVM to be written in C++ over Rust? Have you considered that you perhaps do more damage to the conversation by having it with this hypothetical strike force instead of the people that are actually involved in the conversation? Whose feelings are you trying to protect? What hypocrisy are you trying to expose? Is the strike force with us in the room…

I assert there is no reason to rewrite LLVM in Rust.

And I also assert that the speech that Rust is going to take over the C++, misses on that as long as Rust depends on LLVM for its existence.

Or ignoring that for the time being NVidia, Intel, AMD, XBox, PlayStation, Nintendo, CERN, Argonne National Laboratory and similar, hardly bother with Rust based software for what they do day to day.

They have employees on WG14, WG21, contribute to GCC/clang upstream, and so far have shown no interest in having Rust around on their SDKs or research papers.

Re: Type resolution redesign, with language changes to taste

#249

Post by simonask »

pjmlp wrote: post #248
simonask wrote: post #246

Earlier quoted context omitted.

So... Like, what? Do you agree that there is no technical reason for LLVM to be written in C++ over Rust? Have you considered that you perhaps do more damage to the conversation by having it with this hypothetical strike force instead of the people that are actually involved in the conversation? Whose feelings are you trying to protect? What hypocrisy are you trying to expose? Is the strike force with us in the room…

I assert there is no reason to rewrite LLVM in Rust. And I also assert that the speech that Rust is going to take over the C++, misses on that as long as Rust depends on LLVM for its existence. Or ignoring that for the time being NVidia, Intel, AMD, XBox, PlayStation, Nintendo, CERN, Argonne National Laboratory and similar, hardly bother with Rust based software for what they do day to day. They have employees on WG1…

> I assert there is no reason to rewrite LLVM in Rust.

Everybody agrees with that, though? Including the people writing rustc.

There's a space for a different thing that does codegen differently (e.g. Cranelift), but that's neither here nor there.

> And I also assert that the speech that Rust is going to take over the C++, misses on that as long as Rust depends on LLVM for its existence.

There's a huge difference between "Rust depends on LLVM because you couldn't write LLVM in Rust [so we still need C++]" and then "Rust depends on LLVM because LLVM is pretty good". The former is false, the latter is true. Rust is perfectly suited for writing LLVM's eventual replacement, but that's a massive undertaking with very little real value right now.

Rust is young and arguably incomplete for certain use cases, and it'll take a while to mature enough too meet all use cases of C++, but that will happen long before very large institutions are also able to migrate their very large C++ code bases and expertise. This is a multi-decade process.

Re: Type resolution redesign, with language changes to taste

#250

Post by jibal »

jhatemyjob wrote: post #208
8n4vidtmkvmk wrote: post #33

Earlier quoted context omitted.

This seems unnecessarily hostile. They are asking. Here.

It seems hostile to you, but surely you can see what he's replying to is way more hostile and passive aggressive?

Yes, seems clear, right? It was an extremely hostile pompous criticism of something he didn't understand at all, and the questions were rhetorical, not asked sincerely or in good faith:

> Is this a “this dev” thing, a Zig thing, or am just out of touch with modern language (or even larger scale development) projects?

No, none of those, it's him making numerous rash assumptions.

But my snarky post was probably poor judgment on my part. I won't be commenting further.

Post reply on HN