Live data from Hacker News

Please – A cross-language build system

please.build

131–140 of 257 posts

Re: Please – A cross-language build system

#131
post #64

Earlier quoted context omitted.

A surprisingly hard sell even if your organization has a supermajority of ex-Googlers. There's a really strong meme out there that if you are smaller than Google, which is almost universally true, then you shouldn't adopt their practices even when they are zero-cost and obviously superior.

For me the "obvious" part of "obviously superior" is worth interrogating. Googlers have a very particular way of thinking of things. Which works well enough for Google, I guess. But there are a lot of ways to to good work, and not all of them are compatible.

Sure, I think thought needs to be put into any development decision. I think a new project should carefully consider, for at least several hours of research and discussion, what revision control system to use, instead of just using git without consideration of the consequences.

There are already book-length arguments that I like to refer to for specific topics, such as trunk-based development.

https://trunkbaseddevelopment.com/

Re: Please – A cross-language build system

#133
post #4
post #2

Title can possibly be modified to mention that this is a tool to build code.

> Please (please.build) 'build' kind of indicates that

> > Please (please.build)

> 'build' kind of indicates that

Not the GP, but as a developer reasonably conversant with build systems and their pain points, I still assumed this was going to be some form of lazyweb[0] related blog post or portal rather than a build system named 'Please'.

[0] https://ftrain.com/dear-lazyweb

Re: Please – A cross-language build system

#134
post #89

Earlier quoted context omitted.

Make build configurations can be difficult to understand for newcomers in the industry. If the goal is to obscure the code, by all means continue using the older tools. If the goal is continued maintenance, then encouraging new engineers to explore and read the codebase with tools they can comprehend is critical. disclaimer: have not used these particular tools, but the domain is nice and polite

I have use all of these tools and your take isn't accurate at all. Make doesn't obfuscate anything more than Plz or CMake or whatever. Here are some real reasons why Make isn't the end-all: - Make doesn't allow platform selection in a nice way. - Make doesn't work on Windows natively (no, NMake doesn't count). - Recursive make doesn't work well at all. - Make doesn't track byproducts or deleted artifacts. - Make does…

Re win32 I've had not-terrible experiences with dmake.

Re: Please – A cross-language build system

#135
post #119

> If you're familiar with Blaze / Bazel, Buck or Pants you will probably find Please very familiar Yes, so why would I use Please over any of them? I've spent close to 10min reading and have no idea why this exists or why anyone would use it. It looks like Bazel with a different config format, in which case why wouldn't one just use Bazel?

I've only used Bazel in anger (in a medium-small sized project); I've found it really frustrating because it effectively has two separate languages (inside build files and in custom rules), even though it's both Starlark. It's especially terrible for doing things that Bazel didn't already know about (i.e. running shell commands to generate things, even if you could tell Bazel all the inputs and outputs). We wanted to…

What do you mean? Genrules are very good at running she'll commands (or even entire executables).

By custom rules do you mean macros, or full on custom rules?

Re: Please – A cross-language build system

#136

> If you're familiar with Blaze / Bazel, Buck or Pants you will probably find Please very familiar Yes, so why would I use Please over any of them? I've spent close to 10min reading and have no idea why this exists or why anyone would use it. It looks like Bazel with a different config format, in which case why wouldn't one just use Bazel?

Please predates Bazel IIRC. It just didn’t gain as much traction. Please seems considerably easier to operate, but it doesn’t enjoy Bazel’s rigorous usage (although I’ve only encountered bugs when trying to use Bazel to build Python 3 projects).

Re: Please – A cross-language build system

#137

> If you're familiar with Blaze / Bazel, Buck or Pants you will probably find Please very familiar Yes, so why would I use Please over any of them? I've spent close to 10min reading and have no idea why this exists or why anyone would use it. It looks like Bazel with a different config format, in which case why wouldn't one just use Bazel?

I hate bazel with passion, I have to use it at work on really large project, and the UX is so wrong... built for google by google and my CTO thinks we can be google if we use it...

Re: Please – A cross-language build system

#138
post #97

Earlier quoted context omitted.

Why? I pragmatically use my computer with packages my distro offers me. When I download something from untrusted sources, I do take a quick look at what it is before executing it. It still is dangerous since I'm not able to spend time on verifying every single line of it, but it's up to me to decide whether that's an acceptable risk or not. All perfectly pragmatic. I'm not a kind of person who's on a crusade against…

I also read scripts from the user repositories on my distro. It’s perfectly pragmatic for us because we understand shell scripts and system administration. It makes me feel better too. But I would never tell someone to avoid installing developer tooling simply because it pipes curl to bash. It’s not pragmatic to tell a new developer they need to learn to be a sysadmin before installing homebrew.

That's a strawman though. Nobody wants to tell that to new developers. This is all about conventions and normalizing bad behaviors. New developers should avoid piping curl to bash and explicitly download files instead because when they eventually will become experienced enough to inspect those files they will start doing it naturally.

Good practices are rarely black and white, they're often there to influence how you think about stuff and what habits you develop.

Re: Please – A cross-language build system

#139
post #130

Earlier quoted context omitted.

I also was trying to figure out why I would use this over Bazel. Then I remember reading a story yesterday about how ex-googlers miss their tooling when they leave. Their CTO is an ex-googler, so maybe this is the reason.

But Bazel is developed by Google itself right now. Presumably if you missed Google tooling you'd rather use Bazel, no? I'm not suggesting Bazel is perfect: I think e.g. Starlark's insistence on being a separate language does more harm than good. (FWIW I also think the JVM objection is a little silly.) But I am saying preferring the Google tooling would ostensibly mean you like Bazel a lot already :)

I've read Bazel without the rest of Google tooling (giant monorepo of everything, distributed build farms, etc) the experience is nowhere near the same.

Re: Please – A cross-language build system

#140

> If you're familiar with Blaze / Bazel, Buck or Pants you will probably find Please very familiar Yes, so why would I use Please over any of them? I've spent close to 10min reading and have no idea why this exists or why anyone would use it. It looks like Bazel with a different config format, in which case why wouldn't one just use Bazel?

From their FAQ: >Why use Please instead of Bazel, Buck or Pants?

>All four of these systems are quite closely related in the scheme of things, being inspired by (or in Bazel's case, a direct open sourcing of) Google's Blaze.

>Several of us had worked at Google and used Blaze extensively there; we were excited about it being open sourced as Bazel but by then we were already using Please internally. It's a great system but we have slightly different goals, specifically we're aiming Please at being lighter weight and pushing the boundaries of what can be done within the BUILD language. Since Please is written in Go there's no runtime dependency on the JVM.

>We actually used Buck for some months internally before deciding to write Please and before it was capable of building our repo. We preferred it to other options available, but again we're focused on different goals; Please is easier to extend to new languages, has a bunch of features that we specifically wanted (e.g. test sandboxing) and has a stronger focus on BUILD language correctness. Conversely we have much less support for mobile development.

>We're least familiar with Pants; one of our developers briefly tried it and while we liked many aspects we didn't think it was the ideal fit for us at the time.

Post reply on HN