11 ms·

> yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Why? Writing Java is really very fast these

> yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Why? Writing Java is really very fast these days, especially with IDE's. I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration.

pyrophane 10y ago
I can understand it. If you want to just get something together quickly then dynamic languages do have an edge. They allow you to say "just give me whatever and if it fits, it fits" and if you aren't that concerned about it breaking you can build something extremely fast.
- hota_mazi 10y ago
  You're just repeating the same claim without any evidence. Why is it faster to write code in a dynamically typed language? Most modern statically typed languages have type inference so you don't even need to write type annotations for the most part, assuming these extra characters were the reason. So what's that mysterious reason that makes writing dynamically typed language faster?
  - mikerybka 10y ago
    You don't need to wait for them to compile.
    - sgift 10y ago
      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).
      - chrisco255 10y ago
        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.
        sgift 10y ago
        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.
        deleted 10y ago
        [deleted]
        throwanem 10y ago
        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.
        sgift 10y ago
        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.)
        throwanem 10y ago
        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.
  - iopq 10y ago
    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
  - skolsuper 10y ago
    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.
    - hota_mazi 10y ago
      > 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.
      - skolsuper 10y ago
        > 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
        mattmanser 10y ago
        This is a classic case of you forgetting all the learning and concepts you needed to get to "zero".
        10y ago
  - pbreit 10y ago
    Said dynamic language, not dynamically typed. Would be surprised if anyone considers Java more productive than Rails, Python (Django, Flask, etc) or Express.
  - coldtea 10y ago
    >So what's that mysterious reason that makes writing dynamically typed language faster? Less ceremony.
    - lmm 10y ago
      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.
      - coldtea 10y ago
        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().
        lmm 10y ago
        I agree Java is a high-ceremony language, but not all statically typed languages are like that.
        hota_mazi 10y ago
        How is if __name__ == "__main__": main() different from a main()?
        cookiecaper 10y ago
        It's only needed if you're importing the file as a library/module somewhere.
        squeaky-clean 10y ago
        You don't even need that. print("hello world") will run just fine
        coldtea 10y ago
        It's different in that it's optional in Python.
  - nepeckman 10y ago
    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.
mattnewton 10y ago
The edit/refresh cycle starts to slow as the project grows in Java, but node has pretty close to zero startup time and is interpreted. That plus a repl supports a much more explorative coding style where things work as fast as you can add them. No JVM restarts, compilations, or going back to change types or api's in the middle of a thought.
- hota_mazi 10y ago
  > The edit/refresh cycle starts to slow IDEA and Eclipse compile your code as you write it. And with Hotswap, you don't even need to redeploy anything. They also all offer REPL's that are much more sophisticated than anything Javascript has to offer. I think you haven't used a JVM language and its ecosystem in a very long time.
  - ars 10y ago
    > And with Hotswap, you don't even need to redeploy anything. Except when you have to restart the JVM because you added a class or a whole bunch of other things that it can't hotswap in the new code.
    - hota_mazi 10y ago
      Still better than any dynamically typed language (I mean any) where you always have to redeploy everything since none of these language support incremental compilation, let alone incremental reloading.
      - deleted 10y ago
        [deleted]
      - ben-schaaf 10y ago
        If I'm using a truly compiled language (eg. C++, D), which have incremental compilation, I still have to redeploy everything since 'everything' is a single executable. If I'm using an interpreted language I only have to deploy the changed source files. Git can do that for you.
rapsey 10y ago
> I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration Java guys always say how they have really developed tooling and look down on other languages. The problem is those nice tools have become a hindrance as well. You can't develop in Java/Kotlin if you don't use those huge complicated tools. I can't speak for all, but at least for me it prevents me from ever using Java tech. I can develop just fine using a lightweight editor in any of the languages I use. I don't need huge tools or complicated build systems. Because my languages have nice tooling that I can write manually and fully understand. I tried using Kotlin and step one is always install Intellij.
- sgift 10y ago
  > huge complicated tools. Oh please. Let's be real, Maven is not even remotely more complicated than the typical package.json, webpack.config.json, .babelrc triple you need for any useful NodeJS project (though you can put the .babelrc into the package.json, I've heard that's the way to do it at the moment). I was so taken back that nowadays JS needs a build step too. But it's a "transpiler", not a "compiler" - cause that's something completely different. > I tried using Kotlin and step one is always install Intellij. So? Atom and Visual Studio Code did need to be installed too on my machine. This mentality reminds me of someone using an axe head as a hammer "I'd have to pull the hammer out of the toolbox" (install it) - that's too complicated, I prefer light-weight tools!"
  - chrisco255 10y ago
    You don't need a build step for Node.js, 93% of ES6 features are already included in the latest version. Babel is more for client side than anything and that's because browser vendors take a while to implement new standards, so yeah JS has unique challenges and constraints as the de facto language of the web.
    - taurath 10y ago
      Or typescript frequently.
