If you want a language that requires zero learning to use, I am sad to say that they are very far and few between. Sure, we have a clusterf*ck of a module ecosystem and interoperability issues between preprocessors but it isn't like that is a particularly novel problem either.
>The cmake build is doesn't work without -GNinja (you do have ninja installed, right?)
>No actually use Bazel/Buck/Pants/Meson
>Oh you installed $DEP, but not the right $DEP with $DEP-X support
>pkg-config can't find $DEP-X
>Pre-build $DEP-X was built with GCC N, and you have GCC N-1, try building from source
>GOTO 1 for DEP-X
I'm embellishing here, but I feel like I always do some version of this song and dance when trying to build a C++ project. And then after all that is done you somehow still end up with linker errors in your final project.
For most people installing some C/C++ library it's just "apt-get install libfoo" (and maybe libfoo-dev), and they never have to deal with ninja/autotools/cmake/etc, whereas for JavaScript you directly have to deal with the tooling by using "npm install libfoo".
The same task mentioned in the article would probably be a lot easier: install package, write some code, "c++ -lfoo main.cpp".
I'm not saying JS is perfect, or that other languages don't have these issues. I haven't used Rails in years but I remember spending a day trying to get a gem installed and figuring out why nokogiri wouldn't compile. Almost every language has these problems.
That's how you get quality user experience. It creates balance between developer of the library/tool and the user of the library/tool.
Most of the time we would create a minimal CMake file to build the library to our specs or adapt the existing CMake file.
Or, hell, how about the packaging systems in Go or Python? "Yeahhh, we don't really use X anymore, go ahead and use Y."
John certainly failed the perseverance test though.
In John's case, even after he got some help he still couldn't set up and run the project which is really frustating.
oh look, another one
I've used it for some personal projects, but doubt that I'll use it for anything paid anytime soon.
With javascript? Well, for instance, take Expo's official release notes for each new SDK and it's right there, as the recommended practice: wipe out your `node_modules` folder and run `yarn` again every time. And good luck not having your `yarn.lock` file randomly changing versions after a while.
It's just a single silly example, but it tells how much more stable the ruby development experience is.