Hacker News Reader

Comment by voltagex_ | Hacker News Reader

I dunno. Maybe it's a reaction to the myriad build tools developed for Javascript recently. Could they have been done with makefiles instead?

View on HN

That was Java all over again.

- you've got dependencies on some basic Unix commands (cp, rm etc.) in your tasks, so better rewrite that all to use your cross-platform language's facilities.

- XML, erm, no, JSON, shall be your only file format.

> dependencies on coreutils

Or just install that Ubuntu on Windows thingy and be done with it.

Are there even serious developers on the Windows platform? I can't imagine many people lack the `rm` utility.

I heard a legend that even the Windows developers run some flavour of unix.

As soon as that becomes available outside the fast ring I will be spending a lot more time on Windows!

Well in fairness Java does have the excuse that the cloud, and virtual images didn't exist and it was basically a Windows world. Linux/Unix was barely known to most developers.

Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages (although I guess you could argue some of the early Linux did as well (RPM)). It is sort of interesting how Make is sort of like local dependency management.

> Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages

And Maven is still the only "package manager" I don't end up wanting to beat my head after using. For all the flak that pom.xml gets for being wordy, I know that after installing the JDK and maven all it takes is running `mvn package` and all my build plugins plus dependencies will be downloaded, installed, project compiled, tests run with whatever test runner I decided to use that year, and, assuming they passed, the project packaged up in a .jar or .war ready to be deployed.

Some more recent tools like cargo also get this right, but I don't have much of a use case for rust since the majority of my time is spend in web and desktop apps. But EVERYTHING being in one file and one tool makes getting down to business easy, there's no "make sure you run npm install before you call grunt/gulp/brocc/whatever" because maven handles it all.

Oh, as an added benefit, I don't scream about dealing with proprietary libraries like I do with .Net. The .Net SDK for our document management system has to be installed on all systems that use it via an MSI, yet the Java one is just a .jar with a couple dependencies, I whipped up a pom.xml for it in 30 seconds, pushed it to an internal maven repo and boom, done. Hell, at that point getting it packaged into an RPM (because I don't do "sprawl shit over the filesystem" deployments) took me another 3 minutes.

I pretty much agree entirely but have been too ashamed to say it :)

The build tools in Rust are incredible (given the maturity of the language). OCaml is also rapidly evolving as well (after a brief period of stagnation). I think those two languages would and probably even now make for excellent enterprise/business programming languages.

As a tech decision maker I would love to build future projects with Rust or OCaml but the cognitive load and talent needed for both those languages is higher sadly. The Ocaml build tools were a disparate mess back when I used to use it in college and for pet projects but I can honestly say there has been unbelievable strides forward.... and OCaml compiles so damn fast. I still can't believe Go users brag about compilation speed when I swear OCaml has been and still is much faster (IMO/anecdotally of course. I don't have numbers).

> I pretty much agree entirely but have been too ashamed to say it :)

I can understand that entirely, it's way too easy to get ostracized for having a positive view on Maven or Java these days.

Java as a language has warts, but thankfully there's a thriving community around the JVM and a wealth of alternate languages to pick up. Still, you can pull Maven out of my cold, dead hands.

> As a tech decision maker I would love to build future projects with Rust or OCaml

