Hacker News Reader

Comment by vonklaus | Hacker News Reader

There are a lot of jokes here and I appreciate them. It isn't breaking news that js has some bad parts, but why are people who aren't joking concerned?

* What makes nodejs running on an entertainment system dangerous?

* Outside of bias, how strong of a case is there to use another language?

* why shouldn't we use high level languages, even for avionics? Obviously not JS because numbers aren't transitive and it just isn't the usecase, but we don't need to optimize for 1kb of memory anymore. C family languages are the backbone of many things and that makes sense but do we need to keep using java and C-like languages or could we use python or something of similar nature where memory isn't manually allocated.

View on HN

I'm sure that you could use a high level language like Java or Python for some non-critical tasks. For more critical software you likely have hard real-time requirements, and you need to be able to reason about memory use and time in ways that obviously isn't suitable for anything that could "pause the world" for an arbitrary amount of time to collect garbage.

Exactly this.

It's not that there's anything wrong with using a high-level language for safety-critical systems with real-time requirements and limited hardware. It's just that every high-level language that's remotely appropriate for this set of requirements wasn't production ready (or even conceived of) 10-20 years ago.

Hopefully the next generation (or the one after that) of control software for aircraft will be written in beautiful code :-)

I wouldn't be so quick to dismiss how avionics is done currently. That software operates against very difficult requirements, the industry has learned a lot about how to do so reliably. These systems favor static allocation over heap allocation, so a garbage collector isn't as useful as you'd assume.

Nothing against python, but it's just not suited to writing avionics code that human lives depend on.

Now, in some ideal future, could we be using better languages? Absolutely. Stuff like ATS looks like the future of that kind of code, IMO. Likewise, Rust's memory management types make a ton of sense and could be useful for the situations where static allocation can't do the job.

With Rust I'd still be worried about compiler stability and destructor/allocation pauses. There's a reason that most avionics software written is on top of an RTOS & compiled with multiple different compiler vendor's software.

Not saying it couldn't in the future, but it pays to look backwards for safety critical systems.

Personally, I prefer node.js for serving as a backend to a JS based front end... Then again, I also like document oriented databases most of the time (RethinkDB, Mongo, etc).

I find that there is much less distraction when you're working on both the front end and backend, that you can get things done much more seamlessly. In this case (for entertainment), I feel it's a pretty decent match.

For other systems, I'm not sure I'd suggest C variants at this point, if Go or Rust are options, I'd probably favor one of them. It really depends on the use case.

I'd rather use a statically typed language, like C++11 to avoid surprises at runtime. I guess you could use TypeScript to circumvent this problem.

You'd rather use a language full of undefined behavior as opposed to one in which (practically) every behavior of a program is specified by ECMA-262? To "avoid surprises at runtime"?

Surprises based on undefined behavior are usually not surprises at runtime, because of superior tooling. Either way, C is best because it has both of those things (tooling, defined behavior). It is possible to write very nice C.

> Surprises based on undefined behavior are usually not surprises at runtime, because of superior tooling.

Yes, they are. Empirically ([1], just to name one example).

> Either way, C is best because it has both of those things (tooling, defined behavior).

C has tons of undefined behavior.

[1]: https://lwn.net/Articles/342330/

My only thought is that the airline is going to regret crumbling under the pressure from developers who wanted node.js. Allowing developers to choose whatever language they want for such a massive system is a mistake. node.js has not proven itself beyond being the latest fad. The developers wanted to use something cool and modern, while clearly ignoring concerns over the long-term viability of the system.

Oh well, that isn't a problem for anyone other than the airline. It's possible that in a matter of a few years (instead of decades), the entire system will have to be reimplemented at the airline's cost. You don't use the latest trendy language for systems which are expected to remain in operation for 20-30 years.

Reply on news.ycombinator.com