[arc776]

> the real killer feature to me is the javascript target

Agree, this is amazing because you can share code and data structures between front and backend (for example: https://github.com/karaxnim/karax).

Also, it's really nice having high level stuff like metaprogramming and static typing spanning both targets. Things like reading a spec file and generating statically checked APIs for server/client is straightforward, which opens up a lot of possibilities.

[dom96]

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.

[arc776]

Only if you consider the web side.

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.

[dom96]

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.

[arc776]

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

[dom96]

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

[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?

[elcritch]

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.