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

Zig: All Package Management Functionality Moved from Compiler to Build System

ziglang.org

Post reply on HN
Print view View original

11–20 of 109 posts

Re: Zig: All Package Management Functionality Moved from Compiler to Build System

#11

Post by himata4113 »

forrestthewoods wrote: post #9
malkia wrote: post #7

Everytime I see a language creating their own package system, all I can think of it how much we've missed here. The only exception is C/C++, where there is none established that well, for good or bad. These choices may create later super-convoluted processes when you have to mix more than one language together. Packaging systems makes thing easy, but complicate further the line if another language needs to be used.

The world has yet to standardize on a good crossplatform polyglot build system. The only real such build systems are Buck and Bazel. But they have way too much baggage from their overlords. It’s a shame.

build systems using llvm as the backend are getting there, but zig is making their own compiler too.

Re: Zig: All Package Management Functionality Moved from Compiler to Build System

#12

Post by cornstalks »

himata4113 wrote: post #10
jswny wrote: post #8

Earlier quoted context omitted.

What’s the advantage of that for building?

sandboxing, which feels a weird way to achieve that. Although the reason for it to begin with is because builds systems can typically access raw memory and disable artificial restrictions. I think this is a bad move since the real fix to these attacks is a sandboxed environment rather than a single tool implementing sandboxing.

How would you do it, then? Sandboxing a project's build.zig via Wasm (and the various dependencies's build.zig files) seems like a great improvement to me and is how I would personally try to sandbox the build process.

Re: Zig: All Package Management Functionality Moved from Compiler to Build System

#14

Post by foltik »

ChrisGreenHeur wrote: post #5
SwellJoe wrote: post #4

Earlier quoted context omitted.

The thing about Zig in these times is that it proves that software development as a craft is not dead or replaced by LLMs. Even though I use LLMs every day, and have to admit they're remarkably good at many classes of problem, I don't want a programming language built by an LLM. Every line of code in a programming language, every decision, every trade off, matters. A vibe-designed/vibe-coded programming language woul…

Sure a human would write the language spec and the llm implement it

Such a spec would never survive contact with reality. Maybe a human could stumble their way through iterating on it with the help of an LLM, but with current models you’re going to end up with nothing but a steaming pile of garbage. Not Zig.

Re: Zig: All Package Management Functionality Moved from Compiler to Build System

#15

Post by arikrahman »

forrestthewoods wrote: post #9
malkia wrote: post #7

Everytime I see a language creating their own package system, all I can think of it how much we've missed here. The only exception is C/C++, where there is none established that well, for good or bad. These choices may create later super-convoluted processes when you have to mix more than one language together. Packaging systems makes thing easy, but complicate further the line if another language needs to be used.

The world has yet to standardize on a good crossplatform polyglot build system. The only real such build systems are Buck and Bazel. But they have way too much baggage from their overlords. It’s a shame.

Zig is pretty good for my use case. It may not be fully pollyglot at a technical level, but I can use it for my embedded C use case, for Jank to export the .cpp to other platforms, and thereby Clojure.

Re: Zig: All Package Management Functionality Moved from Compiler to Build System

#16

Post by himata4113 »

cornstalks wrote: post #12
himata4113 wrote: post #10

Earlier quoted context omitted.

sandboxing, which feels a weird way to achieve that. Although the reason for it to begin with is because builds systems can typically access raw memory and disable artificial restrictions. I think this is a bad move since the real fix to these attacks is a sandboxed environment rather than a single tool implementing sandboxing.

How would you do it, then? Sandboxing a project's build.zig via Wasm (and the various dependencies's build.zig files) seems like a great improvement to me and is how I would personally try to sandbox the build process.

Use containerized development systems: bwrap (my favorite), devcontainers.json, isolated server, anything really. You can't protect yourself against malicious vscode extensions with a zig build system sandbox.

Re: Zig: All Package Management Functionality Moved from Compiler to Build System

