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

91–100 of 109 posts

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

#91

Post by forrestthewoods »

himata4113 wrote: post #88
forrestthewoods wrote: post #35

Earlier quoted context omitted.

compilers and build systems are and should be different. A good polyglot build system should support llvm and zig and python and literally any toolchain under the sun.

the problem is that you need a compiler capable of compiling said zig, python, rust. LLVM does that, you can compile something as untyped as javascript(with a lot of hacks) or as strict as rust.

> the problem is that you need a compiler capable of compiling said zig, python, rust

no! No you do not!!

It’s perfectly totally fine to have multiple different compilers. Literally not a problem at all. That’s my point!

Compilers and build systems are separate. It is perfectly fine for one build system to invoke multiple different compilers.

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

#92

Post by himata4113 »

forrestthewoods wrote: post #91
himata4113 wrote: post #88

Earlier quoted context omitted.

the problem is that you need a compiler capable of compiling said zig, python, rust. LLVM does that, you can compile something as untyped as javascript(with a lot of hacks) or as strict as rust.

> the problem is that you need a compiler capable of compiling said zig, python, rust no! No you do not!! It’s perfectly totally fine to have multiple different compilers. Literally not a problem at all. That’s my point! Compilers and build systems are separate. It is perfectly fine for one build system to invoke multiple different compilers.

cargo pretty much does that, but then you have to have to bundle all those compilers which becomes a fuckfest.

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

#93

Post by forrestthewoods »

himata4113 wrote: post #92
forrestthewoods wrote: post #91

Earlier quoted context omitted.

> the problem is that you need a compiler capable of compiling said zig, python, rust no! No you do not!! It’s perfectly totally fine to have multiple different compilers. Literally not a problem at all. That’s my point! Compilers and build systems are separate. It is perfectly fine for one build system to invoke multiple different compilers.

cargo pretty much does that, but then you have to have to bundle all those compilers which becomes a fuckfest.

Ehh. Cargo has build.rs but calling that a polyglot build system is like calling bash scripts a polyglot build system.

Buck and Bazel have the right architecture. Just need a version written fresh without all the baggage.

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

#94

Post by Mawr »

chabska wrote: post #32

Zig, Go, and Python developers do this thing, where they announce that "We have removed the radiator fluid from the fuel tank", and all their supporters cheer about how this is good for the language, how performance will surely improve significantly, and I'm over here wondering why did they put the radiator fluid in the fuel tank in the first place.

> Zig, Go, and Python

If you cherry pick, any position is possible to argue for.

What is C and error handling?

What is Java and value types?

What is C++ and modules?

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

#95

Post by Mawr »

chabska wrote: post #78
MomsAVoxell wrote: post #61

Earlier quoted context omitted.

Individual developer convenience takes priority early in projects like this, in lieu of actually thinking about the consequences of the design. It was convenient to have package management in the compiler, it meant the developers didn’t have to think about things outside their own scope - but as the language and its tooling gets wider adoption these personally-beneficial features become liabilities to adoption. It ha…

I can accept this for a hobby project language that unexpectedly blew up in popularity. Go is not that language. Zig's developer also had grandiose plans for his project language, based on his writings, so I had expected more care put into its design.

You underestimate the difficulty of designing a language by at least an order of magnitude.

You've basically arbitrarily focused on a particular flawed design decision of a language while ignoring a thousand others that they may well have gotten right.

It's not possible to just sit down and get everything 100% right up front. The language design space has too much both depth and breadth to it.

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

#96

Post by Quothling »

jamiejquinn wrote: post #73
Quothling wrote: post #59

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. We've heavily adopted LLM's, to the point where I'll often not touch any code and have a better and more maintainable codebase than if it had been written by any of our developers (myself included). I'm not sure it would be possible if our philosophy wasn't explicity, no abstractions and defens…

This is an interesting approach. When you say no abstractions though, what do you actually mean? I would count functions as abstractions but do you mean classes/structs representing an object? Effectively no new types?

It depends. Ah, well I guess it's a litlle unfair to say that because in the context of your question I absolutely didn't mean for it to be taken literally and I should've been more clear. It does depend on domain though. For some of our engineering and control software it is almost meant literally. Since we'd have very few abstractions beyond the language primitives because of explicity.

For what you were asking though, it's not no-abstractions it's YAGNI where business logic lives in "just" functions which operate on plain data structures with runtime assertions and validation. The data structures will usually include domain specific types. There are no classes, object hierachies or architecture abstractions, at least, there almost never ever are. When it absolutely doesn't make sense not to introduce an abstraction beyond what we typically want, then it's allowed. This pains a lot of Uncle Bob's disciples, until it doesn't.

The advantage of it is that we've found that it works really well with LLM's. At least in my experience they seem to be absolutely excellent with explicit, localized code instead of layers of indirection.

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

#97

Post by Quothling »

pjmlp wrote: post #84
jamiejquinn wrote: post #73

Earlier quoted context omitted.

