Live data from Hacker News

Maintain It with Zig

kristoff.it

151–160 of 286 posts

Re: Maintain It with Zig

#151
post #6

Zig is a very interesting language. You are able to do thing that would require wizard level skills in C with simple plain language construct. Like serializing/deserializing an enum variants over the wire for example in the most efficient way (look at std.json.{parser, stringify} [0]). > soon we’ll also have a package manager This. If they succeed to do this (and I have my doubts) it will be a paradigm shift for low-…

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

> Progress is swift ...

ahem

> Progress is zig ...

Thanks for all your work! I ported a bunch of basic data-structures from C++ to Zig very early on (right as y'all began exposing generics). Even though the code no longer compiles, still worth learning The Zig Way™.

Re: Maintain It with Zig

#152

I hear about zig all the time, and I'm surprised I don't more about vlang. Yet they still to target a similar audience. Is this a matter of popularity or features ?

Vlang started as a closed source project with a lot of lofty claims that fell apart quickly once the project was actually opened up. Combined with all the delays and broken delivery promises leading up to that, it gave people a poor impression of the project.

With that said, I've heard the situation has improved since then.

Re: Maintain It with Zig

#153
post #113
post #96

Earlier quoted context omitted.

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…

> 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....JS..etc.. I have good news and bad news: That programmer will not know any of those languages, as they will just program in English and GPT-3000 will convert it into code.

The reason that we have programming languages at all is that English and all other natural languages are too ambiguous to be used for this purpose.

GPT-3000 will have no problem understanding some interpretation of your English (or Spanish or Mandarin) "program", but will it be the right one? How long will it take to get GPT-3000 to understand what you mean when you can only talk to it in English (or Spanish or Mandarin) ?

Re: Maintain It with Zig

#154
post #94
post #83

Earlier quoted context omitted.

> clang cross compilation is not really any harder, you just supply the -target flag. Yes, but it doesn't bundle and automatically compile the appropriate C library for the platform. Zig does.

It can, if the package manager bundles it that way. Instead, clang is usually packaged and distributed as cross-compilation variants; because most of the time users don't need all of the different possible targets, they just want one or two.

The benefit here is that zig is batteries-included. The fact that you can drive to the store and buy batteries if you need them is missing the point.

Re: Maintain It with Zig

#156
> once you learn JS you can do [...] video games (Unity)

Not true. Unity once supported their own language based on Boo, a python dialect for the .net runtime, that they falsely advertised as "Javascript". That has since been depreciated.

Re: Maintain It with Zig

#157

Generally speaking, what killed C++/C for me is the absolute insanity that comes with it's build systems/third party dependency management. I feel like the notoriety that C++ gets for it's absurd complexity comes not from variadic template metaprogramming/rvalue references/unique_ptr or whatever, but the absolutely humongous effort needed to understand automake/CMake/autotools just to build other people's code (god f…

> the absolute insanity that comes with it's build systems/third party dependency management.

Well yes, that would kill me too, if I actually expected the language to come with a single blessed dependency that addresses functionality , that I will never want or need to patch the blessed dependency, and that there would be only one way to actually build a program or library.

But it doesn't kill me because I don't expect either of those things.

The dependency stack for my (21 year old) project consists of 86 3rd party libraries that on an x86_64 platform take up about 2GB after compilation. This is intimidating and sometimes painful, but I don't find it insane in any way. We have patches for a half-dozen of the deps that will never make it upstream and we have to be sure that we compile the libraries in the precise way that we need them (for example, we require the thread-safe version of libfftw, not the regular version).

Re: Maintain It with Zig

#160
post #121

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…

All systems programming languages need the ability to do unsafe stuff, the big difference between C , C++, Objective-C and all the remaining system programming languages since JOVIAL and NEWP, is the explicit unsafe code blocks that make that visible. It is a big difference to have it on your face that something might need to be properly double checked and having each line of code as possible security exploit.

> the big difference between C , C++, Objective-C and all the remaining system programming languages since JOVIAL and NEWP, is the explicit unsafe code blocks that make that visible.

Would you consider Oberon to belong in the former or latter category? On one hand, there's no explicit code blocks as such (syntactically). On the other hand, unsafe primitive operations are limited to the SYSTEM module, so functions calling operations in the SYSTEM module can be considered doing unsafe things.

Post reply on HN