Live data from Hacker News

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

311–320 of 365 posts

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

#311
post #304

Earlier quoted context omitted.

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.

"Terrifying? What if something REALLY happens to you? You used 'terrifying' on the Java ecosystem!"[1]

[1]: http://zenpencils.com/comic/95-louis-c-k-we-dont-think-about...

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

#312
post #191

Earlier quoted context omitted.

V8 is a world class compiler. Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. (Pypy is a good match for it but it's not main street and you can't just use any module.) in terms of performance and popularity, v8/node stand pretty much alone as far as dynamic non-compiled environments. JavaScript has a lighter weight feel than Java and the jvm stack. Single threaded with a top notch event reac…

"if you don't stay up to date with your depends, things change fast and sometimes they change a lot." This, was actually one of the things I liked most about Node.js - npm allows a developer to specify all dependencies (`pacakage.json`), versioned, similarly to maven but not as clunky. I was able to get up to speed project very quickly and easily using just `npm install`. I had one or two versioning issues to iron ou…

Not sure what your other experience is, but most dynamic languages have simple package management platforms similar to npm. As you note, Java has Maven/Ant and C# has NuGet, both of which are substantially more "enterprisey".

It'd be interesting to hear a fair, modern comparison between npm, ruby-gems, LuaRocks, pip/PyPI/cheeseshop, and the other big ones I'm sure I'm forgetting.

The JavaScript community has had a lot of competitors on this front, particularly for frontend asset management, but it does finally seem to stabilizing a little bit. It took forever.

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

#313

Earlier quoted context omitted.

V8 is a JIT compiler, which incorporates a runtime and a compiler.

> V8 is a JIT compiler, which incorporates a runtime and a compiler. So it's a compiler which incorporates a compiler? Compilerception much? Seriously though: Can I tell V8 to compile my JS and tell me any errors found before I deploy it to production and runtime? Yes or no? Just because V8 internally JIT-compiles the JS-code to something eventually executable which the machine can run doesn't change the fact that it…

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 gcc and glibc, would the combined product no longer be considered a "compiler"?

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

#314
post #272

Earlier quoted context omitted.

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…

> 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.

Like C#'s dynamic keyword (not to be confused with its var keyword, which just does type inference).

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

#315

Earlier quoted context omitted.

It's not just the types, it's the whole APIs, culture etc. Java, for example, is no picnic, whether it can now infer some types or not. In Python I don't even need a main().

How is if __name__ == "__main__": main() different from a main()?

It's only needed if you're importing the file as a library/module somewhere.

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

#316
post #206
post #158

Earlier quoted context omitted.

No I want to use the command line. https://maven.apache.org/guides/getting-started/maven-in-fiv... Maven quick start first command: > mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false Then it generates stupidly deep Java structure. and next you have to write a verbose xml. They even say: > The POM is huge and can be daunting…

> Then it generates stupidly deep Java structure. It generates enough structure to scale up to reasonable projects. The nesting is a price well worth paying for consistency. Every maven project puts its source in the same structure, with the result that you can jump into any project and know how its build will work and where to find the source. > All of this stuff is verbose and built to be generated by IDEs. It's no…

> It generates enough structure to scale up to reasonable projects.

It generates stupidly deep structure because Java requires a stupidly deep structure.

> Every maven project puts its source in the same structure, with the result that you can jump into any project and know how its build will work and where to find the source.

Rust, Elixir and Erlang achieve this with tooling that is practically trivial to use. Without an IDE.

> Verbose is worth it for clarity, particularly in a file you edit rarely.

Being concise is a big factor in clarity.

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

#317

Earlier quoted context omitted.

Same, and same. It's very research-y. It is an incredible place to work if you treat your development process like research anyway, but if you just want to jam through production cycles I would pick Python or something stable.

So, not development?

I would say research-y development: building with the understanding that some percentage of the time you will be building only to learn.

Also, there is a lot of research in design, and I do design and development interleaved. I could carve out slices of that work to call "pure development" or "pure research", but for me, design, engineering, and research are all part of one tightly coupled process. I call that process development for shorthand. Is there a better word?

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

#318

Earlier quoted context omitted.

The command to set up a Dropwizard project according to the getting started guide[0] is: mvn archetype:generate -DarchetypeGroupId=io.dropwizard.archetypes -DarchetypeArtifactId=java-simple -DarchetypeVersion=1.0.0 Which spends the first 30 seconds downloading a bunch of stuff before asking you for settings to start off your project. I then read the README it created and ran `mvn clean install` as instructed which st…

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.

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

#319

Earlier quoted context omitted.

You nailed it. Three major things I care about for my application: - Logging - Metrics/Instrumentation/Tracing (memory usage, transactional performance monitoring, etc) - Surviving exceptions All of these are either very immature in Node or simply so far behind they may as well not exist. By nature of running in an application server, you do get a lot of benefits right off the bat for all of those, but even if you're…

Promises and now async/await go a long way to remedy the discrepancy between synchronous exceptions and asynchronous errors, by helping ensure that they both end up as promise rejections (as long as promises/async functions are your de facto async abstraction) while also being handleable with try/catch. The Koa framework (and in the future Express I believe) is designed around this concept, so middleware-level promis…

Spot on! And with node version 8, due out any week, we no longer needs babel on the server when doing async/await/import. It will all be there natively.

We use PM2 in production for web apps, long running processes (console apps with rethinkdb change feeds) and cron to spin up command line apps for data transformations, SaaS integrations, bots and more.

Most of us use VS Code now (I still use Vim)...so yes, having done enterprise work with a full blown IDE and tooling can be very helpful as the Node debugging and profiling experience is not great (but getting a ton better).

In the past we had a ton of C#/.net in production, then Ruby and now JS for the indefinite future. We build things that end up in production for 10 years or more, so having that talent pool to pull from in the future will be great.

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

#320

Earlier quoted context omitted.

> V8 is a JIT compiler, which incorporates a runtime and a compiler. So it's a compiler which incorporates a compiler? Compilerception much? Seriously though: Can I tell V8 to compile my JS and tell me any errors found before I deploy it to production and runtime? Yes or no? Just because V8 internally JIT-compiles the JS-code to something eventually executable which the machine can run doesn't change the fact that it…

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.

Post reply on HN