Meh, I feel a little like this is dunking on Javascript for the sake of dunking on Javascript. Ever done the same with a PHP app? Go? Python?! They all have issues with versioning and this is why there are a good set of tools to deal with it - pyenv/nvm etc. It's like they've listed all the good reasons to use JS and then kicked it because it's cool to hate on JS.
Hi, I am Darren, and I love JS - I will no longer be ashamed by it.
I can come back to a go module I write today months later and do a build. `go.mod` specifies exactly what version of what dependency I used, and `go.sum` provides the checksums. Even if the original repo was shut down, there is a good chance the `GOPROXY` I use has it cached, and failing that, if I am really worried about long time availability of dependencies I can always do a `go mod vendor` and check everything in my own repo.
Heck, I think half a year ago, I unearthed a project I wrote in Go1. ... I think 6? 8?, Anywho, way before modules were introduced. All I had to do to get it to build was a `go mod init app && go mod tidy`.
And all of this is baked into the official toolchain that comes with the language. So is testing, benchmarking, documentation-generation. As a bonus, the official proxy provides a handy way for package discovery, but without relying on any one centralized repository to fetch said packages.
The language itself doesn't change a whole lot, and by design encourages a straightforward and to-the-point style of doing things, (at the cost of being somewhat verbose sometimes, but I think that's an acceptable tradeoff). The result (and also a big thanks to `gofmt` at this point) is a coding style that is pretty consistent between many modules written 5 years ago and projects started yesterday. The designers make sure that newer versions of Go itself don't break things, with even generics not breaking any backwards compatibility.
And if I want to upgrade a dependency, there are only 2 possible outcomes: Either the go-tool can resolve the dependency graph to something that works for everything in the project, or it cannot. Either way, provided I `go mod vendor`ed, I won't end up in a situation where I just cannot build any more.
I use go a lot and also love it. I did find it odd in the early days to not have a package manager, but they seem to have mostly built on the experience of NPM and got it right.
Yeah, the initial days were indeed odd, and modules absolutely required, otherwise the ecosystem would probably be a tangle of different 3rd party solutions for vendoring and version-pinning right now. Glad they avoided that.
They were building in the right direction with the idea that a world where public code repositories exist, a) doesn't need yet-another-repository for just one language, and b) should acknowledge the real world by specifying these resources directly in the code.
Not on this scale. Let's leave out the versions of the NodeJS for clarity's sake (nvm is not for managing packages, afaik), and focus on packages. You could argue that the complexity is because of JavaScript's popularity, but it's hard to deny that running a seemingly simple `npm install` will net you tons of dependencies, and that's typical regardless of what you're installing.
Yeah this is really the Achilles heel of the node ecosystem. It turns out having an expansive standard library is important since I'd like to think most of these issues would disappear if that were the case.
In my opinion Python modules are rarely "one function" dependencies. And while the ecosystem is certainly enormous, so is the standard library, so for many common tasks, I don't even need to `pip install` a new dependency.
Yes, "virtual environments" used to be kind of messy, and the fact that there are usually 2 competing ways to install modules (via the OS pkg manager and pip) doesn't help either. But since `pyenv` and `venv` exist now, venvs are much less of a hassle than they used to be.
>Hi, I am Darren, and I love JS - I will no longer be ashamed by it.
Don't make a programming language part of your identity. It's pathetic.
No one is "dunking on Javascript for the sake of dunking on Javascript." PHP, Go and other languages don't have these issues, or at best don't have them at the same frequency, nor are they as catastrophic when they occur.
No PHP dev ever woke up to discover the entire universe was broken because some rando who owned the function that left-aligned text in terminals deleted their repo in a fit of pique. Other languages vendor dependencies by default. Other developers use libraries which contain more than a single function so their dependency trees are shallower and less brittle. Other developers are less allergic to actually writing code than Javascript developers, so less of their application is offloaded to remote dependencies.
This isn't a JS issue, it's an ecosystem and culture issue. Back in the ancient days of JQuery modules, none of these problems existed. They're the result of Javascript being co-opted by SV and corporate interests. The necessary evils of piling on complexities in order to get the language to do things it wasn't meant to do, in contexts it wasn't meant to operate in, because money.
Hell, a lot of JS' problems stem from the fact that - alone among programming languages as far as i'm aware - JS development all but requires using another language entirely. No one writing Python actually uses a strictly typed "superset" of Python that compiles to Python, because they consider actually writing Python directly to be too dangerous. That would be ridiculous. Yet in JS, it's essentially mandatory.
Yeah, sorry but JS is kind of a comedy of errors right now, and it's never going to get better if people refuse to see its faults.
My dude, have you lived in the tech (or otaku) community for long?
Making a piece of tech (or any media) part of your identity is a tale as old as time, and arguably getting worse.
I mean, you’re right, it is pathetic, and we need to collectively grow up. But
you might as well be saying “be a well adjusted person, eat well and exercise”. We are so insecure and needy that we ascribe our self worth to a tech fad or piece of media or media figure. But it’s the core problem we have in western society today: geek/otaku culture, with its highs and lows, has gone mainstream. We are so comfortable and abundant with basic resources that we are bored and unsatisfied with our status and function in society and desperate to fill that gap with something to geek out on.
We live in a world where Lennart Poeterring gets death threads over systemd, the Golang maintainers get threats over generics, TV show runners get death threats when they change a character’s story arc. And politically there’s lots of folks willing to eject democracy so their adopted club can rule for eternity. Is it all for the lulz?
Anyway I took this on a tangent but… really, “I can’t believe you use that programming language” has always been bad as far as I can remember (at least 35-40 years).
There's nothing wrong with making a language part of your identity but Darren is not even doing that, he simply said he loves JS.
I don't identify as a Python dev and I don't even work with Python much lately, I know package management isn't great and PyPI registry suffered malicious attacks recently, but I can still say I love Python, I started with it and the syntax is enjoyable.
But you are clearly making language hate part of your identity.
(BTW I'd actually thank JS for TS, if they added types natively they'd probably be limited like Python's and we'd be stuck with it, but they didn't so now we have a new language with a great type system that evolved beyond JS with variations that compile into WASM and such.)
Yeesh this really kicked off but thanks for the defence. For clarity I identify as a male programmer with Lego loving tendencies. JS is simply a tool I actually mostly enjoy using. I also use a lot of other languages, but really JS is one I'm always happy to come back to!
> No PHP dev ever woke up to discover the entire universe was broken because some rando who owned the function that left-aligned text in terminals deleted their repo in a fit of pique.
You act as if this is something that was forced upon you.
Giving some "rando" the power to "own" a function in your app is a power that you choose to give them. If you don't want that then don't do it.
Sentences like "Other languages vendor dependencies by default" are nonsense statements. Stop saying "language" when you mean "the kind of people I do/don't have a problem with".
> This isn't a JS issue, it's an ecosystem and culture issue.
Right, and when people tacitly insist otherwise—by being sloppy with their words and thoughts—then it makes it harder for people to recognize the problem, see what specifically needs to be fixed, and then proceed with the "okay, let's fix it now" part.
Python has a completely different issue and that is that its dependencies on c extensions makes cross platform or cross version packaging a terrible thing.
This is why I get a bit puzzled when people complain about the Java build system. It's so much saner in comparison to the scripting languages, and arguably better than Go or Rust (though I'll take any of the three over Python or JS).
> Python has a completely different issue and that is that its dependencies on c extensions makes cross platform or cross version packaging a terrible thing.
Well java has no way to do a unix socket unless we rely on a C extension so it's hardly better in this respect.
Well that's a judgement call I'm afraid you have wrong. JS is a great solution to some problems, as is Go, as is Rust, Ruby etc etc. I love JS for what it's good at - things like making web apps a reality, allowing a single language to be a start point for devs etc. I certainly don't use it exclusively.
Hi, I am Darren, and I love JS - I will no longer be ashamed by it.