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

Maintain It with Zig

kristoff.it

Post reply on HN
Print view View original

201–210 of 286 posts

Re: Maintain It with Zig

#201

Post by zamadatix »

kristoff_it wrote: post #171
zamadatix wrote: post #168

Earlier quoted context omitted.

One could say the same thing about Rust, and at least that language has hit 1.0.

It's not just a random remark, the self-hosted implementation of the compiler which is being worked on as we speak (type?) has multiple backends, one being the C backend which will be used to simplify the bootstrap process of Zig.

Agreed, and Rust folks have been working on a gcc backend to get off the llvm monoculture too.

As much as I lean on thinking Zig will achieve it first it seems unfair to make claims about things that haven't been done in a language that hasn't even been finalized as reasons it's better than a stable language in the same boat at the moment.

Re: Maintain It with Zig

#202

Post by azakai »

pjmlp wrote: post #33

Until Zig fixes the issues with use after free, it is hardly an improvement.

I'm not close to Zig development, but in addition to the GeneralPurposeAllocator work that a comment already links to, there is other ongoing stuff in that space, like an allocator in 64-bit that does not reuse pages (and instead keeps using new addresses in the "infinite" 64-bit space).

There are also known techniques like Type-After-Type that can avoid use-after free in C and C++ [0]. And also advances in hardware like ARM MTE [1]. Those things - and GPA, and not reusing 64-bit pages - have various tradeoffs in terms of overhead, but Zig is a developing language that has a chance to explore possibilities that C and C++ can't. So this is an interesting area to follow.

[0] https://dl.acm.org/doi/10.1145/3274694.3274705 [1] https://security.googleblog.com/2019/08/adopting-arm-memory-...

Re: Maintain It with Zig

#203

Post by AndyKelley »

kllrnohj wrote: post #170
steveklabnik wrote: post #149

Earlier quoted context omitted.

You care because you need to have a c compiler installed, as well as the libc stuff… It is a giant pain to do so in some circumstances. One less dependency is a good thing. I quoted from cc’s readme above.

100% of platforms that Zig & Rust run on already have a C compiler installed, though. A c compiler being present is the baseline assumption. If Zig existed in places C doesn't and I wanted to write C for that platform then having Zig CC would be an advantage. But such a situation doesn't currently exist and seems unlikely to ever exist? Especially in the context of a library/module porting to Zig or Rust piecemeal, t…

You might not be aware that Zig runs perfectly fine on Microsoft Windows, without MSVC installed. Consider also that installing Zig on Windows is a matter of unpacking a 40 MiB .zip file, whereas installing MSVC on Windows requires downloading something like 8 GiB, being an administrator (!!), and restarting the computer twice.

Re: Maintain It with Zig

#204

Post by pryelluw »

pryelluw wrote: post #173
AndyKelley wrote: post #120

Earlier quoted context omitted.

> Let's hope this is not vaporware. I sincerely approve of the skepticism. I can assure you there is already a very large fire under my ass to get this shipped. To provide some more context, here is a snippet from the latest release notes[0]: > Having a package manager built into the Zig compiler is a long-anticipated feature. Zig 0.8.0 does not have this feature. > If the package manager works well, people will use…

How can I help?

There’s this helpful guide:

https://github.com/ziglang/zig/blob/master/CONTRIBUTING.md

Though I’m interested in hearing from the creator itself as well.

Re: Maintain It with Zig

#205

Post by tialaramex »

Ar-Curunir wrote: post #89
mumblemumble wrote: post #68

Earlier quoted context omitted.

Not sure at all - I have effectively zero working knowledge of Rust - and certainly not looking to second-guess people's motivations for using the feature. The big bias I'm working from here is that, as an outsider, I have a hard time reconciling all the big talk about how Rust makes it impossible to experience certain classes of bugs, with the existence of a known set of things that its type checker can't check, and…

No type checker can catch all buggy programs (that involve solving the halting problem). In practice, Rust strikes a good balance: in over 120,000 LoC of Rust code that I have helped write and maintain, we have maybe 10 lines of unsafe, with performance matching or exceeding that of the C/C++ counterparts.

> No type checker can catch all buggy programs (that involve solving the halting problem).

It's far worse than that, the problem is that the machine can't know what was intended. The result 5 from calling sum([1,2,1,1]) makes sense, but alas this function was intended to produce the product not the sum, the inputs were supposed to be [1,2,3,4] and the desired result was 24... the machine can't hope to guess that.

A program may be buggy even if it its meaning is transparent and exactly reflects its effect, simply because it doesn't reflect the intention of the person who wrote the wrong program.

