Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The tragedy of running an old Node project

abdisalan.com

Post reply on HN
Print view View original

231–240 of 412 posts

Re: The tragedy of running an old Node project

#231

Post by regularfry »

fredrikholm wrote: post #171
regularfry wrote: post #124

Earlier quoted context omitted.

Clojure too, by all accounts. I'd say Common Lisp but they're in the weird position of code itself being rampantly portable across time but the ecosystem around it being astonishingly immature.

Things have improved a lot with the introduction of Quicklisp, but I'd have to agree when compared to others. CL is still one of the nicest languages there is, and the only language that skirts the line between being some combination of dynamic and interpreted yet typed and compiled. It is showing its age though, particularly around the edges like what you're saying.

Quicklisp is a start, and I like that it's a Debian-style distribution because it can at least move towards making the assertion that everything in the distribution is mutually compatible. The problem is that the underlying ecosystem has no culture of saying "version X of library A is only compatible with versions Y+ of library B". You can put that info in the asdf system definition but I don't see many examples of it.

The other problem is rate of updates, and that's a symptom of it basically being on one person's shoulders to keep it ticking over. I can't readily think of another major language ecosystem with that characteristic. It just seems really fragmented.

Re: The tragedy of running an old Node project

#232

Post by liontwist »

peutetre wrote: post #147
yen223 wrote: post #146

Earlier quoted context omitted.

JavaScript will be killed off by webassembly for about 5 years now

The difference lately is the number of tools that are now in place for WebAssembly development and the new extensions to WebAssembly (WasmGC, Memory64, etc.). Despite 28 years of effort at optimization, JavaScript is outperformed by WebAssembly. There's not much coming back from that: https://jordaneldredge.com/blog/speeding-up-winamps-music-vi... https://www.amazon.science/blog/how-prime-video-updates-its-... https:…

?? JavaScript was outperformed by every language since it was introduced.

It doesn’t matter. What matters is what people put in their web pages.

Re: The tragedy of running an old Node project

#233

Post by ivan_gammel »

andai wrote: post #226
ivan_gammel wrote: post #179

Earlier quoted context omitted.

I still can open my decade-old Java projects, run build with modern Maven/JDK and get working code - in a few minutes. Two hours of dancing with a drum doesn’t feel acceptable to me.

I spent an hour or two figuring out how to even download Java, whether I need to give Oracle my home address, use a third party JDK etc. Then it turned out the standard built in GUI library I needed was no longer standard or built in. (I also used it ten years ago and it was a much better experience then.)

Well, I would spend probably similar time to get started on Pascal, which I used last time in the previous century. I would not blame Pascal for it though.

Re: The tragedy of running an old Node project

#234

Post by secondcoming »

Ameo wrote: post #112
elashri wrote: post #110

Earlier quoted context omitted.

You can't use 'pip install' in debian because they chose to do that during the transition from python2 to python3. You should use 'pip3 install' which is provided by package python3-pip from debian. One can argue that this decision should be revised by debian but you should not install packages on system python installation for working into projects. Always use virtual environment.

No that does not work either. You get an error like this: » pip3 install supervisor error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. As far as I can understand, they did this on purpose to dissuade users from installing packages globally to avoid conflicts with oth…

Encountered this too. So annoying.

Re: The tragedy of running an old Node project

#235

Post by liontwist »

regularfry wrote: post #231
fredrikholm wrote: post #171

Earlier quoted context omitted.

Things have improved a lot with the introduction of Quicklisp, but I'd have to agree when compared to others. CL is still one of the nicest languages there is, and the only language that skirts the line between being some combination of dynamic and interpreted yet typed and compiled. It is showing its age though, particularly around the edges like what you're saying.

Quicklisp is a start, and I like that it's a Debian-style distribution because it can at least move towards making the assertion that everything in the distribution is mutually compatible. The problem is that the underlying ecosystem has no culture of saying "version X of library A is only compatible with versions Y+ of library B". You can put that info in the asdf system definition but I don't see many examples of i…