manyxcxi 10y ago
You know what isn't as quick? Websockets, non-trivial asynchronous code, boilerplate, and build times. The vast majority of my company is built on Java and we're not encumbered by legacy code, so we get to play with all the new stuff. I don't need to be convinced that Java (or even more specifically the JVM) is a good choice for many practical reasons. I live in IntelliJ and Gradle (and Maven too) all day, you're preaching to the choir. Between having a REPL, near instaneous stop/relaunch times, and doing in 8 lines of Node.js what takes me 70 lines using CompletableFutures, I'm still going to reach for Node to prove the idea. Now, when it takes hold and looks like it might stick around, it immediately gets turned into a Java project. Or, if the event we were building for is over, it basically just gets deleted- which pretty much says it all in my opinion. It's not a toy language, there's some real usefulness to it, but just like anything else, there's a time and place. Currently, that place is NOT production.
- dm3 10y ago
  Do you have any particular reasons to prefer Node (assuming Javascript) to Clojure/Groovy? Asking, because I do most of my development in Clojure and find it much nicer than Node both for POC and production. There's also self-hosted Clojurescript now that runs without a dependency on JVM.
  - manyxcxi 10y ago
    Honestly, because I'm pretty good w/ Node (or just JS in general) and haven't invested the time to get good w/ Groovy or Clojure at this point. I've only just played around with Clojure and I've written a middling amount of Groovy, but the vast majority of it involved Jenkins build pipelines, so I don't really count it.
- lmm 10y ago
  I agree that Java's async support is bad (haven't had to use it much since I've been primarily Scala for years now), but I'm surprised a PoC would need to be async in the first place? Conventional one-thread-per-request is fine for non-prod, no?
ganonm 10y ago
> I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration. Dropwizard is a great example of this. It's an opinionated (convention over configuration) Java framework for building REST web services. You can get a 'Hello World' web service up and running in literally 10 minutes following this tutorial http://www.dropwizard.io/1.0.0/docs/getting-started.html http://www.dropwizard.io/1.0.0/docs/getting-started.html

pyrophane 10y ago

I can understand it. If you want to just get something together quickly then dynamic languages do have an edge. They allow you to say "just give me whatever and if it fits, it fits" and if you aren't that concerned about it breaking you can build something extremely fast.

hota_mazi 10y ago
You're just repeating the same claim without any evidence. Why is it faster to write code in a dynamically typed language? Most modern statically typed languages have type inference so you don't even need to write type annotations for the most part, assuming these extra characters were the reason. So what's that mysterious reason that makes writing dynamically typed language faster?
- mikerybka 10y ago
  You don't need to wait for them to compile.
  - sgift 10y ago
    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).
    - chrisco255 10y ago
      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.
      - sgift 10y ago
        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.
        deleted 10y ago
        [deleted]
        throwanem 10y ago
        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.
        sgift 10y ago
        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.)
        throwanem 10y ago
        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.
- iopq 10y ago
  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
- skolsuper 10y ago
  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.
  - hota_mazi 10y ago
    > 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.
    - skolsuper 10y ago
      > 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
      - mattmanser 10y ago
        This is a classic case of you forgetting all the learning and concepts you needed to get to "zero".
        10y ago
- pbreit 10y ago
  Said dynamic language, not dynamically typed. Would be surprised if anyone considers Java more productive than Rails, Python (Django, Flask, etc) or Express.
- coldtea 10y ago
  >So what's that mysterious reason that makes writing dynamically typed language faster? Less ceremony.
  - lmm 10y ago
    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.
    - coldtea 10y ago
      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().
      - lmm 10y ago
        I agree Java is a high-ceremony language, but not all statically typed languages are like that.
      - hota_mazi 10y ago
        How is if __name__ == "__main__": main() different from a main()?
        cookiecaper 10y ago
        It's only needed if you're importing the file as a library/module somewhere.
        squeaky-clean 10y ago
        You don't even need that. print("hello world") will run just fine
        coldtea 10y ago
        It's different in that it's optional in Python.
- nepeckman 10y ago
  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.

mattnewton 10y ago

The edit/refresh cycle starts to slow as the project grows in Java, but node has pretty close to zero startup time and is interpreted. That plus a repl supports a much more explorative coding style where things work as fast as you can add them. No JVM restarts, compilations, or going back to change types or api's in the middle of a thought.

