Hi, I am Darren, and I love JS - I will no longer be ashamed by it.
Hi, I am Darren, and I love JS - I will no longer be ashamed by it.
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.
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.
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.
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.
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).
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.
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.)
Bugs happen but it's by no means a constant 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).
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.
That is the problem. You love a hammer and see nails everywhere.