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

301–310 of 365 posts

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

#301

Post by zlynx »

jimmaswell wrote: post #292
root_axis wrote: post #280

Earlier quoted context omitted.

Frankly, I find your condescending insults to "x-developers" to be a sign of unsophistication, that aside, in my experience, logging is preferable to running a debugger in most situations. Logging gives you an immediate output about the particular state you're concerned with as opposed to using a debugger which slows you down while you fiddle with breakpoints, slowly step through code, hover your mouse over variables…

Are you really implying writing a bunch of print statements is more "professional" than a debugger? Debuggers are incredibly useful in tracking certain things down and don't make you write and then remove a ton of logging statements. Sometimes logging is easier, sometimes debugging is, and not just for "junior devs".

I agree that debuggers aren't always the right tool. Use it only when you have a reproducible bug configuration running on your desktop.

There are fancier setups than "print statements", like binary lock-free logs to circular memory maps. But in essence, print statements, yes.

And heh, I just realized that if you're using a debugger with reversible execution tracing, you're using EXACTLY a binary log file.

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

#302

Post by curun1r »

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?

I can say why I chose it and why I no longer choose it anymore. For me, JavaScript was the price I had to pay for a number of other benefits. I don't like the language, but TypeScript, Coffeescript and the like can paper over some of the deficiencies well enough. But what Node is is more than just JavaScript.

It's a fast, well-designed runtime written in C++ with the event loop as a central construct. It's an ecosystem where async is the default and you don't have to work hard to get performance and scalability in that area. And it has a fantastic package management tool. The quality of the packages that npm installs may not always be high, but the tool itself is so much better than pip, maven/gradle, gem, cpan, etc.

