Hacker News Reader

Comment by omegabravo | Hacker News Reader

If you're pushing bits and bytes you might want tight control over the runtime and guaranteed execution time. If you're not, I think it's perfectly acceptable.

View on HN

The same way its 'perfectly acceptable' to use a Canon to kill a mosquito.

Also, in many circles, known as “a larf”. In the immortal words of Kurt Vonnegut, “We’re here on this Earth to fart around—don’t let anybody tell you any different.”

And what's the problem with that?

Well, it's a particularly inefficient use of a delicate camera for a purpose for which simpler, more resilient, more purpose-appripriate tools exist.

> particularly inefficient

I'm optimizing for my own time.

> simpler

If you don't need fine grained control of memory how is a non-gc'ed language simpler?

> more resilient

How is it more resilient to use a language that requires manual memory management?

> more purpose-appripriate

Not an actual argument.

You seem to be taking my response to a question about what is wrong with using a “Canon” [sic] to swat a mosquito as if it was an argument about what that was a (typoed) metaphor for rather than a humorous observation about what was literally described.

But javascript isn't even a good tool, you are optimizing for literally nothing else then to not spend like 20 minutes picking up go or something.

Instead you pick literally the worst (of the popular) languages that is painfully inefficient.

> But javascript isn't even a good tool, you are optimizing for literally nothing else then to not spend like 20 minutes picking up go or something.

I know Go and Rust. I likely wouldn't use Javascript for embedded, the tool I use will be informed by whether I need performance and what language has the best ecosystem. If I can get away with GC for my app I will use it.

There is a difference between 'maximizing performance' and 'picking literally the worst tool for the job because I don't care lmao'

In many ways typescript is terrible, but I've been writing it for a long time now and I don't often write bugs in it that get shipped to production. I've never really run into bugs that I could blame on typescript being bad. I just don't do dumb things like comparing strings and numbers. So yeah, it has a bunch of weird foot guns and is just generally not efficient but

1. I can write code that's fast enough to solve the problem.

2. I can write it quickly.

3. I can hire a million people to work on it if I need to.

4. Every single company that releases a service releases a Typescript or Python library first.

Also from personal experience, using 1 language across all environments speeds up development massively. Especially early on in a project when the schemas are not set in stone. If every time you update a table you need to change 4 different files and update all your validation logic you will have a rough time.

When you say JavaScript, are you talking about runtime or language?

Both

And what is wrong with JS as a language in this case? Because there are runtimes optimized for low-level work.

Reply on news.ycombinator.com