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

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

Post reply on HN
Print view View original

321–330 of 365 posts

Re: Hard-won lessons: Five years with Node.js

#321

Post by PerfectDlite »

rapsey wrote: post #163
sgift wrote: post #138

Earlier quoted context omitted.

> huge complicated tools. Oh please. Let's be real, Maven is not even remotely more complicated than the typical package.json, webpack.config.json, .babelrc triple you need for any useful NodeJS project (though you can put the .babelrc into the package.json, I've heard that's the way to do it at the moment). I was so taken back that nowadays JS needs a build step too. But it's a "transpiler", not a "compiler" - cause…

> So? Atom and Visual Studio Code did need to be installed too on my machine. This mentality reminds me of someone using an axe head as a hammer "I'd have to pull the hammer out of the toolbox" (install it) - that's too complicated, I prefer light-weight tools!" You misunderstand my point completely. I was trying to say the Java ecosystem is complicated and the only way it works is by using large IDEs. Saying how awe…

> because Java is unusable without them

This is like saying 'Javascript is unusable without IDEs', you know.

Re: Hard-won lessons: Five years with Node.js

#322

Post by PerfectDlite »

ben-schaaf wrote: post #318
empthought wrote: post #259

Earlier quoted context omitted.

You just described my experience with npm, except there aren't any useful tracebacks, just a note absolving npm of all blame and advising me to contact some random module author. Edit: and of course with npm the annoying downloads happen every time for each project, instead of once per dependency version...

Not excusing any crashes for npm (having those for any package manager sucks), but `npm init` doesn't download anything or make a project that needs to, it has readable config files and `npm --help` at least gives you a list of commands. A lot of the small stuff goes a long way to making things more approachable.

> `npm --help` at least gives you a list of commands

`mvn --help` gives you a list of commands too.

Re: Hard-won lessons: Five years with Node.js

#323

Post by jerryszczerry »

PerfectDlite wrote: post #321
rapsey wrote: post #163

Earlier quoted context omitted.

> So? Atom and Visual Studio Code did need to be installed too on my machine. This mentality reminds me of someone using an axe head as a hammer "I'd have to pull the hammer out of the toolbox" (install it) - that's too complicated, I prefer light-weight tools!" You misunderstand my point completely. I was trying to say the Java ecosystem is complicated and the only way it works is by using large IDEs. Saying how awe…

> because Java is unusable without them This is like saying 'Javascript is unusable without IDEs', you know.

And this is making Java look good how exactly?

Re: Hard-won lessons: Five years with Node.js

#325

Post by crimsonalucard »

Safety1stClyde wrote: post #38
crimsonalucard wrote: post #32

Too many lessons learned and arbitrary rules to follow equals flaws with design/language design

What language does not have these kinds of problems? I have encountered them with every programming language.

Take for example Elm. Elm has no runtime errors, the concept just does not exist in that universe. That's a whole series of gotchas that don't exist.

Re: Hard-won lessons: Five years with Node.js

#326

Post by brlewis »

mattmanser wrote: post #303
brlewis wrote: post #285

Earlier quoted context omitted.

>Sometimes it really is justified. Like in the situations in the article. That's why the comment in question is not just blunt. It's a bad comment. A good comment would take a specific instance of using logging and said why setting a breakpoint / using a debugger would have solved that particular mystery faster.

I've read the article. Obviously I haven't seen the actual problem, but as an experienced developer, I feel that: NaN bug doesn't sound like it needed logging Mutability bug doesn't sound like it needed logging Dependencies and versions bug doesn't sound like it needed logging The Documentation and versions bug doesn't sound like it needed logging Obviously we're not seeing the whole picture or the whole bug. But tha…

My comment about the NaN bug: https://news.ycombinator.com/item?id=14156595

Re: Hard-won lessons: Five years with Node.js

#327

Post by specialist »

lasfter wrote: post #15

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?

You're not wrong.

InterSystems Caché is easily the worst tool I've ever used. A typo in your code often caused the compiler to bork your entire runtime. Not kidding.