hota_mazi 10y ago
> The edit/refresh cycle starts to slow IDEA and Eclipse compile your code as you write it. And with Hotswap, you don't even need to redeploy anything. They also all offer REPL's that are much more sophisticated than anything Javascript has to offer. I think you haven't used a JVM language and its ecosystem in a very long time.
- ars 10y ago
  > And with Hotswap, you don't even need to redeploy anything. Except when you have to restart the JVM because you added a class or a whole bunch of other things that it can't hotswap in the new code.
  - hota_mazi 10y ago
    Still better than any dynamically typed language (I mean any) where you always have to redeploy everything since none of these language support incremental compilation, let alone incremental reloading.
    - deleted 10y ago
      [deleted]
    - ben-schaaf 10y ago
      If I'm using a truly compiled language (eg. C++, D), which have incremental compilation, I still have to redeploy everything since 'everything' is a single executable. If I'm using an interpreted language I only have to deploy the changed source files. Git can do that for you.

rapsey 10y ago

> I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration Java guys always say how they have really developed tooling and look down on other languages. The problem is those nice tools have become a hindrance as well. You can't develop in Java/Kotlin if you don't use those huge complicated tools. I can't speak for all, but at least for me it prevents me from ever using Java tech. I can develop just fine using a lightweight editor in any of the languages I use. I don't need huge tools or complicated build systems. Because my languages have nice tooling that I can write manually and fully understand. I tried using Kotlin and step one is always install Intellij.

sgift 10y ago
> huge complicated tools. Oh please. Let's be real, Maven is not even remotely more complicated than the typical package.json, webpack.config.json, .babelrc triple you need for any useful NodeJS project (though you can put the .babelrc into the package.json, I've heard that's the way to do it at the moment). I was so taken back that nowadays JS needs a build step too. But it's a "transpiler", not a "compiler" - cause that's something completely different. > I tried using Kotlin and step one is always install Intellij. So? Atom and Visual Studio Code did need to be installed too on my machine. This mentality reminds me of someone using an axe head as a hammer "I'd have to pull the hammer out of the toolbox" (install it) - that's too complicated, I prefer light-weight tools!"
- chrisco255 10y ago
  You don't need a build step for Node.js, 93% of ES6 features are already included in the latest version. Babel is more for client side than anything and that's because browser vendors take a while to implement new standards, so yeah JS has unique challenges and constraints as the de facto language of the web.
  - taurath 10y ago
    Or typescript frequently.

manyxcxi 10y ago

You know what isn't as quick? Websockets, non-trivial asynchronous code, boilerplate, and build times. The vast majority of my company is built on Java and we're not encumbered by legacy code, so we get to play with all the new stuff. I don't need to be convinced that Java (or even more specifically the JVM) is a good choice for many practical reasons. I live in IntelliJ and Gradle (and Maven too) all day, you're preaching to the choir. Between having a REPL, near instaneous stop/relaunch times, and doing in 8 lines of Node.js what takes me 70 lines using CompletableFutures, I'm still going to reach for Node to prove the idea. Now, when it takes hold and looks like it might stick around, it immediately gets turned into a Java project. Or, if the event we were building for is over, it basically just gets deleted- which pretty much says it all in my opinion. It's not a toy language, there's some real usefulness to it, but just like anything else, there's a time and place. Currently, that place is NOT production.

dm3 10y ago
Do you have any particular reasons to prefer Node (assuming Javascript) to Clojure/Groovy? Asking, because I do most of my development in Clojure and find it much nicer than Node both for POC and production. There's also self-hosted Clojurescript now that runs without a dependency on JVM.
- manyxcxi 10y ago
  Honestly, because I'm pretty good w/ Node (or just JS in general) and haven't invested the time to get good w/ Groovy or Clojure at this point. I've only just played around with Clojure and I've written a middling amount of Groovy, but the vast majority of it involved Jenkins build pipelines, so I don't really count it.
lmm 10y ago
I agree that Java's async support is bad (haven't had to use it much since I've been primarily Scala for years now), but I'm surprised a PoC would need to be async in the first place? Conventional one-thread-per-request is fine for non-prod, no?

ganonm 10y ago

> I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration. Dropwizard is a great example of this. It's an opinionated (convention over configuration) Java framework for building REST web services. You can get a 'Hello World' web service up and running in literally 10 minutes following this tutorial http://www.dropwizard.io/1.0.0/docs/getting-started.html http://www.dropwizard.io/1.0.0/docs/getting-started.html