4 ms·

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

by arc776 4y ago

> 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 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 4y ago
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 4y ago
  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 4y ago
    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 4y ago
      > 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 4y ago
        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 4y ago
        > 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?

by arc776 4y ago

dom96 4y ago

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 4y ago
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 4y ago
  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 4y ago
    > 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 4y ago
      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 4y ago
        > 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?