8 ms·

sounds like the same experience I have with pretty much every language I'm not used to. I just want to try this C++, download, unzip, oh it's windows so .proje

by gernb 4y ago

sounds like the same experience I have with pretty much every language I'm not used to. I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error. repeat the same with xcode and any project in c, c++, objc, swift okay how about ruby? oh I have old ruby , hmmm , try to install new ruby, seems to run, but it can't find certain gems or something. oh and this other ruby thing I was using is now broken ? why do I have to install this stuff globally? You don't but there are several magic spells you must execute and runes you must set in the rigtt places. Oh ... I think I got that setup but it getting this new error. .... I'm sypathetic it sucks but it's not unique to js

Madmallard 4y ago
Stacks being nonfunctional on install is a failure not progress
synthmeat 4y ago
Go is yet to prove its stability over timespans similar to those languages you've mentioned, but it doesn't have many of noted (and similar) quirks.
- rat9988 4y ago
  My old go code doesn't compile anymore with the newer compiler versions
  - synthmeat 4y ago
    What was it that broke it? Usage of unsafe? Security and bug fixes in the compiler/tooling? Just interested.
    - rat9988 4y ago
      I didn't try for a long time I have a hard time remembering. I believe it had something to do about how it handles dependencies.
    - jcalabro 4y ago
      The Go 1 promise[0] says that the language spec and set of core libraries will be backwards compatible. I maintain a few dozen go projects, some of which are 10 years old, and while upgrading from i.e. 1.4 -> 1.18 has been relatively easy, it definitely has not been zero work. There are changes in the tooling, dependency ecosystem, deprecated dependencies that should be replaced, runtime behavior differences, things like that. But the language itself and stdlib is totally stable. [0] https://go.dev/doc/go1compat https://go.dev/doc/go1compat
