3 ms·

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 knowled

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 written codebase and disregard for proper, complete documentation. "Because you can just read and understand the code", yeah I can do the same in well maintained code of a faster language.

skulk 6y ago
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" (though I have no idea whether please fulfills this)
- damnyou 6y ago
  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 milliseconds and 500 is large, and the difference between 10ms and 100 is enormous.
  - matheusmoreira 6y ago
    > 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.
- tomlu 6y ago
  My full time job was to make Bazel more efficient for about 1.5 years. The answer is: it really depends. If you are executing 100,000 novel parallel C++ actions, then compilation for that might be I/O bound? If these actions are all cached though you would likely be CPU bound instead, as the build system works hard to discover that all the work is already done.
hobofan 6y ago
> 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.
- eeZah7Ux 6y ago
  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.
  - xyzzy123 6y ago
    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.
  - jrockway 6y ago
    > 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.
higerordermap 6y ago
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.
dang 6y ago
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 https://news.ycombinator.com/newsguidelines.html We detached this subthread from https://news.ycombinator.com/item?id=25240535 https://news.ycombinator.com/item?id=25240535.

skulk 6y ago

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" (though I have no idea whether please fulfills this)

damnyou 6y ago
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 milliseconds and 500 is large, and the difference between 10ms and 100 is enormous.
- matheusmoreira 6y ago
  > 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.
tomlu 6y ago
My full time job was to make Bazel more efficient for about 1.5 years. The answer is: it really depends. If you are executing 100,000 novel parallel C++ actions, then compilation for that might be I/O bound? If these actions are all cached though you would likely be CPU bound instead, as the build system works hard to discover that all the work is already done.

hobofan 6y ago

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

eeZah7Ux 6y ago
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.
- xyzzy123 6y ago
  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.
- jrockway 6y ago
  > 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.

higerordermap 6y ago

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.

dang 6y ago

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 https://news.ycombinator.com/newsguidelines.html We detached this subthread from https://news.ycombinator.com/item?id=25240535 https://news.ycombinator.com/item?id=25240535.