[arc776]

> In the general case I think you underestimate how performant JavaScript JITs are these days.

No, I'm well aware of JS and WASM performance, internals, and pitfalls.

> For 99.9% of use cases the performance is enough.

Again, it depends on your perspective and requirements. Statistically, PHP is enough for most people so why use TypeScript? At the edges of the resources bell curve however the details do matter. It's not enough to say that for those concerns you must use different language and potentially a whole different set of semantics, intricacies, libraries and workflows.

> I think we need to think bigger. Embedded is far too small a niche to be considered to be Nim's killer feature

That wasn't my point, and ironically you might be underestimating how much minimising power and resource usage drives much of the modern world. Memory/storage + CPU ticks == money.

My point is that a language that can act as a universal tool without sacrificing efficiency, productivity, or extensibility (via AST macros), is itself a 'killer feature'. Nim hits that sweet spot of being easy to read and write as well as 'close to the metal'. It lets me target JS, embedded, and natively interface with C and C++ ABI. That gives me a lot of options with one language. There are other languages that have some of these traits, but not all together in a nice package IMO.

> especially when this space is already dominated by Rust

You mean C?

[dom96]

> Statistically, PHP is enough for most people so why use TypeScript?

In the context of our discussion PHP doesn't make sense as it doesn't have native support for running in the browser. TypeScript is specifically a good choice because it has been built with the browser and the backend in mind.

> you might be underestimating how much minimising power and resource usage drives much of the modern world. Memory/storage + CPU ticks == money.

I have learned over the years that what actually drives the modern world is pragmatism. Sure, performance matters, but when you have to reimplement hundreds of libraries from scratch because the ecosystem doesn't exist then you are losing far too much time (and your implementations of those libraries are likely to be suboptimal). You're better off losing some performance and picking the established language, so that you actually ship your project within a couple of months instead of a couple of years.

Nim has been going now for 15 years and has thus far failed to reach critical mass. With each year gaining that critical mass becomes less and less likely. A killer feature for Nim needs to be so beneficial that it overcomes the lacking ecosystem.

> You mean C?

I was referring to the space of languages that work well on embedded and in the browser. C doesn't support the browser side well.

[arc776]

> TypeScript is specifically a good choice because it has been built with the browser and the backend in mind.

Sure, if your only use case is web front/back end uniformity.

My use case covers web front and back end, but also custom embedded, HPC, ML, simulations, and a lot of other stuff that is simply not viable with TS/JS or WASM. This language lets me share abstractions and reuse code across all this stuff and use C/C++/JS/Python ecosystems directly.

All the above are possible with just JS. Yes, you can even run JS on a microcontroller: https://www.espruino.com/

The V8 JS/WASM engine, however, is written in C++ for good reason. TS/JS/WASM/web is built on people counting ticks and aligning bytes to give even the floppiest callback spaghetti of frameworks the overhead to be responsive as abstractions increase.

> I have learned over the years that what actually drives the modern world is pragmatism.

I agree, except I think it's more pragmatic to have one language that can service any industry. TS/JS ain't it, from my perspective.

> reimplement hundreds of libraries from scratch because the ecosystem doesn't exist then you are losing far too much time

Why would you reimplement libraries from scratch instead of using FFI? FFI is one of the many, apparently unrecognised, 'killer features'. Specifically killer is FFI with ABI compatibility to C++. The pragmatic approach is always to stand on the shoulders of giants and FFI with existing libraries for the reasons you listed.

I'm surprised to hear you say that to be honest as you've used the language for years. Is there an experience behind it?

> You're better off losing some performance and picking the established language, so that you actually ship your project within a couple of months instead of a couple of years.

Well, I don't disagree with the sentiment, but this is more of a commentary on the job market/cost of business than capability.

Again, though, it really depends what you're doing. Chucking out a web app for an internal tool and distributed websites have different requirements.

> Nim has been going now for 15 years and has thus far failed to reach critical mass. With each year gaining that critical mass becomes less and less likely.

This is a strange perspective to me. Programming languages aren't food left out of the fridge, they're tools to do a job.

Python was made in the 1980s and took decades to even be known about. Why did people start using Python? Because it was readable, convenient, and very productive. Why did it become popular? Because people used it more...

What you call 'critical mass' is just a visible hiring pool.

Companies need confidence to find or train people in the language, and developers need confidence they can pay their bills by learning it. Confidence is increased when people hear of business use, say, if FAANG started a some minor project with it, and it feeds back.