7 ms·

Unless your project is small (like under 10-20k lines), why use node when you can use a typed language? Javascript is a mess and if I'm server side and using s

by mahyarm 10y ago

Unless your project is small (like under 10-20k lines), why use node when you can use a typed language? Javascript is a mess and if I'm server side and using something dynamic, I might as well use something nicer like ruby or python.

z3t4 10y ago
Types are low level. JavaScript is very high on the stack, and has no concept of types, it only has "value objects" (variable values: string and number, plus static values: true, false, null, undefined) and "normal objects" (Array, Object, Date, Function, etc). There's a debate though on what type should be used for numeric values in JavaScript. In JavaScript you rarely see getters and setters, as you do not need any abstraction over the type system, although it is possible to do bitwise operations, so if you want to you could make your own types, although you will not have full control of their binary representation, witch you would need a "real" programming language with a proper type system, but I've only seen that in optimization witch rarely runs faster then native JS. You get a lot of productivity by not having to worry about types in JS, and you rarely se buffer overflows witch is common in lower level languages such as C and C++. JavaScript is an an abstraction where you do not have to worry about the under-layer like imperative memory management. If you have to decide between small int vs big int vs floats, it's a leaky abstraction. JavaScript is one level above that.
- tscs37 10y ago
  You seem to assume that A) Types are low level B) C++ and C are the only competition to JavaScript C) Not having to worry about types makes you faster or in any way better A) is simply refuted by looking at java or SQL. SQL is a very high-level language compared to other stuff, yet it's heavily typed simply to ensure that data is either valid or the query fails (SQL Injection is still valid data in this case) B) Take a look at Go. It's blazing fast. It beats Node.js in all benchmarks but Regex matching -> https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=node https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... Furthermore, Go is statically linked which means deploying to production is a simple scp operation to drop the binary. Lastly, Go is opinionated on how you write programs, you will write programs that are scalable simply because of how simple goroutines are, using channels you can utilize asynchronous execution as you would in node.js but also utilize all available cores without having to think about threads or synchronization. Just pipe data through the channel! C) Is a red herring, depending on who you ask it's either opinion or static typing being "better". http://danluu.com/empirical-pl/ http://danluu.com/empirical-pl/ Some studies indicate that it does not matter, some indicate faster development but more bugs for no types and others indicate less bugs and slightly longer development for types. IMO Types are good. I want to worry about the types because when I receive user input I can be sure that once parsed it's 100% an int or a float or it fits in a certain struct. For the same reason I think relational databases are better than document stores, they ensure that my data is valid. I don't have to write as much validation logic. It is sufficient to know that my function has been passed an int-type, I don't have to check if it's nil or a string.
  - life_is_short 10y ago
    > without having to think about threads or synchronization. Just pipe data through the channel! I mostly agree with what you're saying, but note having a channel doesn't mean one stops worrying about synchronization. If two goroutines both started waiting for data from a channel they'd be deadlocked.
    - tscs37 10y ago
      True, on the other hand, go will take care of that to some extend and terminate if all go routines have been deadlocked. Which means well-designed services will remain available even if only with degraded performance.
      - life_is_short 10y ago
        I didn't know go can do deadlock detection. Thanks for this, I learned something new today.
        tscs37 10y ago
        it's not a 100% detection. You can certainly pile up deadlocked go routines, but the way most libraries (including the standard library) are setup, if you were to write some server, you'd only deadlock on the request but the app keep running. There is no way to reliably detect that but the service will probably service most requests if you didn't plain deadlock everything. If all go routines are deadlocked, the runtime will terminate the service. It's a kind of graceful and somewhat safe degradation.
  - z3t4 10y ago
    SQL is also a leaky abstraction, it would be much more simple if the database could just take any value and store it optimally. But at least you do not have to write: SELECT *string* foo, *string* bar FROM banana A INNER JOIN beer B ON *int* B.id = *int* A.id I want to correct myself though. In ES6 you can now go very low level and deal with raw bit buffers. My problem with Go and other languages is that you have to be verbose like str = string = "string"; Where the compiler could probably figure out it's a string because of the quotes. And use a default numeric type when dealing with numbers. A compiled language also has the advantage that the compiler can thoroughly analyze the program, optimize and chose the optimal types if they are not explicitly set. My biggest issue though is the inferior module system compared to NodeJS (commonJS) module system that makes it possible to not write complexed code, because it's lexically scoped and do not have hidden globals. I'm aware that an imperative low level language that can talk directly to the hardware will beat NodeJS and JavaScript in performance. But for the most part I'm willing to sacrifice that for increased productivity and simplicity. What do you think about languages that compile to JavaScript ? And do you think adding types to JavaScript would make it more simple ?
- deleted 10y ago
  [deleted]
danneu 10y ago
> if I'm server side and using something dynamic, I might as well > use something nicer like ruby or python. You could say the same thing about Javascript. "Might as well use the language I already use on the front-end." The code is pretty much identical between Ruby, Python, and Javascript once you have a yield/await abstraction in the latter.
Roboprog 10y ago
Why use an OOP language when you can use an FP one? I must have missed the memo that proved that Java / C# / C++ / Simula 67 are the one true path to productivity. Async I/O is clumsy on the server side, though.
- mahyarm 10y ago
  FP can still have types, like haskell. Typing is independent of OOP vs FP
  - Roboprog 10y ago
    Sorry. Generally, when I hear people complain about the lack of "types" in a dynamic language, I'm pretty sure what they mean is [static] "classes", so that "intellisense" (auto-complete, for non-MS/VS-bubble-land) works. Then next, a hair-brained XML configuration scheme (with reflection) will be used to work around the inevitable deficiencies, which an IDE plug-in may or may not parse accurately. Tragedy ensues. (Or hilarity, if I get to stand back while somebody else has to support the monster) YMMV.

