Honestly as someone that has used Nim for this extensively, I think that these days with WASM and TypeScript available this isn’t much of a killer feature anymore.
Backend and frontend in the same language is a massive feature for many reasons, not least performance and uniformity. Adding TypeScript is increasing interface friction and complexity, instead of simplifying things.
Of course, right now this may or may not be easier/harder/feasible with just Nim depending on the project, and many more people know TypeScript, but the ideal of one language > many languages is a worthy one.
What do you mean? I am considering it from both sides.
TypeScript already allows this, i.e. you can build the backend and frontend in one language (TypeScript). Same for most languages that compile to WASM.
My point is that with TypeScript this killer feature is already realised and in a way that is far more familiar to the many thousands of developers that already know JavaScript.
> you can build the backend and frontend in one language (TypeScript)
Sure, from the uniformity side, but what about performance?
It's not just latency performance either, it's resource performance and overheads, such as with embedded servers.
> with TypeScript this killer feature is already realised
It really depends on your requirements whether this is true. Personally, a systems language I can use for web stuff is more useful and has a wider scope to me than running JavaScript or WASM in a systems role, even though it is technically possible to do so.
In the general case I think you underestimate how performant JavaScript JITs are these days. For 99.9% of use cases the performance is enough.
Sure, for embedded it might not be workable, but again- since we're discussing killer features I think we need to think bigger. Embedded is far too small a niche to be considered to be Nim's killer feature, especially when this space is already dominated by Rust which supports WASM very well (and therefore hits the performance + uniformity you desire).
> 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
> 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.
I'd agree embedded is a pretty niche area, and that it's likely not a killer app for Nim. Though it does bring a fair bit of attention.
However Rust doesn't dominate embedded. That's still C or even C++.
Rust has a lot of embedded crates, but supports a pretty small subset of hardware given the number of crates and amount of effort poured into them. The trait system particularly sucks for modeling hardware, IMHO, and with the "re-write the world" mentality it means there's still quite a bit of pain.
So it seems rosier than it actually is -- for now. Rust on embedded is gaining momentum.
> However Rust doesn't dominate embedded. That's still C or even C++.
I don't disagree. What I meant specifically is that Rust dominates the space where you want to target embedded and the browser (Rust does well on embedded and has good WASM support). C/C++ does not support the browser well at all (you can say that it supports WASM too, but Rust has far more front-end frameworks that actually target the browser than C afaik).
Backend and frontend in the same language is a massive feature for many reasons, not least performance and uniformity. Adding TypeScript is increasing interface friction and complexity, instead of simplifying things.
Of course, right now this may or may not be easier/harder/feasible with just Nim depending on the project, and many more people know TypeScript, but the ideal of one language > many languages is a worthy one.