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

Things I Regret About Node.js [video]

youtube.com

Post reply on HN
Print view View original

491–500 of 502 posts

Re: Things I Regret About Node.js [video]

#491

Post by humbleMouse »

swsieber wrote: post #481
humbleMouse wrote: post #339

Earlier quoted context omitted.

If you limit the annotations to only the basics,(controller,config,bean,requestmapping,etc.) - not much can go wrong. It sounds to me like you haven't worked with any large spring boot apps and experienced the stability annotations can provide.

Except circular dependencies. I work on an app where a circular dependency failure happens depending on what order spring finds our annotated classes. It made writing a faster bean scanner a little tricky because I had to replicate Springs ordering method.

To clarify what you said - You wrote a custom "fast bean scanner" and it's not working properly? Or you had to re-write it because spring's bean scanner wasn't working? What version of spring is this?

Re: Things I Regret About Node.js [video]

#492

Post by swsieber »

humbleMouse wrote: post #491
swsieber wrote: post #481

Earlier quoted context omitted.

Except circular dependencies. I work on an app where a circular dependency failure happens depending on what order spring finds our annotated classes. It made writing a faster bean scanner a little tricky because I had to replicate Springs ordering method.

To clarify what you said - You wrote a custom "fast bean scanner" and it's not working properly? Or you had to re-write it because spring's bean scanner wasn't working? What version of spring is this?

Ah, the spring bean scanning was working, but startup wasn't. The reason? Our app was apparently very brittle and the mere act of registering beans in the wrong act would cause a circular dependency error during startup.

To be more concrete, to the original spring bean scanner, we were passing in a set of package names, which it would scan. Spring registers those bran defininitions in yhe order that it scans the beans. My custom scanner (found and registered all the same beans), broke our app because it wouldn't startup anymore due to a circular dependency error. Once I sorted the bean definitions by the original pack path inputs, that startup error went away.

I think we are 4.x

Extra details: I used the fast -classpath-scanner library. I subclassed the annotation cand date componend scanner class (well, something like that), and rewrote a method to load the resources for the string specified, treating the path a a fqcn, not a package path. Then I could feed that class the output from the fast classpath scanner (which was the list of classes with the annotations). Until I sorted the input by the original package paths, my app wouldn't start. Mind you, the method I overwrote simply created bean definitions. But that ordering difference made all the difference.

I can dig up exact class names if you are curious. The scanner of course didn't replicate all spring bean sear check capabilities - just the ones we were using. But it cut the scan time by 60% (several seconds).

Re: Things I Regret About Node.js [video]

#493

Post by sametmax »

manigandham wrote: post #490
sametmax wrote: post #478

Earlier quoted context omitted.

I'm having a hard time understanding what's fascinating about typescript. I agree it makes JS better. I agree it's a good tool for its purpose. But "fascinating" ? It's hardly the most elegant scripting language down there (Ruby, Python, Kotlin and Dart doesn't have to live with the JS legacy cruft). It has a very small ecosystem outside of the web. The syntax is quite verbose for scripting. It has very few data stru…

Typescript IS javascript, so of course it inherits all of its problems. The data structures and standard libraries are what you get from JS, nothing more. It's called a programming langauge but its more of an extension to JS with a powerful compiler. The typing system is what is special though, especially in how seamless it is in adding strict types alongside pure dynamic objects, but also allowing you to choose pret…

> Typescript IS javascript, so of course it inherits all of its problems. The data structures and standard libraries are what you get from JS, nothing more. It's called a programming langauge but its more of an extension to JS with a powerful compiler.

That's pretty much my point.

> he typing system is what is special though, especially in how seamless it is in adding strict types alongside pure dynamic objects, but also allowing you to choose pretty much anything in the middle of that spectrum depending on your definitions.

> You can have a few strong-typed properties mixed with others in a generic type that inherits from something else but can only take a few certain shapes. It's unlikely you need all that in most programs but it's the fact that you can do it which makes it great. In fact, the Typescript type system is actually turing complete.

Apparently you haven't read my comment because I clearly says it's not special. Others languages do it to.

> Perhaps this video on Typescript from Build 2018 would help: https://www.youtube.com/watch?v=hDACN-BGvI8

Perhaps this article would help: https://www.bernat.tech/the-state-of-type-hints-in-python/

Re: Things I Regret About Node.js [video]

#494

Post by mncharity »

kbenson wrote: post #322
allover wrote: post #237

Earlier quoted context omitted.

> You'll find much harsher critics of Node/NPM in these parts! They're ill-informed. GPP is correct that, for example pip is fundamentally inferior to npm [1], and those that insist on throwing shade at npm on HN should be corrected. They're wrong, and insulting a sound, well maintained project, without basis. [1] https://github.com/pypa/pip/issues/988

> those that insist on throwing shade at npm on HN should be corrected. Preferrably by giving them better ammunition, since I do see NPM as substandard in quite a few ways, which is inexcusable when there do exist examples to learn from (whether it be a positive or negative influence). First, it helps to clarify whether we are talking about npm the client or NPM the repository and ecosystem . Client issues are genera…

> there are some obvious things that could be done to greatly improve it [...] it could be so much more

As with much of programming language design and implementation over the last 3+ decades?

below> that could have been mitigated or entirely avoided by surveying best practices

Yes, people who would spend their time working on language designs and implementations, should at least be familiar with the many surveys of best practices. Surveys of repos, type systems, memory layout, parallelism, and so much else. Language choices are intertwined and subtle, and adhocery has enormous downstream costs to the field and to society. The programming language design and implementation wiki exists for that reason. To accessibly distill our collective experience. Not using these resources is negligent - a disregard of our profession's responsibilities to society.

Oh, wait. Our field can't be bothered to create surveys of best practices. Or a wiki. Knowledge is inaccessibly dispersed among balkanized and siloed human communities, assorted academic papers, and scattered code.

Shall we continue to blame pervasive failure on individual language developers and tools? For how many more decades? At what point do we start addressing it as a systemic problem?

:) So I agree with your observation, but suggest the problem extends far beyond package management systems.

