Live data from Hacker News

Things I Regret About Node.js [video]

youtube.com

411–420 of 502 posts

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

#411

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.

I'm just disagreeing that it's "really hard" for languages besides JavaScript. Concurrency in Go is stupid easy, it's built into the language. Pretty sure Elixir is the same story. C++ and Rust are slightly more difficult but still nowhere near "really hard" when it comes to making a socket server that can serve hundreds of thousands.

Here's a nice WebSocket server in C++:

https://github.com/uNetworking/uWebSockets/blob/master/READM...

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

#412
post #408
post #399

Earlier quoted context omitted.

I can't argue with you, but "most of the time" it works. Not that I have a choice (unless I stop being a frontend developer), but the time we spend with node/npm debugging is not critical in the timesheet/log.

There is a choice, I do native frontend.

What tech are you using? Guess not react native then :)

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

#413
post #118

Having worked with Maven, Gradle, Ruby Gems, Pip and the non-existing Go package management I must say I actually really like the Node / NPM combo. I guess artists are their own worst critics. edit: forgot Scala's SBT, admittedly a builder using Maven repo's but still an excellent example of how bad UX in this area can get.

npm is the worst software I use daily. * The maintainers have pushed several breaking updates by mistake (I'm a teapot recently). * There have been a few cascading failures due to the ecosystem (leftpad). * node-gyp (alluded to in the talk) break cryptically on install in different operating system/package combinations. It also obscures the actual package contents. * The lack of package signatures and things like nam…

Here's one thing Node and npm are great at and NuGet fails at completely: local development of two packages. With npm, I can use "npm link" to redirect a package reference to a local folder. With NuGet, the best you an do is edit the .csproj and change the nuget reference to a project reference (if you can find the original source code). This makes simple step-through debugging across package boundaries a chore every time, whereas a source-based package system doesn't have this issue.

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

#415
It's nice to see some recognition of the idea that interpreters are safe by default (excluding infinite loops/OOM), and we can avoid many security concerns (access to files/network/etc.) by simply not including that functionality in the interpreter (unless opted in via a startup parameter, as described).

I'm also a fan of using env vars for configuration and locating dependencies, as mentioned in the talk. Much simpler and easily extensible compared to e.g. vendored directories (requires messing with the contents of the source directory, which requires write access and breaks hashes, etc.), hard-coded system paths like /usr or ~/.some-default-location (causes conflicts when running multiple incompatible versions), etc. A simple env var of paths, e.g. colon-separated, maybe with some sane quoting convention, can be used for all of those if desired, whilst making it super easy to extend-with or restrict-to any other location(s) instead. It's also trivial to "bake in" an env var to an application, just call `PACKAGE_PATH=foo:bar my_app` rather than `my_app` (or make a one-line wrapper script).

I agree with others that importing from URLs seems like a bad idea: network I/O is one of the least reliable actions we can take, which would make importing far more complicated than necessary (what if we're offline? should we follow redirects? should we check for proxy settings? how should we report errors? etc.). All of this complexity and the inescapable problems of network failures are completely avoidable by just downloading things up-front. Package managers/build tools can fetch whatever they like (URLs, git repos, etc.), however they like (with proxies, caches, etc.), to wherever they like (one big cache, project-specific vendor dirs, whatever), and just stick the resulting directory (possibly of symlinks) in the program's environment (e.g. via a wrapper script, as above).

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

#416
post #358

One takeaway from this is how Microsoft is killing it currently: * Much-beloved TypeScript * Much-beloved VSCode * Much-beloved GitHub If they hire Ryan to flesh out his vision for deno we'd probably need a new acronym, MAFANG On a more serious note, I wonder if deno could support a lower level construct like Observables. As much as Promises are perceived to be an improvement over callbacks, they still have major fla…

* Much-beloved Ubuntu Just leaving it here, given Azure Sphere and WSL.

Nitpick, but Azure Sphere doesn't use Ubuntu.

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

#417

Earlier quoted context omitted.

> using a language with _very_ limited expressiveness (C#) is not very productive. o_0. Think you need to check yourself mate. I believe the productiveness of more "expressive" language tends to be undermined by the loss of productivity that occurs when you're compelled to write blog posts or comment on hacker news about how amazingly productive and expressive your language is.

I can do like 3-4 hours of productive work a day realistically - after that I lose focus. I can push this in some periods - but that's the ammount of time I limit myself to be functional over long term. If I need to waste that time sifting trough boilerplate than I'm pretty upset because I get less shit done in that time window. Chatting on forums is a casual brain teaser and keeping up to date on industry stuff.

I would suggest using more personal language when expressing personal opinion and toning down the force (very).

> [I find that] using a language with limited expressiveness (C#) is not very productive for me.

Like, I'd figure you can be mad productive in any language (even COBOL?) although I'm only completely cosy in a couple. There's no need to be so dismissive of the tools that others use.

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

#419

Earlier quoted context omitted.

> using a language with _very_ limited expressiveness (C#) is not very productive. o_0. Think you need to check yourself mate. I believe the productiveness of more "expressive" language tends to be undermined by the loss of productivity that occurs when you're compelled to write blog posts or comment on hacker news about how amazingly productive and expressive your language is.

I can do like 3-4 hours of productive work a day realistically - after that I lose focus. I can push this in some periods - but that's the ammount of time I limit myself to be functional over long term. If I need to waste that time sifting trough boilerplate than I'm pretty upset because I get less shit done in that time window. Chatting on forums is a casual brain teaser and keeping up to date on industry stuff.

I don't think "expressiveness" or "boilerplate" are the things that slow me down. I use Go, and I find that it is both expressive and a little verbose, but it's still very simple and there's usually one clear way to do things, so I find that I can move a fair bit faster than I can in C# _or_ Haskell (in the latter case, it might just be that Haskell has a huge learning curve and I'm nowhere near over it).

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

#420
post #349

Earlier quoted context omitted.

Yes, that's a cost your brain is paying. And a higher cost if you bring on new devs to that project, who then need to learn and understand both Python and Elixir. Debugging is different in both languages, libraries are different, standards, conventions, top level APIs, runtimes, capabilities, all that has to be understood to operate at a high level. That's a non-zero cost and it's pretty significant. That you've lear…

>> I was working with a system where server is written in Erlang and client (and another server) is written in Python. No problems with switching back and forth. > Yes, that's a cost your brain is paying. What cost? I said I haven't noticed any. > new devs [...] then need to learn and understand both Python and Elixir. No, they don't need to learn even a speck of Elixir. -- What you described is a trusim that one nee…

How wouldn't there be a cost?

There are more things you have to remember. Workflows in both languages. Of course it's more stuff, thus more context. And you have to use both languages constantly to stay fresh in them. The syntax isn't the only problem, just the easiest one.

Is it just as easy to maintain Spanish and English skills than just English?

"I don't notice it" isn't a very strong argument. I bet you don't notice the effects of slight dehydration and your diet and exercise on your output either. But if you were actually experimenting with it, I guarantee you could soon perceive it.

Post reply on HN