Node is almost that bad. Stately as nicely as possible: it's syntactic vinegar for a type hostile flow of control obfuscation framework.

If you have some irrational need to use libuv (callback hell vs actors, CSP, multithreaded NIO, or AIO thread per connection), you're much better off just using 'C'.

Re: Hard-won lessons: Five years with Node.js

#328

Post by int_19h »

joekrill wrote: post #195
int_19h wrote: post #113

Earlier quoted context omitted.

What really scares me about the Node ecosystem is bugs like these: https://github.com/npm/npm/issues/10999 https://github.com/npm/npm/issues/9633 I have personally hit both while trying to build (not even write!) Node software. The former bug is an example of "broken by design", and it's interesting that it remains open (therefore admitting that it is a problem?), but no solution came yet. Although I believe Yarn doe…

Technically those are NPM bugs, not Node bugs. And Yarn seems to do a much better job these days.

That's why I said "Node ecosystem". NPM is definitely a part of said ecosystem, and it still the de facto standard package manager (which, also - why, when there's Yarn?).

Re: Hard-won lessons: Five years with Node.js

#329

Post by cookiecaper »

josteink wrote: post #320
cookiecaper wrote: post #313

Earlier quoted context omitted.

Syntax errors will be detected prior to runtime because the application will not be able to be compiled into whatever format it compiles down to (raw ASM, some IR, etc.). A fully AOT compiler will generally check more than a JIT compiler, but there is still compilation and it is still a "compiler" in a technical sense. And for the record, AOT languages also have "runtimes" provided by a platform. If someone combined…

It is my understanding that V8 provides you with the capability to interpret your code and run it, while gcc produces a resulting binary which be run independently of gcc. Can V8 be used to compile js to a artifact/binary which can later be executed independently of V8? If no, then it's not a compiler. It's as simple as that.

Executables from gcc can't be run independent of a binary-compatible C runtime.

The difference is just that V8 includes the runtime and compiler in the same program. If they split it into v8c and v8lib without making any changes to the way that JavaScript is converted into something that your CPU processes, would it then be a "real compiler"?

Are mcs or javac real compilers? They both leave behind an "executable", but they require a separate runtime to be installed actually execute it. What about GCJ? What about anything that compiles down to LLVM IR and depends on LLVM to convert it to machine code? Is that not a real compiler either? Is CPython a compiler? It leaves junk on my disk in the form of pyc files.

I'm really curious why you insist that something isn't performing compilation if it doesn't write its output to disk. When is the process of compiling from one target into another not compilation?

Perhaps you're suggesting that only compilers that emit appropriate machine code are "real compilers". That's silly, but I could understand if that's what you mean.

However, I think you'll be disappointed to learn that V8 does directly emit machine code. [0]

[0] https://github.com/v8/v8/tree/master/src/compiler

Re: Hard-won lessons: Five years with Node.js

#330

Post by mattmanser »

cookiecaper wrote: post #308
mattmanser wrote: post #303

Earlier quoted context omitted.

I've read the article. Obviously I haven't seen the actual problem, but as an experienced developer, I feel that: NaN bug doesn't sound like it needed logging Mutability bug doesn't sound like it needed logging Dependencies and versions bug doesn't sound like it needed logging The Documentation and versions bug doesn't sound like it needed logging Obviously we're not seeing the whole picture or the whole bug. But tha…

Interactive debugging is a useful tool, but it can encourage lazy reasoning. People just write something and step through until they notice some change they don't expect. That's fine and everything, but talking about "crutches" and tooling, it sounds like you may be a little biased toward big-IDE style development that makes the debugger the automatic answer v. some reasoning over the code and extra logging of potent…

Logging is lazy reasoning. Stepping through is simply seeing what is happening with a bug you can replicate. Stepping through is the step in debugging after reading the code.

Even after you've read the code and think you've spotted the problem, you should step through to 100% confirm you've understood the problem.

It's simply confirming the bug and the solution, it's good science, it's good practice. It's empirical.

Post reply on HN