Hacker News Reader

Comment by JamesSwift | Hacker News Reader

I prefer to take it one abstraction further and setup a makefile where the default `make` brings up the app. This makes it so you can rework the runtime as you see fit and nothing changes. It also doesn't require you to jump into docker immediately, and gives a good extension point for various 'helper script' workflows that you will always have.

View on HN

Makefiles are nice in theory but don't scale well to team members who don't know how to use make. If your team is full of experienced C/C++ devs then this will probably work great for you. If you are working with a bunch of android/javascript/etc developers who've never seen make, and who haven't exercised the skillset of reading through 3-decade-old email threads to find answers, you'll find that the only thing you'll do is "make" them upset.

Dont these issues also apply to the docker-compose alternative? I'm recommending make as "the one tool" to use for all of your teams apps. No matter what app they work on, everything is setup with `make bootstrap` and everything is run with `make up`. Everything is deployed with `make deploy`. They dont need to understand the _how_, only the _what_.

No, other tools do not suffer from what makes make complex. Make is "hard" because of a few things:

    1. The syntax is very complex
    2. It's just a wrapper around shell command execution
    3. There's no single standard everyone fully implements

If I implemented a makefile then I'd have to make sure it's compatible with MacOS and GNU Make. The syntax for make files and target deps are also very complex "Do I want to use % or $ or @?" Make also implements very few pieces of functionality. It forks out SHELL for most things and because of this you need to have everything your makefile is using installed on your system. If you have a makefile, invariably, someone implements some tool that's super helpful and works.... until it doesn't. It depends on some system configuration or utility that is no longer a dep of something you've manually installed and the makefile breaks. If you use containers for all of your functionality this is no longer an issue because you can vendor base layers of OSs/images and make sure they don't break. You can also test these changes, that could be breaking, without rolling out to other developers. I cannot test if my Makefile will run on a developer's mac if I don't have a mac myself and even then it's a crap shoot (do they have homebrew? is their PATH correct? etc).

> The syntax for make files and target deps are also very complex "Do I want to use % or $ or @?"

How is this any more complex than any programming language? Take javascript. Do I want to use =, ==, or ===?

> I cannot test if my Makefile will run on a developer's mac if I don't have a mac myself and even then it's a crap shoot (do they have homebrew? is their PATH correct? etc).

Containers suffer from these kinds of problems as well. For example, if your ip tables are not set up just so, you get no network access from inside your container.

C. S. Lewis taught me newness is no virtue, and oldness is no vice. I’ll leave the answer as to why I’m quoting a writer on religion in response to an anecdote on developers’ quirks about their environment as an exercise to the reader.

Yeah but if you use bare tools then it’s hard to change them and the interface may differ project to project. If you let the JS developers pick your universal build tool then they’ll want to change it annually because now the old one they loved is “terrible” and some other thing is great and is definitely the way forward. Plus then you’ll need node on every machine that needs to run the build, and probably you’ll want to lock the version and not use the one in LTS OS releases because those are too old so now all your poor non-JS developers are installing NVM and Node and a pile of other crap.

Or you can just make everyone wrap their build tools in make.

The solution here is to choose a build system that is language agnostic. The most common of these is docker & docker-compose. There's also the Blaze-likes (Pants, Buck, Bazel, Please) that let you hermetically include tools like node inside of the build chain.

Make is not a "wrapper" it's a "translucent layer on top of" since it doesn't hide the deps on the underlying tools.

When I do `docker build -t ... something` or `bazel build //something` I don't need to care if it's node, C++, Java, etc. I just need to know that it is a thing that I want to build. Make cannot deliver that to you as you need all of your system toolchains installed and you need to make sure your makefile works on every OS/system config.

> Make is not a "wrapper" it's a "translucent layer on top of" since it doesn't hide the deps on the underlying tools.

For me, that's kinda the point. If (when!) the underlying layers break, I can open up the Makefile and see exactly what was called, without too much abstraction. It's not there to provide complex build options, it's to provide aliases to the commonly used commands in a platform agnostic way.

Most of my make commands are simply aliases for one or more commands, which are often something like `docker run --rm -it project_runner_image some_command`

There's some real problems with Makefiles in the form of tabs as the prefix, running everything as a shell, weird platform specific versions, etc - but I've yet to see anything else which is as small, as universally available, with such a low barrier to entry. Most of the other options I've seen so far (and I'll be the first to admit I haven't looked very hard) seemed to either be overly complex for simple dev setups, or bound to a particular language.

Yes, you still have to make sure the underlying commands work because Make doesnt provide anything to isolate the commands. But that is also sort of my point: make is nothing but a generic task runner on top of what you are already doing. Its just about having commands and conventions that dont change depending on the underlying systems.

I agree that blaze is the better option, but all the benefits it provides comes with a greater up-front cost, where its not necessarily possible to drop-in on a project and run with. Also notable is that blaze is inspired by and is a replacement for make. So in a lot of ways, make is a poor mans blaze now.

> Makefiles are nice in theory but don't scale well to team members who don't know how to use make

Just learn it then? Running make commands is trivial. Writing basic make targets is trivial too.

Well the entire linked article and this entire thread (and all the others) could be boiled down to "Just learn [kubernetes,docker,whatever] then?" but that's not super helpful.

Not to pile on -- and I'm sure there would be exceptions -- but I've worked with some large and dynamic (employee churn) dev teams and it's always been worth it in my cases, so far, to burn a half day with new people to get them comfortable with Makefiles (and how to fix the common errors when editing them). Teams I've been on have used them for python, ruby, node, Java and Rust[1] codebases (across the years). It's definitely language-agnostic enough on its own. Oh! And the same Makefile is used in the CI/CD pipeline, to make the entire process more likely to be repeatable by our automation tools.

[1] Yes, our Makefiles sometimes call docker/npm/ant/maven/gradle/cargo under the hood. Its been worth it, in my experience. One syntax on all projects to set up the workspace, refresh dependencies, deploy to dev env, clean, etc.

> If you are working with a bunch of android/javascript/etc developers who've never seen make, and who haven't exercised the skillset of reading through 3-decade-old email threads to find answers, you'll find that the only thing you'll do is "make" them upset.

Actually I find most answers either in official documentation or on StackExchange sites. And I much prefer digging in mailing lists over digging in GitHub issues. You access both over web anyway.

Reply on news.ycombinator.com