Re: Things I Regret About Node.js [video]

#495

Post by Rapzid »

aphexairlines wrote: post #366
bschwindHN wrote: post #302

Earlier quoted context omitted.

> NodeJS really does solve the problem around the "many simultaneously persistent connections", something that would be really hard to do without something like NodeJS What part of it is really hard to do without NodeJS? You can do this easily in Go, Elixir, C++, Rust, etc.

The nice thing about Node.js's design is that (almost) all IO is non-blocking by design, so developers can't block their programs on IO by accident. In other platforms developers need discipline to choose non-blocking APIs over blocking ones, or to wrap their blocking calls in async execution contexts like threads or coroutines.

All the "sync" commands are blocking. In my experience developers need discipline to avoid using those and blocking the whole app.

Of the languages mentioned I believe Go is actually closest to all io being non blocking by default; with the caveat that you are using multiple go routines.

Re: Things I Regret About Node.js [video]

#496

Post by devxpy »

jzoch wrote: post #466
algesten wrote: post #336

Earlier quoted context omitted.

I love rust, but the standard libraries are nowhere near the same abstraction level of nodejs. All services I've deployed built on rust pulls in a kitchen sink of deps. Granted. I get a static binary as my end result, so maybe it's fine.

Rust is designed that way, to be fair. They expressly did not want to be batteries included like python is. The reasons are what they are and not particularly relevant to the conversation, but pulling in well designed third party crates is the point.

Speaking from a python user's perspective, the batteries included philosophy works great when you have a neutral implementation. Python does a good enough job, and provides extensibility in a way that I don't need to download a package to do basic things. On the other I have to spend hours trying to find a package in JS that just gets shit done. The third party package way is only required for ui parts because you don't want everything to look generic. But having a good standard library to do non user facing stuff is essential. That's why every node project ends up with a thousand dependencies. Because the language is not batteries included. There in JS there is no "one correct and obvious way to do everything" which makes doing basic programming painful.

Re: Things I Regret About Node.js [video]

#497

Post by grosjona »

PinkMilkshake wrote: post #343
grosjona wrote: post #341

Earlier quoted context omitted.

Yes so true. People should spend more time thinking about the side effects of their actions and speeches before they make them.

No, people should speak what they believe to be true. The onus is on the listeners to not blindly accept everything they hear as reality.

When an authority figure says something, listeners are more likely to accept it, even if it is wrong. That's just human nature. So authority figures have an extra duty to think about the effects of what they're saying.

They owe their success to these people and so the way that they can pay it back is by using their voice as a tool for improving things.

Re: Things I Regret About Node.js [video]

#498

Post by irrational »

lgas wrote: post #315
irrational wrote: post #223

Earlier quoted context omitted.

The problem is, how do we know that those shouting warnings are not false prophets?

Presumably by reading and understanding their arguments.

But, how do we know which ones we should be reading and understanding their arguments?

Re: Things I Regret About Node.js [video]

#499

Post by ninjakeyboard »

pera wrote: post #255
ninjakeyboard wrote: post #108

Earlier quoted context omitted.

what is the 15% figure from? I'm suddenly working with a dynamically typed language (elixir) coming from scala and I do find more bugs. Would like some hard evidence to support that so just curious.

Have you tried to use Dialyzer or Dialyxir and typespecs?

no. I probably should.

Re: Things I Regret About Node.js [video]

#500

Post by ninjakeyboard »

maerF0x0 wrote: post #132
ninjakeyboard wrote: post #108

Earlier quoted context omitted.

what is the 15% figure from? I'm suddenly working with a dynamically typed language (elixir) coming from scala and I do find more bugs. Would like some hard evidence to support that so just curious.

15% is from this paper as I recall it: http://ttendency.cs.ucl.ac.uk/projects/type_study/documents/... https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...

thanks!
Post reply on HN