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

Bazel Fawlty

danmux.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Bazel Fawlty

#41

Post by merb »

Sir_Cmpwn wrote: post #17

We've been using Bazel at work, where we have a monorepo with lots of different languages at play (Python, Go, Java, Scala, JavaScript, CoffeeScript, TypeScript, Protobuf, just to name the major players) and I like that it makes all of them use a consistent interface for configuring and running builds. It helps that we have a specific team handling most of the Bazel work - and it costs about 10% of all of that team's…

> where we have a monorepo with lots of different languages

isn't that the only reason to use something like bazel? I considered using it for our go, java, scala, typescript and c# project, but I would've never used if for go only.

Re: Bazel Fawlty

#42

Post by danmux »

EtDybNuvCu wrote: post #30

Have you tried Nix? It's like Bazel, but without incremental builds. The boons are pretty great. I'm extremely disappointed, as a career SRE, to see "hope is not a strategy" trampled in the mud. I understand that perhaps the author has succumbed to epistemic helplessness and given up on having computers work without optimism or belief, but computers do not operate on any ruleset which includes hope, and we should not…

Not trampling, just holding at arms length. Recognising the reality of the economics of most projects. Unless you live in a completely deterministic world, devoid of human fallibility, or perhaps omnipotent, or simply have unlimited time or resource, at some point you are going to have to admit you just don't know, and you are managing the percentages. Delusional overconfidence is more close to magical thinking than recognising the reality that complex systems will fail in surprising ways, and that it costs ever increasing resource to reduce the risks with ever diminishing returns, until you are forced to stop. The ruleset the computer abides by probably represents a fraction of the factors affecting success. If you feel you have never got to a point where there is an element of faith involved in your choice, then Im envious.

Re: Bazel Fawlty

#43

Post by ris »

EtDybNuvCu wrote: post #30

Have you tried Nix? It's like Bazel, but without incremental builds. The boons are pretty great. I'm extremely disappointed, as a career SRE, to see "hope is not a strategy" trampled in the mud. I understand that perhaps the author has succumbed to epistemic helplessness and given up on having computers work without optimism or belief, but computers do not operate on any ruleset which includes hope, and we should not…

> Have you tried Nix? It's like Bazel, but without incremental builds.

Well, depending on how granular you expect your incremental builds to be, it can indeed have "incremental builds". Any build step that produces a derivation that ends up in the nix store will be lazily evaluated and not regenerated if its input parameters haven't changed. You could go down the route of outputting each compiled object file as a derivation...

Re: Bazel Fawlty

#44

Post by letientai299 »

venantius wrote: post #8

I have worked extensively with Bazel in the context of migrating a very large Java/Scala codebase from Gradle to Bazel. My impression is that it is a first-class build system _specifically for Java and C++_. There are specific properties of the compilation and packaging ecosystem around those languages and runtimes that make them uniquely in need of tools like Bazel. This is not true for Go, where build speed and lar…

I can speak for Java only. Most of my Java project, which are using Spring Boot and lots of libraries, gradle (previous is maven) works just fine. If there's any build issue, assume that it's not compilation issue, I just delete the `build/` and `.gradle` folders, then `./gradlew clean build` again.

I've took a hard look as bazel, for what they claim to be fast, correct, but the complicated setup and document just put me off.

Why should we consider bazel over gradle or maven for Java, or any other JVM languages?

Re: Bazel Fawlty

#45

Post by foota »

letientai299 wrote: post #44
venantius wrote: post #8

I have worked extensively with Bazel in the context of migrating a very large Java/Scala codebase from Gradle to Bazel. My impression is that it is a first-class build system _specifically for Java and C++_. There are specific properties of the compilation and packaging ecosystem around those languages and runtimes that make them uniquely in need of tools like Bazel. This is not true for Go, where build speed and lar…

I can speak for Java only. Most of my Java project, which are using Spring Boot and lots of libraries, gradle (previous is maven) works just fine. If there's any build issue, assume that it's not compilation issue, I just delete the `build/` and `.gradle` folders, then `./gradlew clean build` again. I've took a hard look as bazel, for what they claim to be fast, correct, but the complicated setup and document just pu…

I don't really view bazel as being that complicated to set up, what makes you think that?

Re: Bazel Fawlty

#46

Post by EtDybNuvCu »

danmux wrote: post #42
EtDybNuvCu wrote: post #30

Have you tried Nix? It's like Bazel, but without incremental builds. The boons are pretty great. I'm extremely disappointed, as a career SRE, to see "hope is not a strategy" trampled in the mud. I understand that perhaps the author has succumbed to epistemic helplessness and given up on having computers work without optimism or belief, but computers do not operate on any ruleset which includes hope, and we should not…

Not trampling, just holding at arms length. Recognising the reality of the economics of most projects. Unless you live in a completely deterministic world, devoid of human fallibility, or perhaps omnipotent, or simply have unlimited time or resource, at some point you are going to have to admit you just don't know, and you are managing the percentages. Delusional overconfidence is more close to magical thinking than…

Thank you for your thoughtful reply; you deserve a serious answer.

I accept that, occasionally, my systems will fail. My data will be lost. No recovery will be possible, and the damage will be permanent and lasting. I do not hope to succeed in those times, but expect to be scarred. I will fail.

Given that I will fail, I'd like to understand how I fail. I'd like to understand why I fail. I'd like to measure how often I fail, how short I fall of success, and the root causes of my failure. I'd like to know when failure is about to happen or is happening.