I've moved on from Node because I've found nearly all the benefits of Node available in Rust. Rust has the performance of Node's C++ runtime, easy event loop with tokio, and cargo is the one package manager that I think betters npm. And with wasm, we're even starting to see the possibility of sharing code between the server-side and client-side. Add to that the ability to use it anywhere that Node can be used (I'm using Rust now with Lambda without a single line of JavaScript), and there's now no reason for me to put up with the hassles that using such a poorly-designed language as JavaScript imposes.

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

#303

Post by mattmanser »

brlewis wrote: post #285
mattmanser wrote: post #282

Earlier quoted context omitted.

It's not a bad comment, it's just blunt. I also have a similar stories as the parent commentator, 8-10 years ago when you had even more awful programmers I would sometimes agree to fix something for someone desperate as their own coder had disappeared/failed/etc.. Sometimes even in a language I'd never even used. I'd open some random PHP project, or VBScript, or whatever and find loads of commented out print statemen…

>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 that's 4/5. Most of those sound like they needed a simple step-through.

For example, in the documentation and versions async.js bug, he added "extremely verbose" logging where it appears that a simple step-through would have immediately revealed to him the passed arguments were wrong and the signature of the method didn't match the documentation. Which would have made him realize he had the wrong version.

The only one where I would expect to have to use logging is the tests bug.

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

#304

Post by foldr »

empthought wrote: post #258
foldr wrote: post #252

Earlier quoted context omitted.

It's not a macho thing for me. I use the tools that are easiest to use and do the job. Anyway, I have used a lot of different programming languages, and it's the Java ecosystem specifically that I've always found overwhelming whenever I've tried to dabble with it. So I think the problem is Java, not me.

There's nothing "macho" involved in this, your language describing your own state of mind is inflammatory and (hopefully, for your sake) inaccurate.

You may need to expand your comfort zone with regard to mild hyperbole.

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

#305

Post by foldr »

srpablo wrote: post #277
foldr wrote: post #219

Earlier quoted context omitted.

>It was never built for that. It's not even a fair comparison. No, but it means I can write relatively computationally intensive server side code in JavaScript rather than having to switch to C and use an FFI. It's always nice to have decent performance, even if it's irrelevant most of the time for web programming. Erlang is great but its ecosystem is tiny compared to Node's, and as a programming language it's at lea…

> Erlang is great but its ecosystem is tiny compared to Node's, and as a programming language it's at least as quirky as JavaScript. I disagree with this; while the syntax is unusual for many, its semantics are extremely simple and clear. I don't think it has anything quite like: * JavaScript having `null` and `undefined`. * JavaScript lacking have proper integers. * JavaScript strings being UTF-16, so things like ""…

Does it have a non-hacky way of handling record types yet?

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

#306

Post by SimeVidas »

tambourine_man wrote: post #26
SimeVidas wrote: post #20

Earlier quoted context omitted.

I only know JavaScript (and I know it quite well). Why learn a whole other language, when Node gets the job done just fine?

Learning a new language will make you a better programmer. Especially one with different paradigms

I’m not sure that being a “better programmer” is important in web development. And I don’t mean that term in the broad sense—obviously, we should write good code—but in the sense that understanding two programming languages makes a significant difference. I think in web development it doesn’t.

Web development is about many things. HTML, CSS, performance, accessibility, security, networking, supporting different browsers, polyfills and workarounds, keeping up with new features, UX and usability. Then there are frameworks and build tools, which are all of course JavaScript-based.

Only a small part of web development is actual programming, and the fact that frameworks most of the time lay out the patterns for you, makes the “programmming” aspect even less significant in the overall picture.

So no, I don’t think that learning another programming language is a good way to spend your time if you’re a web developer.

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

#307

Post by root_axis »

jimmaswell wrote: post #292
root_axis wrote: post #280

Earlier quoted context omitted.

Frankly, I find your condescending insults to "x-developers" to be a sign of unsophistication, that aside, in my experience, logging is preferable to running a debugger in most situations. Logging gives you an immediate output about the particular state you're concerned with as opposed to using a debugger which slows you down while you fiddle with breakpoints, slowly step through code, hover your mouse over variables…

Are you really implying writing a bunch of print statements is more "professional" than a debugger? Debuggers are incredibly useful in tracking certain things down and don't make you write and then remove a ton of logging statements. Sometimes logging is easier, sometimes debugging is, and not just for "junior devs".

> Are you really implying writing a bunch of print statements is more "professional" than a debugger?

This is quite a loaded question, so let's unpack it a bit.

1. I made no implications regarding anything, my point is explicitly laid out with clear reasoning and examples.

2. I never made any remarks regarding how the use of any particular tool reflects on one's professionalism. I am guessing you're conflating my remark with regard to junior-level experience with the qualities of professionalism, and if that's the case I'll clarify that being junior does not in any way reflect on one's professionalism.

3. Your flippant dismissal of logging as "a bunch of print statements" is unfortunate and broadcasts a blind-spot in your knowledge of how robust logging is a critical component of any properly engineered software project, especially network services of any kind. It's not an either or question, logging is a must-have business/operations concern, whereas a debugger is a nice-to-have developer concern.

> Debuggers are incredibly useful in tracking certain things down and don't make you write and then remove a ton of logging statements.

You shouldn't be writing and removing a ton of logging statements, logging should be a planned and permanent part of your application from the beginning with appropriate severity labelling for debugging as well as run-time analysis purposes. If you want to use a debugger, that's fine, but a debugger is not a replacement for logging.

> Sometimes logging is easier, sometimes debugging is, and not just for "junior devs".

As I already stated in this comment, that's a false choice, logging should be the minimum, the debugger is there if you really want/need it. I never stated that the debugger is only for junior devs, I said I'd be concerned if a non-junior dev consistently relied on a debugger for solving problems in code, which is not at all the same thing. The use of a debugger is appropriate at any experience level, but generally speaking, the debugger is a slow troubleshooting tool that is best suited for exploring code flow or unusual bugs that seem to defy bedrock assumptions about how the application should be functioning. They are not the best tool for everyday bugs and troubleshooting.

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

#308

Post by cookiecaper »

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…

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 potential trouble spots. There's nothing wrong with logging output v. stepping through in an interactive debugger per se.

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

#309

Post by empthought »

squeaky-clean wrote: post #298
empthought wrote: post #249

Earlier quoted context omitted.

You should probably learn to expand your comfort zones more effectively, if the Java ecosystem terrifies you.

It's not that it's terrifying. It's just... why make it harder for myself? Even if it's one step (which it isn't), why? If the only reason you can give is I need to expand my comfort zone, sorry, I'll keep my comfort zone small and productivity high.

I wasn't responding to you. The person I responded said, "I find the Java ecosystem terrifying" and I pointed out how silly that statement is.

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

#310

Post by cookiecaper »

_pmf_ wrote: post #272
libertymcateer wrote: post #263

Earlier quoted context omitted.

> Based on this, it's hard not to state that current Node-developer are the new PHP-developers: Unsophisticated, completely unable to see when the tools at hand are lacking, and happy with a with whatever they can get running. Comments like this are not the problem with HN. The fact that they get voted, literally, to the top, is.

Do you know why I, personally, agree with this statement to the greatest extent? Because 17 years ago, I had this same naive development workflow. With PHP, exactly as OP mentioned. Whenever someone mentions static typing, the canned response from JS developers is "Oh, haha, we actually have unit tests for this" (usually accompanied with a patronizing smile for the obsolete waterfall programmer). Yet when dealing wit…

Unit tests are a completely inadequate replacement for typing even if they actually do exist, which, as you stated, is pretty rare.

I think the best compromise is optional typing. The language should encourage it by default, but allow some variables to be declared as dynamic/untyped. This greatly simplifies things like parsing of JSON data, which should essentially all be considered a string until there's some reason to consider it something else, but enforces consistency and safety through most of the application. Haxe does a pretty OK job with that.

Post reply on HN