I would love to use OCaml but the lack of interfaces to a lot of tools we use really bites, so I've settled for F# (can't wait for .Net Core support). Until there's DB2 for i drivers plus Laserfiche by some miracle supporting any programming language not deemed "enterprise-grade" I'm stuck with .Net or JVM languages for a lot of things I do daily :(

I too think maven (from 2.0 onwards anyways) is awesome.

It's also declarative, BTW, which is a big improvement over Ant.

Maybe somebody should re-skin maven with a yaml based front end to attract the hipsters?

> It's also declarative, BTW, which is a big improvement over Ant.

It's an improvement over pretty much anything else except for maybe cargo and whatever that haskell build tool is (name escapes me right now). Builds are not iterative/procedural tasks in my mental model, I simply have a list of inputs and desired outputs, so I agree that the declarative model of Maven is awesome.

I absolutely hate dealing with MSBuild files, Rakefiles, grunt/gulp/whatever because they all focus on a chain of tasks in a specific order. Why should I have to tell my build system how to do its job, I told you what I want done, just do it!

> Maybe somebody should re-skin maven with a yaml based front end to attract the hipsters?

A YAML to pom.xml converter would probably be a rather simple solution to this. Honestly, I wouldn't mind it either, there's a lot of noise in pom.xml that I could do without even as someone who likes Maven.

> whatever that haskell build tool is (name escapes me right now).

I guess you mean Shake.

Cabal.

NuGet is the current way of doing packages for .NET and get the same experience as mvn package.

Not even close. Just because Visual Studio will automatically download packages from NuGet when you click 'build' before it executes MSBuild doesn't mean your build server does, or when executing a build from the command line. They are two completely independent tools with almost no integration with each other, beyond maybe stuffing an MSBuild task in to handle nuget package restore before it loads any plugins.

With Maven everything is in ONE tool, and the ENTIRE configuration for the build is contained within your pom.xml. Custom maven repositories, what build plugins need to be installed, how the build plugins are configured, project dependencies, relationships between multi-module projects, what mojos run at what phases, it's all in a single easy to read, declarative XML file. MSBuild is a giant clusterfuck compared to Maven, and it's integration with NuGet is shoddy at best.

NuGet doesn't even allow me to specify repositories on a per-project basis to this day, everything has to be specified globally. There's a LOT more configuration required to get my build server set up to build .Net apps than anything compiled with Maven.

You're right. I hope they get there eventually - NuGet has a lot of attention at the moment due to it being a critical component of .NET Core.

Solution level repositories might go some way to fixing your last issue, see https://github.com/voltagex/junkcode/blob/master/CSharp/zzCo...

> Linux/Unix was barely known to most developers.

As a personal machine maybe not, but even in the early heady days of Java, Unix deployment was the norm. I mean, what you're going to pick, one of those new-fangled NT servers or a proper IBM/Sun/HP-UX machine that has almost enough memory to run Oracle properly?

But given the "write once, run anywhere mantra", Java had something to prove, which lead to a lot ot NIH.

I suppose so. But there are always many tools for everything. And everyone can select his favorite.

The problem is if you want support (even commercial help) you'll need to follow some kind of prevailing trend. If I've got a system with grunt or gulp and I need help, I can probably find a local web developer. I'm not so sure if I can find someone who's an expert in Makefiles at the moment.

You already found at least one. Also try anyone with a degree in computer science. I'd wager it's in most first year courses; it was in 3 of mine. Also you could consult anyone who spends a lot of time working on/programming for Linux and/or in C/C++.

And it's really easy, and there's tons of literature on it on the internet. And it has a manpage.

I never encountered make in any assignment during my studies. It certainly wasn't mentioned in the lectures. At my university, you didn't learn any tooling at all, if you thought you needed it you had to teach yourself.

My professor encouraged us to learn Make but ultimately provided the file for us in every project.

Never heard of it until my 3rd company, much less using it in my first undergrad year.

if your devs can't handle learning basic make, all is lost.

yeah, makes you wonder what kind of bubbles some of these developers are living in if they see Make as some magical relic from the past.

where do you get "some magical relic from the past" from? Not knowing about something != thinking it is useless.

The "bubble" is "most people that never used C/C++" (because outside of there, make is pretty rare despite its usefulness), and even if you've used C/C++ you are not necessarily familiar enough with it to know how to properly use it or to realize you can use it as a general tool.

Why would you expect people to magically know about (and prefer to others) a tool that's almost never used in the ecosystems they touch, or only behind the scenes?

I'd wager there are a fair few Windows devs who don't know make. Granted there are few who truly understand MSBuild to make the comparison fair.

Seriously? The most used build tool in existence... and you don't think you can find someone who knows it?

...That may be the source of your problems if your devs are that inexperienced!

The main issue is that the prevailing trend in web development changes every six months. I wonder how many developers that know grunt you will find in 3 years.

I see this rhetoric being thrown around all the time, but I don't actually think its true in practice.

Grunt came out in 2011 and Gulp came out 2 years later with a superior (IMHO) code-over-convention approach. They've kinda been doing their thing since then.

Statements like seem to be nothing but FUD.

It's not about when things come out, it's when people start talking about them. I've been on an for 4 years (a relative newcomer, I know) and this is the first time I've seen either Grunt or Gulp mentioned.

So how can you be upset with the zeitgeist changing so frequently if it's taking to 4 years to hear about these widely used (in their field) tools?

On Stackoverflow, I scan down the list of questions on the first page and all I see is a myriad of questions about tools I have no idea about and, therefore, cannot help with. Most of these questions have no, or one, answer; most of which aren't helpful.

So the problem with choice is the number of people who also know that tool who can help you.

Reply on news.ycombinator.com