By writing down what I do, I know how to fail. I can write down what I do when I don't fail, too. I can write while I do, and I can read what I wrote to do it again. I can let somebody else read and do what I have done.

I can expect to fail sometimes. I can expect to not fail sometimes. I expect failures based on causes, not based on self-blame. I expect to not fail most of the time, and only fail at certain times when something has caused me to fail.

I can fail less in the future. My actions today can change how I fail in the future. I can plan to fail, or intentionally fail, or sometimes fail less. I act intentionally.

I haven't failed in a while. The last time I failed, I looked at why I failed and I did what was necessary to try to recover and fail less.

This is how SRE works. This isn't overconfidence; this is fault-tolerance. It's not easy, but it works.

To respond to your point about faith, I have plenty of faith, just not hope that my faith will be able to prevent me from failing.

And finally, try Nix sometime. It's pretty cool.

Re: Bazel Fawlty

#47

Post by jkaplowitz »

mkobit wrote: post #40
Aissen wrote: post #36

Earlier quoted context omitted.

See https://youtu.be/gHdTzdXkhRY?t=8m4s for a list of high-profile projects that have moved or are moving to meson. While my parent comment is over-simplifying, the talk goes into more details on the strengths of Meson. Also, I'm not saying there's no open-source community around JVM-based projects. Just that adding it as a dependency is a very expensive decision to make. Python3 is pre-installed in major distros (e.…

I wasn't aware that Python3 was pre-installed on major distros, I don't believe it was by default on my Ubuntu 16.04. It is possibly I removed it, though. It does look like 18.04 is going to bundle Python 3 [1]. I agree with you that adding JVM is an expensive decision and the runtime requirements can make using them in real projects a big pain. Thanks for the video, I'll check it out. It is exciting (and I would als…

2018 and 2019 is when you'll start to see all the distros with an enterprise support lifecycle (RHEL, Debian, Ubuntu LTS, SLES, probably others I'm forgetting) start to move more heavily to Python 3, since Python 2's EOL is in 2020. As your link notes, Ubuntu and Debian are trying to make their next long-term supported stable releases use 3.x as the default Python.

Looking to the following iteration, any distro releasing in 2020 with Python 2.7 as default and a support lifecycle greater than 6-9 months, doing so after 2020 regardless of lifecycle, will be irresponsible. I doubt any of the major ones will overlook this, not even those which target hobbyists instead of enterprises.

(Disclaimer: While I am a Debian developer, I have no personal involvement in this transition for Debian or any other distro.)

Re: Bazel Fawlty

#48

Post by danmux »

EtDybNuvCu wrote: post #46
danmux wrote: post #42

Earlier quoted context omitted.

Not trampling, just holding at arms length. Recognising the reality of the economics of most projects. Unless you live in a completely deterministic world, devoid of human fallibility, or perhaps omnipotent, or simply have unlimited time or resource, at some point you are going to have to admit you just don't know, and you are managing the percentages. Delusional overconfidence is more close to magical thinking than…

Thank you for your thoughtful reply; you deserve a serious answer. I accept that, occasionally, my systems will fail. My data will be lost. No recovery will be possible, and the damage will be permanent and lasting. I do not hope to succeed in those times, but expect to be scarred. I will fail. Given that I will fail, I'd like to understand how I fail. I'd like to understand why I fail. I'd like to measure how often…

Good points well made. I hope I'll be able to prioritise trying Nix at some point.

Re: Bazel Fawlty

#49

Post by venantius »

letientai299 wrote: post #44
venantius wrote: post #8

I have worked extensively with Bazel in the context of migrating a very large Java/Scala codebase from Gradle to Bazel. My impression is that it is a first-class build system _specifically for Java and C++_. There are specific properties of the compilation and packaging ecosystem around those languages and runtimes that make them uniquely in need of tools like Bazel. This is not true for Go, where build speed and lar…

I can speak for Java only. Most of my Java project, which are using Spring Boot and lots of libraries, gradle (previous is maven) works just fine. If there's any build issue, assume that it's not compilation issue, I just delete the `build/` and `.gradle` folders, then `./gradlew clean build` again. I've took a hard look as bazel, for what they claim to be fast, correct, but the complicated setup and document just pu…

Your comment makes it sound like you don't run your build process in a continuous integration environment.

Re: Bazel Fawlty

#50

Post by benley »

ris wrote: post #43
EtDybNuvCu wrote: post #30

Have you tried Nix? It's like Bazel, but without incremental builds. The boons are pretty great. I'm extremely disappointed, as a career SRE, to see "hope is not a strategy" trampled in the mud. I understand that perhaps the author has succumbed to epistemic helplessness and given up on having computers work without optimism or belief, but computers do not operate on any ruleset which includes hope, and we should not…

> Have you tried Nix? It's like Bazel, but without incremental builds. Well, depending on how granular you expect your incremental builds to be, it can indeed have "incremental builds". Any build step that produces a derivation that ends up in the nix store will be lazily evaluated and not regenerated if its input parameters haven't changed. You could go down the route of outputting each compiled object file as a der…

> You could go down the route of outputting each compiled object file as a derivation...

You could, but I believe you would find that Nix becomes pretty inefficient in that scenario. There is a surprising amount of overhead involved in setup/teardown of network namespaces and the other various sandbox features, and that cost is incurred for each individual derivation. It's a reasonable tradeoff for Nix when used as a package-level build sandbox, but (assuming my understanding is correct and still current) for Nix to work well as a file-level incremental build system it would require some strategic changes.

Here's the github issue with a bunch of related discussion and details: https://github.com/NixOS/nix/issues/179

Post reply on HN