Hacker News Reader

Comment by throw-the-towel | Hacker News Reader

> When we called the isOwner function, it returned a Promise even though our function signature did not specify it as an async function. Our synchronous-looking function was invisibly converted into an async function. This meant it no longer returned a boolean, it returned a Promise.

Oh God.

View on HN

I'll be down voted by JavaScript lobby for saying this but I'll still say this.

Never use JavaScript on the server side. The amount of bugs that can happen is insane. JavaScript is just a specification with varying implementations across various versions.

A proper language like Java, Go, or Rust ensures that your code will have fewer logical bugs of this type.

https://ashishb.net/tech/javascript/

this issue was caused by a framework that's trying to do too much, relying on "magic" interfaces to supposedly reduce developer burden. the function is very unambiguously written and the language did nothing wrong

I also support using whatever language you and your team prefer when you can. that's the glory of backend: no restrictions on what you can run. but sometimes you need to write client software, and those are strictly easier to manage in the platform's native tongue: Swift, Kotlin, JS, and so on

> this issue was caused by a framework that's trying to do too much, relying on "magic" interfaces to supposedly reduce developer burden. the function is very unambiguously written and the language did nothing wrong

The function is unambiguously written, but the runtime functions differently, and this is not a language problem? This is incoherent; one of these statements is incorrect.

> the function is very unambiguously written and the language did nothing wrong

The language absolutely did something wrong, by trying to evaluate a non-boolean type as a boolean. That is a horrible footgun and JS is absolutely at fault for doing so.

You'll be down voted appropriately for muddying the difference between the language runtime (on the server side there is one runtime people use and several small competitors) and the framework, which was the issue in this case

The fact it’s possible is the problem he’s pointing out.

That's nonsense. Code has bugs and you're always writing for a particular target runtime anyway. "Someone might run this on a version of the runtime that implements an incomplete or nonstandard version of the spec" is not a concern

That my compiler or interpreter may insert code that has a completely different outcome to the intended source code is way down the list in terms of thoughts when stumbling upon a bug.

I'd say this was React, not JS. And I do feel that all the back end conventions that have emerged around Node.js, etc. are a clusterfuck.

Can JS succeed in the back end? I say yes, but not like this.

My jaw dropped.

Reply on news.ycombinator.com