[omegabravo]

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.

[Xeamek]

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

[nativeit]

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

[wiseowise]

And what's the problem with that?

[dragonwriter]

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

[brigadier132]

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

[dragonwriter]

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.

[Xeamek]

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.

[brigadier132]

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

[wiseowise]

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