by mahyarm 10y ago

z3t4 10y ago

Types are low level. JavaScript is very high on the stack, and has no concept of types, it only has "value objects" (variable values: string and number, plus static values: true, false, null, undefined) and "normal objects" (Array, Object, Date, Function, etc). There's a debate though on what type should be used for numeric values in JavaScript. In JavaScript you rarely see getters and setters, as you do not need any abstraction over the type system, although it is possible to do bitwise operations, so if you want to you could make your own types, although you will not have full control of their binary representation, witch you would need a "real" programming language with a proper type system, but I've only seen that in optimization witch rarely runs faster then native JS. You get a lot of productivity by not having to worry about types in JS, and you rarely se buffer overflows witch is common in lower level languages such as C and C++. JavaScript is an an abstraction where you do not have to worry about the under-layer like imperative memory management. If you have to decide between small int vs big int vs floats, it's a leaky abstraction. JavaScript is one level above that.

tscs37 10y ago
You seem to assume that A) Types are low level B) C++ and C are the only competition to JavaScript C) Not having to worry about types makes you faster or in any way better A) is simply refuted by looking at java or SQL. SQL is a very high-level language compared to other stuff, yet it's heavily typed simply to ensure that data is either valid or the query fails (SQL Injection is still valid data in this case) B) Take a look at Go. It's blazing fast. It beats Node.js in all benchmarks but Regex matching -> https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=node https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... Furthermore, Go is statically linked which means deploying to production is a simple scp operation to drop the binary. Lastly, Go is opinionated on how you write programs, you will write programs that are scalable simply because of how simple goroutines are, using channels you can utilize asynchronous execution as you would in node.js but also utilize all available cores without having to think about threads or synchronization. Just pipe data through the channel! C) Is a red herring, depending on who you ask it's either opinion or static typing being "better". http://danluu.com/empirical-pl/ http://danluu.com/empirical-pl/ Some studies indicate that it does not matter, some indicate faster development but more bugs for no types and others indicate less bugs and slightly longer development for types. IMO Types are good. I want to worry about the types because when I receive user input I can be sure that once parsed it's 100% an int or a float or it fits in a certain struct. For the same reason I think relational databases are better than document stores, they ensure that my data is valid. I don't have to write as much validation logic. It is sufficient to know that my function has been passed an int-type, I don't have to check if it's nil or a string.
- life_is_short 10y ago
  > without having to think about threads or synchronization. Just pipe data through the channel! I mostly agree with what you're saying, but note having a channel doesn't mean one stops worrying about synchronization. If two goroutines both started waiting for data from a channel they'd be deadlocked.
  - tscs37 10y ago
    True, on the other hand, go will take care of that to some extend and terminate if all go routines have been deadlocked. Which means well-designed services will remain available even if only with degraded performance.
    - life_is_short 10y ago
      I didn't know go can do deadlock detection. Thanks for this, I learned something new today.
      - tscs37 10y ago
        it's not a 100% detection. You can certainly pile up deadlocked go routines, but the way most libraries (including the standard library) are setup, if you were to write some server, you'd only deadlock on the request but the app keep running. There is no way to reliably detect that but the service will probably service most requests if you didn't plain deadlock everything. If all go routines are deadlocked, the runtime will terminate the service. It's a kind of graceful and somewhat safe degradation.
- z3t4 10y ago
  SQL is also a leaky abstraction, it would be much more simple if the database could just take any value and store it optimally. But at least you do not have to write: SELECT *string* foo, *string* bar FROM banana A INNER JOIN beer B ON *int* B.id = *int* A.id I want to correct myself though. In ES6 you can now go very low level and deal with raw bit buffers. My problem with Go and other languages is that you have to be verbose like str = string = "string"; Where the compiler could probably figure out it's a string because of the quotes. And use a default numeric type when dealing with numbers. A compiled language also has the advantage that the compiler can thoroughly analyze the program, optimize and chose the optimal types if they are not explicitly set. My biggest issue though is the inferior module system compared to NodeJS (commonJS) module system that makes it possible to not write complexed code, because it's lexically scoped and do not have hidden globals. I'm aware that an imperative low level language that can talk directly to the hardware will beat NodeJS and JavaScript in performance. But for the most part I'm willing to sacrifice that for increased productivity and simplicity. What do you think about languages that compile to JavaScript ? And do you think adding types to JavaScript would make it more simple ?
deleted 10y ago
[deleted]

danneu 10y ago

> if I'm server side and using something dynamic, I might as well > use something nicer like ruby or python. You could say the same thing about Javascript. "Might as well use the language I already use on the front-end." The code is pretty much identical between Ruby, Python, and Javascript once you have a yield/await abstraction in the latter.

Roboprog 10y ago

Why use an OOP language when you can use an FP one? I must have missed the memo that proved that Java / C# / C++ / Simula 67 are the one true path to productivity. Async I/O is clumsy on the server side, though.

mahyarm 10y ago
FP can still have types, like haskell. Typing is independent of OOP vs FP
- Roboprog 10y ago
  Sorry. Generally, when I hear people complain about the lack of "types" in a dynamic language, I'm pretty sure what they mean is [static] "classes", so that "intellisense" (auto-complete, for non-MS/VS-bubble-land) works. Then next, a hair-brained XML configuration scheme (with reflection) will be used to work around the inevitable deficiencies, which an IDE plug-in may or may not parse accurately. Tragedy ensues. (Or hilarity, if I get to stand back while somebody else has to support the monster) YMMV.