#17

Post by afdbcreid »

cornstalks wrote: post #12
himata4113 wrote: post #10

Earlier quoted context omitted.

sandboxing, which feels a weird way to achieve that. Although the reason for it to begin with is because builds systems can typically access raw memory and disable artificial restrictions. I think this is a bad move since the real fix to these attacks is a sandboxed environment rather than a single tool implementing sandboxing.

How would you do it, then? Sandboxing a project's build.zig via Wasm (and the various dependencies's build.zig files) seems like a great improvement to me and is how I would personally try to sandbox the build process.

I don't know what build.zig commonly does, but in Rust build.rs often does things like compiling C/C++ libraries, so you can't sandbox it with WASM (contrary to proc macros, which most of the times can be compiled to WASM and there were/are efforts for that). How does Zig fare with that?

Re: Zig: All Package Management Functionality Moved from Compiler to Build System

#18

Post by afdbcreid »

malkia wrote: post #7

Everytime I see a language creating their own package system, all I can think of it how much we've missed here. The only exception is C/C++, where there is none established that well, for good or bad. These choices may create later super-convoluted processes when you have to mix more than one language together. Packaging systems makes thing easy, but complicate further the line if another language needs to be used.

What do you think we've missed? Do you want one build systems for all languages? There are such systems (e.g. Bazel) and they're often used for multi-languages projects, but I think reality has proven that build systems with language-specific knowledge are much easier to navigate.

Re: Zig: All Package Management Functionality Moved from Compiler to Build System

#19

Post by insanitybit »

himata4113 wrote: post #10
jswny wrote: post #8

Earlier quoted context omitted.

What’s the advantage of that for building?

sandboxing, which feels a weird way to achieve that. Although the reason for it to begin with is because builds systems can typically access raw memory and disable artificial restrictions. I think this is a bad move since the real fix to these attacks is a sandboxed environment rather than a single tool implementing sandboxing.

These are not mutually exclusive, and one makes the other better. "Whole process" sandboxing has always been far worse than native sandboxing because when the devs writing the software design the software to be sandboxed they can achieve far more fine grained permissions. Similarly, "whole environment" sandboxes are the absolute worst - they're the least fine grained possible.

The benefit of "whole environment" is that if you stuff everything into that environment then anything in it is confined, but it's all confined with everything stuffed in and is sort of maximally capable. You can rarely do things are significant as, say, system call filtering, because all software in the environment must continue to work and none of it was designed with that in mind.

Native sandboxing like this will likely make auditing much easier as well. If a dependency requires something like "give me the ability to execute code on the OS", now it has to ask for it and now it gets additional scrutiny.

Native sandboxing is and always will be the infinitely superior method when it's actually used. Whole process/ Environment is only what we use because of how rare native sandboxing is.

Re: Zig: All Package Management Functionality Moved from Compiler to Build System

#20

Post by insanitybit »

afdbcreid wrote: post #17
cornstalks wrote: post #12

Earlier quoted context omitted.

How would you do it, then? Sandboxing a project's build.zig via Wasm (and the various dependencies's build.zig files) seems like a great improvement to me and is how I would personally try to sandbox the build process.

I don't know what build.zig commonly does, but in Rust build.rs often does things like compiling C/C++ libraries, so you can't sandbox it with WASM (contrary to proc macros, which most of the times can be compiled to WASM and there were/are efforts for that). How does Zig fare with that?

Even if they end up with a "this dependency can execute arbitrary code" it'll be a huge win because that will be an explicit grant to that dependency. You'll be able to know "which of my dependencies execute arbitrary code?" and encourage most of them not to. In rust, you can know this but it's going to be "basically all of my dependencies can do it" because somewhere they'll use a build script/ proc macro.

I don't know Zig's plan, but once you have the ability to broker privileges like this you have the ability to audit the privileges being brokered and things change forever.

Post reply on HN