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

Please – A cross-language build system

please.build

Post reply on HN
Print view View original

191–200 of 257 posts

Re: Please – A cross-language build system

#191

Post by matheusmoreira »

hobofan wrote: post #172
high_priest wrote: post #165

I personally despise people combining terms like "fast" or "lightweight" with languages like Go and Python. We are looking at a build system that, to my knowledge, doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human". When I see someone giving such reasons for not using a more performant language, I immediately associate such project with janky, fast writte…

> doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human" I would assume that is has the same advantage as most other Go programs: It's easily distributed as a single static binary, and doesn't need a heavy runtime to be installed.

> doesn't need a heavy runtime to be installed

Of course it does. The runtime environment just happens to be installed alongside every Go executable by virtue of being statically linked to them.

Re: Please – A cross-language build system

#192

Post by xyzzy123 »

eeZah7Ux wrote: post #180
hobofan wrote: post #172

Earlier quoted context omitted.

> doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human" I would assume that is has the same advantage as most other Go programs: It's easily distributed as a single static binary, and doesn't need a heavy runtime to be installed.

No thanks, I want my binaries to use shared objects so that an entire OS can receive quick security updates. And I want the binaries properly packaged with metadata, documentation, manpages to keep the host secure and tidy.

IMHO the ideal situation is that both distribution mechanisms are available; single file static binary and also packages for different OS's.

Which one you want to use in a given situation is contextual.

Murphy's law seems to dictate that the version of the build tool lovingly cared for by the OS's package manager is never the version you actually need.

Build tools in particular have a slightly different lifecycle to many things running on a host, which are "owned", cared for and configured by a system administrator.

Usually the project you're building "owns" the version of the build tool it needs and there's no guarantee that it will build with a different version. As a consequence, genuine build tool security issues must first be handled by the team making the tool and then by the projects depending on it when they verify compatibility.

Re: Please – A cross-language build system

#193

Post by matheusmoreira »

damnyou wrote: post #174
skulk wrote: post #171

Earlier quoted context omitted.

Are build systems typically CPU bound, even during heavy operations such as calculating dependency closure (or other things I'm unaware of)? If not, the I don't see a need to use a language that doesn't provide high level, somewhat costly, but easy to use and understand abstractions. And if it's faster than its competitors and it weighs less, then there's also nothing wrong with calling it "fast" and "lightweight" (t…

Build system performance tends to be IO-bound, but responsiveness for things like no-op builds tends to be CPU-bound -- and the JVM in particular really suffers. Optimizing IO performance makes it perform better, while optimizing CPU performance makes it feel better to use. Arguably, making tools feel better to use is more important than raw performance. When you're doing a no-op build, the difference between 100 mil…

> Optimizing IO performance makes it perform better, while optimizing CPU performance makes it feel better to use.

Optimizing I/O performance certainly makes building software feel better though. Running make on a tmpfs directory feels absolutely amazing. It feels even better on subsequent runs since Linux uses free memory to cache files.

Re: Please – A cross-language build system

#194

Post by jjice »

matheusmoreira wrote: post #191
hobofan wrote: post #172

Earlier quoted context omitted.

> doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human" I would assume that is has the same advantage as most other Go programs: It's easily distributed as a single static binary, and doesn't need a heavy runtime to be installed.

> doesn't need a heavy runtime to be installed Of course it does. The runtime environment just happens to be installed alongside every Go executable by virtue of being statically linked to them.

I think hobofan means that the Go runtime is lightweight when it comes to runtimes.

Re: Please – A cross-language build system

#195

Post by jrockway »

eeZah7Ux wrote: post #180
hobofan wrote: post #172

Earlier quoted context omitted.

> doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human" I would assume that is has the same advantage as most other Go programs: It's easily distributed as a single static binary, and doesn't need a heavy runtime to be installed.

No thanks, I want my binaries to use shared objects so that an entire OS can receive quick security updates. And I want the binaries properly packaged with metadata, documentation, manpages to keep the host secure and tidy.

> I want my binaries to use shared objects so that an entire OS can receive quick security updates.

Have shared libraries historically improved security much? Debian helpfully "updated" OpenSSL, and thanks to the magic of shared libraries, every program on a Debian system generated weak keys.

Personally, I don't think there's enough software on the average filesystem image to justify sharing libraries. Most stuff "in production" these days is in a container, which shares nothing with the other containers running on the same VM, which share nothing with the other VMs running on the same bare metal server. In the case of containers, a full rebuild from source is just as easy as updating a shared library -- maybe even easier. So the "quick security updates" doesn't seem to justify the high maintainability cost of shared libraries. (The high cost is having to maintain binary compatibility with applications you've never even seen before.)