- divan 4y ago
  I recently had to work on a library I wrote in Go in late 2013. I think it was Go 1.2 back then. (Current release is Go 1.18) It just worked. And code was quite readable. I mean it not as a complement to myself, rather the fact that Go is designed to be readable and it pays off. I only had to add modules support (basically run `go mod init` in the library's folder) to make it 100% modern-version friendly. That was as close as I could be to successfully complete 10 Years Reproducibility Challenge [1]. [1] https://github.com/ReScience/ten-years https://github.com/ReScience/ten-years
  - kaba0 4y ago
    I don’t think it is that impressive, though I have the most experience with Java, where a fat jar on a random, obsolete website displaying some university material will just work.
    - divan 4y ago
      To make your comparison with fat jars closer to the point, imagine you got the source code from the owner of that old obsolete website, and need to use it in your newest Java project, with the bleeding version of Java, gradle and all the stuff.
- coopierez 4y ago
  Its dependency management used to be a real mess though. It has got a lot better in recent years.
xpmp 4y ago
jiggawatts 4y ago
Meanwhile I've been trying to warn the Rust project team, or more specifically, the Cargo/Crates teams that they're cheerfully skipping down the easy/happy path towards the same mess. It's inevitable that the conclusion will be the same if the same steps are taken in the same direction. The counter-arguments fail to recognise the special case of "most of us are from Mozilla and we all get along[1]", "no-one has attacked us yet so no-one ever will[2]", "it's tracktable to untangle the dependency hell in your head because there aren't that many crates (yet)", and of course "we all know this history like the back of our hand, because we've all been around since v0.1 alpha." I'm picturing "10 years later" when some junior developer at MegaCorp Inc desperately tries to figure out why the legacy Rust 2018 version he's forced to use in 2032 can't compile some privately hosted crate that's needed for an enterprise project. It'll probably depend on a specific version of a crate that was yanked because some transitive dependency had to be yanked because that guy was a Russian kid that sold access to this popular crate for $500 to Israeli spies. Of course now the patched crate requires Rust 2030 or whatever, breaking fifty seven of the two thousand transitive crates being pulled it, so good luck to him with disentangling that mess and making this work. PS: I wish I was making this story up, but I basically just changed Angular to Rust for a real thing that happened to me, like... a month ago. There is no fundamental difference to how Rust does packages, it's just younger so the mess hasn't accumulated to Angular's levels of madness. Give it time... [1] Except for that spat with the core team. [2] That we know of. Ignore the guy spamming popular, single-word crate names and shovelling in 99.9% C/C++ code with the thinnest possible Rust wrapper. Surprise! Your code is now more C++ than Rust.
- bowsamic 4y ago
  Yep, the Rust team and even the wider community are literally just ignoring this problem under the justification of "it's too early to care about these things yet".
  - pie_flavor 4y ago
    Rust has been designed specifically to avoid these problems, under the justification 'it's never too early to care about these things'. I wonder what on earth you have been reading.
mojuba 4y ago
I think static languages are generally more disciplined and manageable in this regard. The only times I struggled with 3rd party Swift code was when a package included some C or C++ code alongside with Swift. Specifically, I think Apple's philosophy of "everything comes with its own dependencies embedded" saved us a lot of trouble. Sure, it's more disk space and potentially lots of duplicates (just count the number of times various SSL libs are included in a single large and messy application), but it usually just works.
- astrange 4y ago
  MachO has some features that make this easier than ELF, namely matching libraries by full path and two-level namespaces (external symbols know which library they're found in). Though it's still not great if everyone uses their own SSL library, because then you can't update it if there's a bug.
  - mojuba 4y ago
    Yes it's a problem, but because you (as a library maintainer) are responsible for what you are embedding, you should keep an eye on the dependencies and test them with each update. This creates a hierarchy of responsibilities, as opposed to a flat mess that is Linux .so or Windows .dll approach.
- enlyth 4y ago
  I had a similar experience with Rust when I first tried it a couple years ago. Wanted to make a web server which returns Hello World, and then this crate doesn't compile, this official example from the README throws a compilation error, that crate is the wrong version, etc etc. I tried again today and got it done in 2 minutes, so it seems things have improved.
hyperpallium2 4y ago
It is unique to old languages. Young languages are easy to get started in. Ruby used to be. Though ruby has a separate problem of breaking changes. The back-compatibility crowd can run old code (e.g. java), but at the cost of their soul.
- lelanthran 4y ago
  > It is unique to old languages. Rust is a new language, and it has the same complaints above.
bborud 4y ago
You are probably right, but there are differences. Languages like Go and Rust are much easier to get started with since they have better tooling, and more importantly, the tooling has a smaller and more regular surface. This is immensely important. Granted, they occasionally have unnecessary and stupid quirks, but they tend to be small (in terms of cognitive footprint) and contained. In my neck of the woods, Python is the major source of time spent trying to get other people's code to run on my machine. The path of least resistance for Python developers tends to produce code that requires you to go through an easter egg hunt to make it run outside the original author's machine. Yes, you could write Python utilities that are easy to install and run, but people don't. And the last bit of that sentence is the one that actually counts. "Could have" doesn't actually count in an engineering context. If the consumer has to assemble and repair software before getting it to run, the developer isn't being very professional.
Gigachad 4y ago
I'm also sympathetic to the author but don't really see it as a problem. NPM modules are not apps on the App Store. They aren't intended to just be run by regular people quickly. The steps described in the article show someone hitting Node.js with a hammer until it gets closer to doing what they want without any understanding of what is going on. Which is fine, that's what people do often, but it isn't a failing of the tools when this doesn't work. I don't expect to walk in to a workshop and find the welding tools intuitive to use with no training, and I don't expect npm modules to be intuitive to an outsider either.
- lodovic 4y ago
  Sure, but that is how it's sold: NodeJS and Javascript are marketed as super easy, perfect for beginners. They're not, in my opinion.
  - trivialsoup 4y ago
    If you listen to marketers fast cars make you younger and handsomer and give you a full head of hair. Don’t look at how things are sold, look at how they are. In this case it’s code, of course there’s complexity.
psyc 4y ago
This is yak shaving. I mainly but not exclusively encounter yak shaving when, against my better judgement, I venture into the Opensourcelands. 10x more of it there, at any rate.
donatj 4y ago
I have been writing JavaScript professionally for nearly 20 years. I try my damndest to keep up, but the fact of the matter is the ecosystem is garbage. It’s really not a not-knowing-the-language thing. It’s a legacy of years and years of incompatible tooling requiring even more tooling to work around nightmare scenario. Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off. Nothing ever works like a sane person would expect. When I do get a working typescript + webpack setup it’s almost entirely by accident. I stumbled upon something that works? Just avoid touching it at all costs. Recently I wanted to load an AMD module in Deno and just about gave my self an aneurism before giving up hours later. I have worked in dozens of languages over my career, and not encountered as much of a clusterf*ck as JavaScript anywhere else. I have never worked with anything before where so few people had any idea how it actually worked and just prayed that it continues.
- fendy3002 4y ago
  > Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off Uh what? It's literally the name itself "node"_modules, it's designed to be used with node. The fact that it use same language and can later be used by browser is another matter. Thankfully we can easily bundle the whole thing using webpack nowadays. There are also countless boilerplate project with webpack setup already so you can get reference from there.
  - marpstar 4y ago
    Not that I agree with the GP, but I think it’s easy to conflate “node”_modules with “modules from NPM”. Bower was once the recommended package manager for front-end assets, but NPM overtook it. I use Node daily, but 90% of my packages are front end.
    - fendy3002 4y ago
      Uh yeah, the fact that people using npm for frontend too means alternative front end package managers isn't as good (or as suitable) as npm. I take it as even though NPM isn't aimed for that, it works well.
the__alchemist 4y ago
I think C and C++ are a fair comparison in that their build ecosystems also a bit of a mess. I offer 3 counter-examples: Rust, Python, and JS-without-NPM. edit: After reflection, I think Python straddles a middle ground. If you use modern packages and Python 3, it can be a smooth experience. If you use older (improperly-specified) packages, or FFI-wrapped-libs, it can turn into a mess too.
lysecret 4y ago
this is why i love docker :D
tyingq 4y ago
There are some ecosystems where the experience is different. Perl, for example, does have deprecations, but not many. It's fairly common to be able to run 30 year old code unmodified, or with very minor changes. Of course, it has it's own issues, but it is very stable across time.
- corrral 4y ago
  One shock if you go back and forth between Javascript and, say, Java, is adjusting your library evaluation criteria. It's not weird for a Java project to include a library that hasn't had any updates in 4+ years. Sometimes those sorts of libraries are even considered the standard for whatever thing they do. Meanwhile in JS you have to assume a library with no releases in the last 6 months has already bitrotted to death.
deleted 4y ago
[deleted]
aeturnum 4y ago
I agree that the C family has some similar problems but I think you're missing part of what makes Javascript uniquely frustrating. Javascript is deployed in many different environments and you need to learn not just how to include a library in each environment, but also how to interact with that library. Also unlike C or other languages - Javascript has a hard time warning you about when you've imported something the wrong way. C can at least tell you "this does not link" (so it was found but is binary incompatible) - in my experience if you copy and paste a node import line in the browser the browser will just say "this does not make sense to me." C gives more breadcrumbs. I also think that once you get outside the C-likes, the story is universally better. For all of its packaging flaws, it's easy to get python packages for development. Every time I want to make something in Javascript I'm frustrated all over again by how I need to know details about the Javascript ecosystem that I have no way of knowing at this stage (like: getting to hello world can require a working knowledge of WebPack). It's just no where near that bad other places.
- greggman3 4y ago
  I get it's frustrating but ... do you expect any Lua to run in every environment Lua is used in? AFAICT no 2 Lua's are alike and nearly ever use of it has it's own APIs and quirks. I have the same issue with C. You can find some C that will run anywhere. You can also find lots of C that is platform specific and unless you're an expert you'll be just as frustrated trying to get it to run on a different platform. Seems the same to me.
  - aeturnum 4y ago
    > do you expect any Lua to run in every environment Lua is used in? I do not, but again - I think "I should be able to run any version of a language in any place" is not related to "it is strangely hard to run a given Javascript file." I actually think Lua is a great example for comparison that illustrates the point! Different Luas support different features, but the basics (import statements, etc) are syntactically valid (and singular) in all of them. If you try to import a library that doesn't exist in the version you've embedded, you will get an import error. In Javascript - there are multiple import systems for different ecosystems. Getting an import error might mean you need to install the library, it might mean you're using the wrong convention, it might mean that the version of the library has a compilation error....etc. Javascript does not really help you resolve this. What this means is that there's a clean separation between environment and language. If your Lua deploy supports all the features your script uses, you are good - there are no "families" of Lua script that use different conventions for importing libraries or interop or whatever. A given piece of Javascript, however, has an arbitrary number of deployment-specific setup actions that require pretty advanced ecosystem knowledge to identify. Like, look back at the errors listed in the article. There's nothing "wrong" with the restrictions, but the language ecosystem does an unusually bad job of helping you understand and navigate them. Like, you can have two or three different import mechanisms for different environments...but if you want to do that you should be more helpful in pointing out when you're using the wrong one.

by gernb 4y ago

Madmallard 4y ago

Stacks being nonfunctional on install is a failure not progress

synthmeat 4y ago

Go is yet to prove its stability over timespans similar to those languages you've mentioned, but it doesn't have many of noted (and similar) quirks.

rat9988 4y ago
My old go code doesn't compile anymore with the newer compiler versions
- synthmeat 4y ago
  What was it that broke it? Usage of unsafe? Security and bug fixes in the compiler/tooling? Just interested.
  - rat9988 4y ago
    I didn't try for a long time I have a hard time remembering. I believe it had something to do about how it handles dependencies.
  - jcalabro 4y ago
    The Go 1 promise[0] says that the language spec and set of core libraries will be backwards compatible. I maintain a few dozen go projects, some of which are 10 years old, and while upgrading from i.e. 1.4 -> 1.18 has been relatively easy, it definitely has not been zero work. There are changes in the tooling, dependency ecosystem, deprecated dependencies that should be replaced, runtime behavior differences, things like that. But the language itself and stdlib is totally stable. [0] https://go.dev/doc/go1compat https://go.dev/doc/go1compat
divan 4y ago
I recently had to work on a library I wrote in Go in late 2013. I think it was Go 1.2 back then. (Current release is Go 1.18) It just worked. And code was quite readable. I mean it not as a complement to myself, rather the fact that Go is designed to be readable and it pays off. I only had to add modules support (basically run `go mod init` in the library's folder) to make it 100% modern-version friendly. That was as close as I could be to successfully complete 10 Years Reproducibility Challenge [1]. [1] https://github.com/ReScience/ten-years https://github.com/ReScience/ten-years
- kaba0 4y ago
  I don’t think it is that impressive, though I have the most experience with Java, where a fat jar on a random, obsolete website displaying some university material will just work.
  - divan 4y ago
    To make your comparison with fat jars closer to the point, imagine you got the source code from the owner of that old obsolete website, and need to use it in your newest Java project, with the bleeding version of Java, gradle and all the stuff.
coopierez 4y ago
Its dependency management used to be a real mess though. It has got a lot better in recent years.

xpmp 4y ago

jiggawatts 4y ago

Meanwhile I've been trying to warn the Rust project team, or more specifically, the Cargo/Crates teams that they're cheerfully skipping down the easy/happy path towards the same mess. It's inevitable that the conclusion will be the same if the same steps are taken in the same direction. The counter-arguments fail to recognise the special case of "most of us are from Mozilla and we all get along[1]", "no-one has attacked us yet so no-one ever will[2]", "it's tracktable to untangle the dependency hell in your head because there aren't that many crates (yet)", and of course "we all know this history like the back of our hand, because we've all been around since v0.1 alpha." I'm picturing "10 years later" when some junior developer at MegaCorp Inc desperately tries to figure out why the legacy Rust 2018 version he's forced to use in 2032 can't compile some privately hosted crate that's needed for an enterprise project. It'll probably depend on a specific version of a crate that was yanked because some transitive dependency had to be yanked because that guy was a Russian kid that sold access to this popular crate for $500 to Israeli spies. Of course now the patched crate requires Rust 2030 or whatever, breaking fifty seven of the two thousand transitive crates being pulled it, so good luck to him with disentangling that mess and making this work. PS: I wish I was making this story up, but I basically just changed Angular to Rust for a real thing that happened to me, like... a month ago. There is no fundamental difference to how Rust does packages, it's just younger so the mess hasn't accumulated to Angular's levels of madness. Give it time... [1] Except for that spat with the core team. [2] That we know of. Ignore the guy spamming popular, single-word crate names and shovelling in 99.9% C/C++ code with the thinnest possible Rust wrapper. Surprise! Your code is now more C++ than Rust.

bowsamic 4y ago
Yep, the Rust team and even the wider community are literally just ignoring this problem under the justification of "it's too early to care about these things yet".
- pie_flavor 4y ago
  Rust has been designed specifically to avoid these problems, under the justification 'it's never too early to care about these things'. I wonder what on earth you have been reading.

mojuba 4y ago

I think static languages are generally more disciplined and manageable in this regard. The only times I struggled with 3rd party Swift code was when a package included some C or C++ code alongside with Swift. Specifically, I think Apple's philosophy of "everything comes with its own dependencies embedded" saved us a lot of trouble. Sure, it's more disk space and potentially lots of duplicates (just count the number of times various SSL libs are included in a single large and messy application), but it usually just works.

astrange 4y ago
MachO has some features that make this easier than ELF, namely matching libraries by full path and two-level namespaces (external symbols know which library they're found in). Though it's still not great if everyone uses their own SSL library, because then you can't update it if there's a bug.
- mojuba 4y ago
  Yes it's a problem, but because you (as a library maintainer) are responsible for what you are embedding, you should keep an eye on the dependencies and test them with each update. This creates a hierarchy of responsibilities, as opposed to a flat mess that is Linux .so or Windows .dll approach.
enlyth 4y ago
I had a similar experience with Rust when I first tried it a couple years ago. Wanted to make a web server which returns Hello World, and then this crate doesn't compile, this official example from the README throws a compilation error, that crate is the wrong version, etc etc. I tried again today and got it done in 2 minutes, so it seems things have improved.

hyperpallium2 4y ago

It is unique to old languages. Young languages are easy to get started in. Ruby used to be. Though ruby has a separate problem of breaking changes. The back-compatibility crowd can run old code (e.g. java), but at the cost of their soul.

lelanthran 4y ago
> It is unique to old languages. Rust is a new language, and it has the same complaints above.

bborud 4y ago

You are probably right, but there are differences. Languages like Go and Rust are much easier to get started with since they have better tooling, and more importantly, the tooling has a smaller and more regular surface. This is immensely important. Granted, they occasionally have unnecessary and stupid quirks, but they tend to be small (in terms of cognitive footprint) and contained. In my neck of the woods, Python is the major source of time spent trying to get other people's code to run on my machine. The path of least resistance for Python developers tends to produce code that requires you to go through an easter egg hunt to make it run outside the original author's machine. Yes, you could write Python utilities that are easy to install and run, but people don't. And the last bit of that sentence is the one that actually counts. "Could have" doesn't actually count in an engineering context. If the consumer has to assemble and repair software before getting it to run, the developer isn't being very professional.

Gigachad 4y ago

I'm also sympathetic to the author but don't really see it as a problem. NPM modules are not apps on the App Store. They aren't intended to just be run by regular people quickly. The steps described in the article show someone hitting Node.js with a hammer until it gets closer to doing what they want without any understanding of what is going on. Which is fine, that's what people do often, but it isn't a failing of the tools when this doesn't work. I don't expect to walk in to a workshop and find the welding tools intuitive to use with no training, and I don't expect npm modules to be intuitive to an outsider either.

lodovic 4y ago
Sure, but that is how it's sold: NodeJS and Javascript are marketed as super easy, perfect for beginners. They're not, in my opinion.
- trivialsoup 4y ago
  If you listen to marketers fast cars make you younger and handsomer and give you a full head of hair. Don’t look at how things are sold, look at how they are. In this case it’s code, of course there’s complexity.

psyc 4y ago

This is yak shaving. I mainly but not exclusively encounter yak shaving when, against my better judgement, I venture into the Opensourcelands. 10x more of it there, at any rate.

donatj 4y ago

I have been writing JavaScript professionally for nearly 20 years. I try my damndest to keep up, but the fact of the matter is the ecosystem is garbage. It’s really not a not-knowing-the-language thing. It’s a legacy of years and years of incompatible tooling requiring even more tooling to work around nightmare scenario. Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off. Nothing ever works like a sane person would expect. When I do get a working typescript + webpack setup it’s almost entirely by accident. I stumbled upon something that works? Just avoid touching it at all costs. Recently I wanted to load an AMD module in Deno and just about gave my self an aneurism before giving up hours later. I have worked in dozens of languages over my career, and not encountered as much of a clusterf*ck as JavaScript anywhere else. I have never worked with anything before where so few people had any idea how it actually worked and just prayed that it continues.

fendy3002 4y ago
> Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off Uh what? It's literally the name itself "node"_modules, it's designed to be used with node. The fact that it use same language and can later be used by browser is another matter. Thankfully we can easily bundle the whole thing using webpack nowadays. There are also countless boilerplate project with webpack setup already so you can get reference from there.
- marpstar 4y ago
  Not that I agree with the GP, but I think it’s easy to conflate “node”_modules with “modules from NPM”. Bower was once the recommended package manager for front-end assets, but NPM overtook it. I use Node daily, but 90% of my packages are front end.
  - fendy3002 4y ago
    Uh yeah, the fact that people using npm for frontend too means alternative front end package managers isn't as good (or as suitable) as npm. I take it as even though NPM isn't aimed for that, it works well.

the__alchemist 4y ago

I think C and C++ are a fair comparison in that their build ecosystems also a bit of a mess. I offer 3 counter-examples: Rust, Python, and JS-without-NPM. edit: After reflection, I think Python straddles a middle ground. If you use modern packages and Python 3, it can be a smooth experience. If you use older (improperly-specified) packages, or FFI-wrapped-libs, it can turn into a mess too.

lysecret 4y ago

this is why i love docker :D

tyingq 4y ago

There are some ecosystems where the experience is different. Perl, for example, does have deprecations, but not many. It's fairly common to be able to run 30 year old code unmodified, or with very minor changes. Of course, it has it's own issues, but it is very stable across time.

corrral 4y ago
One shock if you go back and forth between Javascript and, say, Java, is adjusting your library evaluation criteria. It's not weird for a Java project to include a library that hasn't had any updates in 4+ years. Sometimes those sorts of libraries are even considered the standard for whatever thing they do. Meanwhile in JS you have to assume a library with no releases in the last 6 months has already bitrotted to death.

deleted 4y ago

[deleted]

aeturnum 4y ago

I agree that the C family has some similar problems but I think you're missing part of what makes Javascript uniquely frustrating. Javascript is deployed in many different environments and you need to learn not just how to include a library in each environment, but also how to interact with that library. Also unlike C or other languages - Javascript has a hard time warning you about when you've imported something the wrong way. C can at least tell you "this does not link" (so it was found but is binary incompatible) - in my experience if you copy and paste a node import line in the browser the browser will just say "this does not make sense to me." C gives more breadcrumbs. I also think that once you get outside the C-likes, the story is universally better. For all of its packaging flaws, it's easy to get python packages for development. Every time I want to make something in Javascript I'm frustrated all over again by how I need to know details about the Javascript ecosystem that I have no way of knowing at this stage (like: getting to hello world can require a working knowledge of WebPack). It's just no where near that bad other places.

greggman3 4y ago
I get it's frustrating but ... do you expect any Lua to run in every environment Lua is used in? AFAICT no 2 Lua's are alike and nearly ever use of it has it's own APIs and quirks. I have the same issue with C. You can find some C that will run anywhere. You can also find lots of C that is platform specific and unless you're an expert you'll be just as frustrated trying to get it to run on a different platform. Seems the same to me.
- aeturnum 4y ago
  > do you expect any Lua to run in every environment Lua is used in? I do not, but again - I think "I should be able to run any version of a language in any place" is not related to "it is strangely hard to run a given Javascript file." I actually think Lua is a great example for comparison that illustrates the point! Different Luas support different features, but the basics (import statements, etc) are syntactically valid (and singular) in all of them. If you try to import a library that doesn't exist in the version you've embedded, you will get an import error. In Javascript - there are multiple import systems for different ecosystems. Getting an import error might mean you need to install the library, it might mean you're using the wrong convention, it might mean that the version of the library has a compilation error....etc. Javascript does not really help you resolve this. What this means is that there's a clean separation between environment and language. If your Lua deploy supports all the features your script uses, you are good - there are no "families" of Lua script that use different conventions for importing libraries or interop or whatever. A given piece of Javascript, however, has an arbitrary number of deployment-specific setup actions that require pretty advanced ecosystem knowledge to identify. Like, look back at the errors listed in the article. There's nothing "wrong" with the restrictions, but the language ecosystem does an unusually bad job of helping you understand and navigate them. Like, you can have two or three different import mechanisms for different environments...but if you want to do that you should be more helpful in pointing out when you're using the wrong one.