You're leaving out a lot when you say it'd take you "five minutes with a simple Maven/Gradle build". What's a maven? What's gradle? What's groovy and where can I learn it?

I literally don't know the answers to these questions so the same task would take me hours, possibly days. Getting from zero to JSON api in node.js is fast by comparison.

Note I am not arguing whether or not it's better in the long run to be the guy that went from zero to node.js or zero to Java, that's a separate discussion.

> You're leaving out a lot when you say it'd take you "five minutes with a simple Maven/Gradle build". What's a maven? What's gradle? What's groovy and where can I learn it?

You have similar concerns with node (What's npm? etc...) These are peripheral and necessary knowledge on both platforms.

> Getting from zero to JSON api in node.js is fast by comparison

It's only fast because you already have the knowledge.

Two equally proficient developers in Java and node will set up and get a server up and running in about the same amount of time.

The idea that it's a faster to achieve in a dynamically typed language is a myth.

> It's only fast because you already have the knowledge.

No, when I said "from zero" I meant from zero knowledge.

> You have similar concerns with node (What's npm? etc...)

What's the "etc..."? Install node and you get npm with it.

Writing a REST service IS simpler with Node when going from zero, I know because I have done (or at least attempted) both from zero in the recent past.

> The idea that it's a faster to achieve in a dynamically typed language is a myth.

Doesn't seem like you're open to discussion on this

This is a classic case of you forgetting all the learning and concepts you needed to get to "zero".

I don't think so. Npm is included with node and is very simple to use.

So your main argument is that you have to make two downloads with Java (JDK and Maven) but with Node you need to make one? Seems pretty weak.

It can't be anything else, because after you have Maven, it is literally a single command to set up a REST project using Dropwizard.

Well, to an extent this is a subjective question. With node, you get npm with it, npm is what everyone uses, and npm is clearly what you should be using too. Moreover, the basic functionality of npm is very very easy to understand.

I find the Java ecosystem terrifying by comparison. I have no idea whether Maven is what I should be using or if I should be using something else instead -- having it as a separate download makes a big difference in that regard -- and I have no idea by looking at a typical Maven config file what it does.

You should probably learn to expand your comfort zones more effectively, if the Java ecosystem terrifies you.

It's not a macho thing for me. I use the tools that are easiest to use and do the job. Anyway, I have used a lot of different programming languages, and it's the Java ecosystem specifically that I've always found overwhelming whenever I've tried to dabble with it. So I think the problem is Java, not me.

There's nothing "macho" involved in this, your language describing your own state of mind is inflammatory and (hopefully, for your sake) inaccurate.

You may need to expand your comfort zone with regard to mild hyperbole.

"Terrifying? What if something REALLY happens to you? You used 'terrifying' on the Java ecosystem!"[1]

[1]: http://zenpencils.com/comic/95-louis-c-k-we-dont-think-about...

It's not that it's terrifying. It's just... why make it harder for myself? Even if it's one step (which it isn't), why? If the only reason you can give is I need to expand my comfort zone, sorry, I'll keep my comfort zone small and productivity high.

I wasn't responding to you. The person I responded said, "I find the Java ecosystem terrifying" and I pointed out how silly that statement is.

The command to set up a Dropwizard project according to the getting started guide[0] is:

    mvn archetype:generate -DarchetypeGroupId=io.dropwizard.archetypes -DarchetypeArtifactId=java-simple -DarchetypeVersion=1.0.0

Which spends the first 30 seconds downloading a bunch of stuff before asking you for settings to start off your project. I then read the README it created and ran `mvn clean install` as instructed which started downloads that took 1:40 min only to end in a build failure with multiple large tracebacks.

Running `mvn --help` doesn't help at all and the pom file it creates is 143 lines of hard to read XML.

I've used gradle a little, I'm familiar with bundler/gem, pip, npm and dub. Maven just makes me want to run as far as possible from anything Java related.

[0] http://www.dropwizard.io/1.1.0/docs/getting-started.html

You just described my experience with npm, except there aren't any useful tracebacks, just a note absolving npm of all blame and advising me to contact some random module author.

Edit: and of course with npm the annoying downloads happen every time for each project, instead of once per dependency version...

Not excusing any crashes for npm (having those for any package manager sucks), but `npm init` doesn't download anything or make a project that needs to, it has readable config files and `npm --help` at least gives you a list of commands. A lot of the small stuff goes a long way to making things more approachable.

That's apples and oranges. You would have to set up some Express project or something to do what the Dropwizard archetype is doing.

Also package.json and pom.xml are equally (un)readable. At least Maven project files have a schema to help editors out.

> `npm --help` at least gives you a list of commands

`mvn --help` gives you a list of commands too.

Knowing how to use npm and what packages are useful isn't something that is flashed into your brain when you click download on the Node website.

For example, I've been doing a lot of Rust coding.

The code in question looks like:

    iter.next().ok_or(ErrorKind::NotEnoughArguments.into())?.parse().chain_err(|| "cannot parse argument")?

the compiler responds with cannot infer type information for `_`

the solution is of course to do

   iter.next().ok_or::<Error>(ErrorKind::NotEnoughArguments.into())?.parse().chain_err(|| "cannot parse argument")?

then the type inference is decidable

in a dynamic language, you wouldn't have to worry about this; in fact, you wouldn't need to call .into() either - there's just less typing and compiler errors

>So what's that mysterious reason that makes writing dynamically typed language faster?

Less ceremony.

But no ceremony is necessary in the cases where types can be inferred - and in the cases where types can't be inferred you probably do want to to be explicit about them even in a dynamic language.

It's not just the types, it's the whole APIs, culture etc.

Java, for example, is no picnic, whether it can now infer some types or not.

In Python I don't even need a main().

How is

    if __name__ == "__main__":
        main()

different from a main()?

It's only needed if you're importing the file as a library/module somewhere.

You don't even need that.

  print("hello world")

will run just fine

It's different in that it's optional in Python.

I agree Java is a high-ceremony language, but not all statically typed languages are like that.

The slow part of static languages isn't just typing out the annotations. Its needing to describe the type in the first place, and needing to change that type description if the shape of your data changes. If you want to prototype quickly in a dynamic language, you don't need to mess around with any sort of class description as you decide how you want your program to work.

Said dynamic language, not dynamically typed. Would be surprised if anyone considers Java more productive than Rails, Python (Django, Flask, etc) or Express.

You don't need to wait for them to compile.

Unfortunately, modern JS has Transpilers, which you have to wait for, so no, that's not the case anymore. I have not seen any NodeJS project which didn't have to be transpiled (i.e. compiled to a different JS version).

Totally false. Node.js pre-dates Babel by about 6 years so I wonder how that could possibly be true. Second, most ES6 features are already included natively in latest versions of Node so no need to transpile at all. You can even get async/await out of the box.

No one cares how you wrote 6 years ago, today the way to do it (as I've been told by many people who write NodeJS applications all the time) is to use transpilers. And:

> most ES6 features

Most. Ugly word. Really ugly word.

That's a way to do it. It is not the only way to do it, even if some people do it that way all the time.

I might add a transpiler for Typescript to my stack soon, if that language turns out as pleasant to work with as I've been hearing. If I do, it'll be the first time I use one. And I've been working with Node, in production, since 2013.

Go away. I've invested weeks to learn something which at least resembles NodeJS best practices and now you come along and say "nope, we do it different" ... :(

(That was a joke btw. Thanks for the info. The consensus seemed to be that Babel is the way to go, but if your variant works for you good to hear. I will still stay with it. I like ES6 imports in Node.)

Hey, you do you. I'm just here to say that not everyone agrees, or should, that real-world best practice necessarily involves a giant pile of transpilers and bundlers.