The whole reason things like "Linux distributions" exist is for some central authority to coordinate and handle all the breakages this model causes. It's nice that they do it for us, but it's kind of makework to save a few bytes of network transfer now and again. Doesn't seem worth it to me.

> I want the binaries properly packaged with metadata, documentation, manpages to keep the host secure and tidy.

You've just invented containers. Many other people agree with you, which is why they became so popular.

Re: Please – A cross-language build system

#196

Post by jrockway »

dblotsky wrote: post #141

How big does the project have to be in order for this system to have benefits over Make?

The problem with Make is that it doesn't know what it's building, so it can't do anything smart. For incremental builds to work at all, you have to supply the smarts. Having worked on a number of make-based projects (I am most scarred by buildroot), I can tell you that people make mistakes with build rules. The project then devolves to doing a clean build for every change, turning what could be a few milliseconds of CPU time into a 30 minute rebuild.

The idea of these build systems like Bazel is that the rules are correct so that you don't have to worry about writing correct rules, and you have a high probability of an incremental build producing a binary that's bit-for-bit identical to one from a full build. The result is that you don't do full builds anymore, and save the latency of waiting for things to build. (That latency shows up in the edit-build-test cycle, how long it takes to deploy software to production to fix an emergency bug, etc. So it's important!)

Re: Please – A cross-language build system

#197

Post by higerordermap »

high_priest wrote: post #165

I personally despise people combining terms like "fast" or "lightweight" with languages like Go and Python. We are looking at a build system that, to my knowledge, doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human". When I see someone giving such reasons for not using a more performant language, I immediately associate such project with janky, fast writte…

Go is pretty fast, within factor of 2 compared to C/C++.

Python is another thing. Most CLI utilities written in python are unusably slow.

Re: Please – A cross-language build system

#199

Post by surajrmal »

jrockway wrote: post #195
eeZah7Ux wrote: post #180

Earlier quoted context omitted.

No thanks, I want my binaries to use shared objects so that an entire OS can receive quick security updates. And I want the binaries properly packaged with metadata, documentation, manpages to keep the host secure and tidy.

> I want my binaries to use shared objects so that an entire OS can receive quick security updates. Have shared libraries historically improved security much? Debian helpfully "updated" OpenSSL, and thanks to the magic of shared libraries, every program on a Debian system generated weak keys. Personally, I don't think there's enough software on the average filesystem image to justify sharing libraries. Most stuff "in…

I too used to take this view until I worked on a system which was on a limited storage budget of roughly 500MiB. Shared libraries go a long ways on a system like that towards making the entire thing fit. The other option was linking multiple binaries together busybox style, which also works wonders, although it forces release coupling so there are tradeoffs. Not every linux system is for desktop or server either.

Re: Please – A cross-language build system

#200

Post by dang »

high_priest wrote: post #165

I personally despise people combining terms like "fast" or "lightweight" with languages like Go and Python. We are looking at a build system that, to my knowledge, doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human". When I see someone giving such reasons for not using a more performant language, I immediately associate such project with janky, fast writte…

Please don't do programming language flamewars on HN. They're tedious and we're trying to avoid that here.

https://news.ycombinator.com/newsguidelines.html

We detached this subthread from https://news.ycombinator.com/item?id=25240535.

Post reply on HN