5 ms·

You basically have arrived where lisp was some decades ago. Logical next steps are to write the OS and the editor and the VCS in JavaScript. However, at some p

You basically have arrived where lisp was some decades ago. Logical next steps are to write the OS and the editor and the VCS in JavaScript. However, at some point you will have a look into your myriad of nodejs dependencies and see with horror that they rely on C++ extensions. Then you learn that your precious stack is just a GCC upgrade away from not building anymore. And noone in your company even remembers what that is, a C++ compiler flag.

winrid 6y ago
Well, in my experience you cache those dependencies via something like jfrog. That helps. But yeah, dependencies require maintenance.
speedgoose 6y ago
If a NPM package requires a C++ compiler, I ignore it and move on.
- mbrodersen 6y ago
  V8 (and other Javascript JIT compilers) are written in C++. Whenever you think you run Javascript code, what you are actually running is C++ code that will emulate and compile your Javascript into machine code, update the DOM with C++ code, access sockets using C/C++ code etc. all running on an OS written in C/C++. Your code is a very small percentage of the code that runs "your" application. C/C++ runs the world. Including Javascript, Python, Java etc.
  - speedgoose 6y ago
    I do trust the C++ of V8 and NodeJS because it's used by many and well tested in the field. I do not trust a random npm package with C++. C++ is way too level and insecure and it's not worth it.
AmericanChopper 6y ago
Whether you end up with a hellish dependency tree is more up to the developer than the language. I’d say the only reason this is more common in node projects than it is in other languages is because dependency management in other languages is more tedious, so the barrier for introducing new dependencies is higher. All of my node projects have had rather tidy dependency trees. It’s also been quite easy for me to use popular packages. If something breaks and hundreds of thousands of devs are impacted by it, it’s going to get fixed pretty quick. Which has been my experience in the rare occasions that in of my dependencies has broken, it’s been fixed before it even had a chance to impact me.
- randombytes6869 6y ago
  Trust me, its the lack of standard library. Python and Java are both "batteries included" . You can write apps decently with just 5-10 dependencies if you want. Every JS app I've worked on has like 10-20X the dependencies of projects written in languages with a good standard lib
  - ProZsolt 6y ago
    I'm currently learning Go and it's at the other end of the spectrum. Most of my apps have only one to three dependencies and one is usually a database driver. It's a really good feeling when there is something missing from the standard library and you questioning yourself that you really need that thing.
  - scottlocklin 6y ago
    > Trust me, its the lack of standard library. It's almost certainly not, as R has plenty of batteries, and young nitwits in the Hadleyverse are writing preposterous node-like dependency graphs. It's fashion, and it should be curb-stomped.
    - disgruntledphd2 6y ago
      To be fair though, there isn't as much good introductory resources on base R, that aren't very discipline specific. I do completely agree otherwise, but those people will learn through bitter, bitter experience that those dependencies will break over time and will see the light that is base R.
sradman 6y ago
Choose “proven” technology, or “boring” tech as the original article calls it, applies here too. Popular libraries that are embedded in multiple language runtimes are written in C. SQLite comes to mind. Choose boring dependencies written with boring integration interfaces.
randombytes6869 6y ago
> at some point you will have a look into your myriad of nodejs dependencies and see with horror that they rely on C++ extension This is a big selling point of the most boring languages of all, Java and C#. Performance is close enough to C, and FFI is painful enough, that its rare to see any native code in a project. Other languages that are slower or have better FFI have a much bigger risk of bitrot if you're going to keep a backend around for decades. Where I work we deploy the exact same pre-built artifact to our Mac dev machines, Linux servers, and Windows QA guys. With Go, Python, JS, Ruby, etc we would have to have it built specifically for the platform. They all use enough native libraries that you can't share a zip file. And its a huge pain to cross-compile for anything except Linux.

winrid 6y ago

Well, in my experience you cache those dependencies via something like jfrog. That helps. But yeah, dependencies require maintenance.

speedgoose 6y ago

If a NPM package requires a C++ compiler, I ignore it and move on.

mbrodersen 6y ago
V8 (and other Javascript JIT compilers) are written in C++. Whenever you think you run Javascript code, what you are actually running is C++ code that will emulate and compile your Javascript into machine code, update the DOM with C++ code, access sockets using C/C++ code etc. all running on an OS written in C/C++. Your code is a very small percentage of the code that runs "your" application. C/C++ runs the world. Including Javascript, Python, Java etc.
- speedgoose 6y ago
  I do trust the C++ of V8 and NodeJS because it's used by many and well tested in the field. I do not trust a random npm package with C++. C++ is way too level and insecure and it's not worth it.

AmericanChopper 6y ago

Whether you end up with a hellish dependency tree is more up to the developer than the language. I’d say the only reason this is more common in node projects than it is in other languages is because dependency management in other languages is more tedious, so the barrier for introducing new dependencies is higher. All of my node projects have had rather tidy dependency trees. It’s also been quite easy for me to use popular packages. If something breaks and hundreds of thousands of devs are impacted by it, it’s going to get fixed pretty quick. Which has been my experience in the rare occasions that in of my dependencies has broken, it’s been fixed before it even had a chance to impact me.

randombytes6869 6y ago
Trust me, its the lack of standard library. Python and Java are both "batteries included" . You can write apps decently with just 5-10 dependencies if you want. Every JS app I've worked on has like 10-20X the dependencies of projects written in languages with a good standard lib
- ProZsolt 6y ago
  I'm currently learning Go and it's at the other end of the spectrum. Most of my apps have only one to three dependencies and one is usually a database driver. It's a really good feeling when there is something missing from the standard library and you questioning yourself that you really need that thing.
- scottlocklin 6y ago
  > Trust me, its the lack of standard library. It's almost certainly not, as R has plenty of batteries, and young nitwits in the Hadleyverse are writing preposterous node-like dependency graphs. It's fashion, and it should be curb-stomped.
  - disgruntledphd2 6y ago
    To be fair though, there isn't as much good introductory resources on base R, that aren't very discipline specific. I do completely agree otherwise, but those people will learn through bitter, bitter experience that those dependencies will break over time and will see the light that is base R.

sradman 6y ago

Choose “proven” technology, or “boring” tech as the original article calls it, applies here too. Popular libraries that are embedded in multiple language runtimes are written in C. SQLite comes to mind. Choose boring dependencies written with boring integration interfaces.

randombytes6869 6y ago

> at some point you will have a look into your myriad of nodejs dependencies and see with horror that they rely on C++ extension This is a big selling point of the most boring languages of all, Java and C#. Performance is close enough to C, and FFI is painful enough, that its rare to see any native code in a project. Other languages that are slower or have better FFI have a much bigger risk of bitrot if you're going to keep a backend around for decades. Where I work we deploy the exact same pre-built artifact to our Mac dev machines, Linux servers, and Windows QA guys. With Go, Python, JS, Ruby, etc we would have to have it built specifically for the platform. They all use enough native libraries that you can't share a zip file. And its a huge pain to cross-compile for anything except Linux.