This quote is attributed to Babbage:

'On two occasions I have been asked, – "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question'

But that is what we wanted, even if we obviously can't have it.

Re: Maintain It with Zig

#206

Post by AndyKelley »

ndesaulniers wrote: post #158

Replacing lld rather than add macho support send like a mistake.

LLD is written in C++ and depends on LLVM (a massive C++ library). Zig's self-hosted linker has no C++ or LLVM dependency. One of the features of a compiler is how short the bootstrapping path is. C++ as part of the bootstrapping process is a failure of sorts.

Furthermore, LLD doesn't support incremental compilation. It's just not fast enough for our compilation performance goals.

Re: Maintain It with Zig

#207

Post by dnautics »

nyanpasu64 wrote: post #199
moogly wrote: post #182

Earlier quoted context omitted.

I wouldn't use the word "require", and perhaps you didn't mean it that strongly. Don't get me wrong: I could get by without and achieve what I needed to, but to be honest it didn't feel great. I was doing some pretty gnarly high-level filesystem work (transforming an unstructured tree of files/folders into a more structured tree following certain naming and categorization conventions -- a lot of parsing/building/conc…

Keep in mind that filesystem paths aren't strings. On Linux, they are raw bytes without any fixed encoding (but usually UTF-8 on UTF-8-based locales), and on Windows, they are sequences of 16-bit codepoints which are expected to be UTF-16 but not validated. Rust's OsStr is my favorite approach so far. It stores Linux's raw bytes as-is, and stores Windows's possibly-valid UTF-16 as WTF-8. This makes path management "j…

MacOS filesystem is utf-8 strings with valid Unicode glyphs that are pinned to a certain revision of Unicode.

Re: Maintain It with Zig

#208

Post by IggleSniggle »

abledon wrote: post #96
nrclark wrote: post #15

Earlier quoted context omitted.

I think that's correct with some overlap, yes. Zig's explicit goal - as stated by the creator - is to replace C. Nothing more, nothing less. I feel like Rust wants to replace C but it also wants to replace C++. And given the complexity difference between the two languages, that means that Rust will end up closer to C++ than to C. So there's some overlap based on how Rust positions itself, but not based on how Zig pos…

We already have c/c++ as low level bases, now zig/rust are coming for the throne, I really hope contenders dont keep spawning like rabbits. If everyone got behind a smaller # of initiatives the worlds codebase would be simpler going forward? I'm imaging some poor software engineer in 2065, having to maintain an enterprise legacy stack... levels of FORTRAN/COBOL->C->C++->ZIG->RUST->PERL->PYTHON.... all the way up....J…

While I would absolutely love to have that job, I’m afraid I’ll never get to do it. Language cross-compilers seem to keep getting better. It may be that case that one day, you will run a legacy program through a babelfish and get something understandable to you back out.

Of course, the complexity might explode from there…or you might just not really notice it all that often. Anybody familiar with LLVM or WASM or heck even a language that can transpile to JavaScript can probably relate to this possibility.

The thing that’s harder to fathom is going from low-level to high-level. High-level -> intermediary low-level -> high-level is fathomable though.

Re: Maintain It with Zig

#209

Post by ksec »

hitekker wrote: post #43
steveklabnik wrote: post #24

Earlier quoted context omitted.

It is a weird self-fulfilling thing. People talk about it like it's a thing, so it's a thing, even if there's very little actual evidence of anyone sincerely holding this belief. People repeat that there's this plague of folks requesting that projects be re-written, and while it is literally true that I have seen two or three instances of this (you link to one of them, and notably it is not anyone harassing maintaine…

As a counterpoint, I remember when someone satirized RIIR on HN and the post was flagged into oblivion even though the comments section was mostly approving. https://news.ycombinator.com/item?id=25198571 Someone reposted the same document with Rust replaced with "$hotlang" which, for a reason you can guess, wasn't flagged at all: https://news.ycombinator.com/item?id=25208313 My impression is that there are more than…

It is with people who support Rust ( enthusiast ), but not (most) Rust developers. And it isn't just Github, but literally everywhere from Twitter, Reddit, HN to many other social media. That is why you get the upvote / downvote, and where you get the question Why are you not writing / rewriting it with Rust? And it isn't just about Rust itself, all other programming languages topic will always end up having rust in the comments.

They call this evangelist.

Re: Maintain It with Zig

#210

Post by shp0ngle »

You replace the pipeline from GCC/LLVM to Zig. But the codebase is still in C and therefore has all the negative properties (memory unsafety, undefined behaviour), so what did you gain?
Post reply on HN