This is an interesting approach. When you say no abstractions though, what do you actually mean? I would count functions as abstractions but do you mean classes/structs representing an object? Effectively no new types?

With low code / no code systems like Power Automate, Boomi, Workato you can already do plenty of enterprise workflows without a line of code, just diagrams. Now those systems have evolved to become orchestration workflows engines with agents and tools integrations, thus several scenarios that still required proper code, have now been reduced to agent instructions. I think many in HN don't have a clue how little tradi…

I think orchestration is the perfect description. In enterprise you have a bunch of standard systems which play by their own tune, and even with a lot of the "low-code" options you're going to build systems that transfer data to the right system at the right time. Like a director of an orchestra.

Having spent a lot of time in enterprise which is not related to software development (or IT at all) I'm pretty familiar with a lot of the low / no code or Robot Process Automation systems. Which always end up requiring specialized developers, except, you can't hire software developers for them so you end up with various consultants creating huge messes. Microsoft's Cowork is the first time I've seen a system which can actually directly replace people who aren't experts in their business domain. It requires a lot less than any other system I've seen before. You need someone who has global, intune and AI admin in the Microsoft ecosystem, who know enough about software development to evaluate an app to be safe and efficient and how to debug it, and a domain expert. Then you'll have something which "just works". It's scary really.

I had no domain knowledge of PowerBI like at all, and while I could fill a data architect role, I would have never been able to do anything beyond a semantic model in Fabric and even on the semantic model it's not like I've ever worked with DAX. Yet Cowork (with read access to the Fabric workspace) could guide me through the process of creating a powerBI report set which was good enough that the business wanted to use it with a few minor improvements... Five months ago, this would have been a 2 people job. Now I was basically a puppet getting told which button to click in the report editor. If Cowork had write access it wouldn't have needed me in the loop once the data was delivered to the datalake it shortcutted to.

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

#98

Post by pjmlp »

Quothling wrote: post #97
pjmlp wrote: post #84

Earlier quoted context omitted.

With low code / no code systems like Power Automate, Boomi, Workato you can already do plenty of enterprise workflows without a line of code, just diagrams. Now those systems have evolved to become orchestration workflows engines with agents and tools integrations, thus several scenarios that still required proper code, have now been reduced to agent instructions. I think many in HN don't have a clue how little tradi…

I think orchestration is the perfect description. In enterprise you have a bunch of standard systems which play by their own tune, and even with a lot of the "low-code" options you're going to build systems that transfer data to the right system at the right time. Like a director of an orchestra. Having spent a lot of time in enterprise which is not related to software development (or IT at all) I'm pretty familiar w…

Thanks for the experience overview, those kind of experiences is what makes me evaluate that long term, some of us are lucky to slid into other roles, more architecture like, others not so sure.

For many kind of products, where selling software isn't the main business, companies will settle for approaches like that you describe, writing classical business software isn't what it used to be.

We are at the evolution of 4GLs and RUP dreams.

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

#99

Post by jamiejquinn »

Quothling wrote: post #96
jamiejquinn wrote: post #73

Earlier quoted context omitted.

This is an interesting approach. When you say no abstractions though, what do you actually mean? I would count functions as abstractions but do you mean classes/structs representing an object? Effectively no new types?

It depends. Ah, well I guess it's a litlle unfair to say that because in the context of your question I absolutely didn't mean for it to be taken literally and I should've been more clear. It does depend on domain though. For some of our engineering and control software it is almost meant literally. Since we'd have very few abstractions beyond the language primitives because of explicity. For what you were asking tho…

Right, that makes a lot of sense. Seems like reviewers can easily see and check those asserts to understand if the LLM has written something sensible (and I presume those asserts are strongly declared in the prompts).

I'd love to read a blog post or something on what you've discovered on good software patterns for AI. I'm only now getting into using LLMs and beyond the purely technical aspect of what LLM is "best" it seems like there's a wealth of learned experience in how to structure and write code to work well with them.

I've heard good arguments for using Rust with LLMs because the compiler keeps the LLM from making silly mistakes. What languages have you been developing in?

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

#100

Post by hitekker »

chabska wrote: post #78
MomsAVoxell wrote: post #61

Earlier quoted context omitted.

Individual developer convenience takes priority early in projects like this, in lieu of actually thinking about the consequences of the design. It was convenient to have package management in the compiler, it meant the developers didn’t have to think about things outside their own scope - but as the language and its tooling gets wider adoption these personally-beneficial features become liabilities to adoption. It ha…

I can accept this for a hobby project language that unexpectedly blew up in popularity. Go is not that language. Zig's developer also had grandiose plans for his project language, based on his writings, so I had expected more care put into its design.

If he had left that coupling at 1.0, I’d agree that would be careless. But he didn’t; that one expedient choice was reversed before mass adoption.

IMHO, you may be confusing “care” for legibility. The creator(s) made a choice that you disagree with and that you may not understand. They also haven’t justified or explained their choice to you. That illegibility might feel careless, even a little mean, but I reckon their focus was on figuring out the language, not seeking widespread approval.

Post reply on HN