6 ms·

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

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

by arc776 4y ago

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