Quicklisp is merely a registry for getting libraries, not shipping code. Download what you want and use asdf.

Re: The tragedy of running an old Node project

#236

Post by ivan_gammel »

cesarb wrote: post #225
lowboy wrote: post #221

Earlier quoted context omitted.

Well, the article is about npm, a package manager for node. Vendoring dependencies into source is a choice, albeit one that I don't often reach for.

> Well, the article is about npm, a package manager for node. And Maven is a package manager for Java. The main difference IMO? The usual way to do things in Maven is to always use exact versions for the dependencies. When I specify I want some dependency at version 1.2.3, Maven will use version 1.2.3 of that dependency even if 1.2.4 or later already exists.

Maven is also stable and requires only JDK to run. You can unzip it to desired location and add to PATH - it will be ready to go in a couple of minutes.

It will not build all old projects out of the box, of course. Specific versions of plugins may not be compatible with it or some dependencies may break on modern JDK. But chances of hitting this issue are much lower than in JS/NPM ecosystem.

Re: The tragedy of running an old Node project

#237

Post by secondcoming »

j1elo wrote: post #186
regularfry wrote: post #122

Earlier quoted context omitted.

My slightly heretical opinion is that Debian would have been better off removing system pip entirely. The system python is for the system.

My not so heretical opinion is that PIP should behave like NPM by default, and work under a local environment subdirectory, just like "npm install" already creates a "node_modules" directory where to put all files, without the user needing to specify how and where and which env tool to use.

Python is a scripting language. I shouldn’t need to faff about with environments if I want to run my script on another machine.

Re: The tragedy of running an old Node project

#238

Post by regularfry »

j1elo wrote: post #186
regularfry wrote: post #122

Earlier quoted context omitted.

My slightly heretical opinion is that Debian would have been better off removing system pip entirely. The system python is for the system.

My not so heretical opinion is that PIP should behave like NPM by default, and work under a local environment subdirectory, just like "npm install" already creates a "node_modules" directory where to put all files, without the user needing to specify how and where and which env tool to use.

Ah, but that would require that the python interpreter look first in the local directory in case there's a virtualenv there, which would mean your system could break depending on which directory you ran bits of it from. Less than ideal.

It's better all round to just assume that unless you're building something to be a part of the system itself, that the system interpreters just aren't for you. There's a special case for shells where they're actually UI, but I've seen so much effort wasted over the years trying to let system interpreters do double-duty as both system tools and development environments that I've come to the conclusion that it's simply not worth the hassle.

Re: The tragedy of running an old Node project

#239

Post by regularfry »

liontwist wrote: post #235
regularfry wrote: post #231

Earlier quoted context omitted.

Quicklisp is a start, and I like that it's a Debian-style distribution because it can at least move towards making the assertion that everything in the distribution is mutually compatible. The problem is that the underlying ecosystem has no culture of saying "version X of library A is only compatible with versions Y+ of library B". You can put that info in the asdf system definition but I don't see many examples of i…

Quicklisp is merely a registry for getting libraries, not shipping code. Download what you want and use asdf.

Yes, that's what makes it immature. There doesn't seem to be anything in the ecosystem to handle version resolution. Qlot is a start towards that in that you can at least specify alternatives to get yourself out of a hole, but you still ended up in the hole in the first place.

Re: The tragedy of running an old Node project

#240

Post by pier25 »

JansjoFromIkea wrote: post #209

node-sass is to blame for like 95% of these node-gyp issues in my experience, it's not that much grief to deal with but it's hard to grasp how it was allowed to hang around so terribly for so long

> it's hard to grasp how it was allowed to hang around so terribly for so long

It's not hard. The explanation is simply that the dart version of SASS (the sass npm package) is much slower than node-sass.

At one point it was like 20x slower and I believe right now it's about 2-3x slower.

https://github.com/sass/dart-sass/issues/1534

Post reply on HN