> There's also cases where case sensitivity should matter in naming in my experience, and it's not possible without it. I'm really curious, do you have any examples? I can't think of any that wouldn't be better served…
Oh yes, just like you can never find anything in Google because it's case insensitive.
I'm a full time Nim developer and have been for over half a decade. It's completely spoiled me for other languages, it is just ridiculously productive. Rather than an ah-ha moment, it was more a gradual transition from…
> It's less that "Reddit uses NIM" but rather one guy at Reddit uses NIM to do work. They are the same thing. No one is saying Reddit bases their entire infrastructure on Nim. The point is just that the language is…
Yeah definitely. Unlike Python though it's fast and light on memory, so once you have a prototype it's often already performant enough to be developed into a final product. Things like that save a lot of time and money…
> 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…
> 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.…
> 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…
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…
> 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…
100% my experience too. GC in Nim is a rounding error at worst and is often statically elided, anyway. Performance is almost entirely about memory access patterns and you have the same access to this as C. In other…
> you often have quasi-singleton classes called "FooManager", then a single instance called "foo_manager". Like this: type FooManager = object var foo_manager: FooManager > Now... are these colliding? Or not, because…
Searching has never been a problem for me in years of using Nim but there is `nimgrep` bundled for style insensitive search. Also I'm no RE wiz, but seems like RE might help if it came down it. Just to stress myself as…
> other people's code can, refer to the same thing by different names They can but the compiler will just tell you it's ambiguous and to qualify it. Also bear in mind Nim has very strong static typing, so for things to…
> the automatic conversion from camel-case to snake-case... very much so. If an identifier clashes, you get a compile time ambiguity error. It means `is_OK` and `isOk` will report ambiguous identifiers and force you to…
Nim's super power is being ridiculously productive (at least for me). Hack stuff out like a Python script, yet it runs really fast and is a tiny self contained executable, so you can just use it as is and move on to the…
Nim - https://nim-lang.org/ Lets you mix and match other libraries with their native ABI as it compiles to C, C++, ObjC and JS + has excellent FFI.
We don't want to automatically convert between `int` and `float` because there's a loss of information, since floats aren't able to represent integers precisely. However, we don't need to specify types until the point…
> So why can't Nim infer from `let b: uint = a` It "can", but it's a design decision not to by default because mixing `uint` and `int` is usually a bad idea. This is telling the compiler you want to add an `int` that…
> not slowing one's work Put back into context, your reply makes sense as these popular libraries are pretty battle tested. Having said that, it is a valid point that type hints being voluntary means they can only be…
> just doesn't slow one's work down very frequently in daily practice. Well, maybe you don't feel it slows you down, but it is manual work you must do to get a reliable product only because of dynamic typing. Not only…
In Nim you can even convert JSON to static types! https://nim-lang.org/docs/json.html#to%2CJsonNode%2Ctypedesc... Now you get type checking on JSON at compile time :)
> I think the message is more nuanced I thought it was more nuanced too as they were explaining how integer types can be derived, until I finished the article, and they really did just seem to be complaining that…
Thanks for your reply. It's interesting to know what the perceived weaknesses and strengths are. Nim does have pattern matching but it's rarely used, whereas it seems to be used a lot in Rust (probably because of the…
The syntax is what attracts me to Nim too. Why use Rust over Nim in this case? Is it Rust's static lifetime constraints? Is there some feature you would miss if you used Nim instead? Or would you prefer to use Rust…
> There's also cases where case sensitivity should matter in naming in my experience, and it's not possible without it. I'm really curious, do you have any examples? I can't think of any that wouldn't be better served…
Oh yes, just like you can never find anything in Google because it's case insensitive.
I'm a full time Nim developer and have been for over half a decade. It's completely spoiled me for other languages, it is just ridiculously productive. Rather than an ah-ha moment, it was more a gradual transition from…
> It's less that "Reddit uses NIM" but rather one guy at Reddit uses NIM to do work. They are the same thing. No one is saying Reddit bases their entire infrastructure on Nim. The point is just that the language is…
Yeah definitely. Unlike Python though it's fast and light on memory, so once you have a prototype it's often already performant enough to be developed into a final product. Things like that save a lot of time and money…
> 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…
> 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.…
> 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…
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…
> 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…
100% my experience too. GC in Nim is a rounding error at worst and is often statically elided, anyway. Performance is almost entirely about memory access patterns and you have the same access to this as C. In other…
> you often have quasi-singleton classes called "FooManager", then a single instance called "foo_manager". Like this: type FooManager = object var foo_manager: FooManager > Now... are these colliding? Or not, because…
Searching has never been a problem for me in years of using Nim but there is `nimgrep` bundled for style insensitive search. Also I'm no RE wiz, but seems like RE might help if it came down it. Just to stress myself as…
> other people's code can, refer to the same thing by different names They can but the compiler will just tell you it's ambiguous and to qualify it. Also bear in mind Nim has very strong static typing, so for things to…
> the automatic conversion from camel-case to snake-case... very much so. If an identifier clashes, you get a compile time ambiguity error. It means `is_OK` and `isOk` will report ambiguous identifiers and force you to…
Nim's super power is being ridiculously productive (at least for me). Hack stuff out like a Python script, yet it runs really fast and is a tiny self contained executable, so you can just use it as is and move on to the…
Nim - https://nim-lang.org/ Lets you mix and match other libraries with their native ABI as it compiles to C, C++, ObjC and JS + has excellent FFI.
We don't want to automatically convert between `int` and `float` because there's a loss of information, since floats aren't able to represent integers precisely. However, we don't need to specify types until the point…
> So why can't Nim infer from `let b: uint = a` It "can", but it's a design decision not to by default because mixing `uint` and `int` is usually a bad idea. This is telling the compiler you want to add an `int` that…
> not slowing one's work Put back into context, your reply makes sense as these popular libraries are pretty battle tested. Having said that, it is a valid point that type hints being voluntary means they can only be…
> just doesn't slow one's work down very frequently in daily practice. Well, maybe you don't feel it slows you down, but it is manual work you must do to get a reliable product only because of dynamic typing. Not only…
In Nim you can even convert JSON to static types! https://nim-lang.org/docs/json.html#to%2CJsonNode%2Ctypedesc... Now you get type checking on JSON at compile time :)
> I think the message is more nuanced I thought it was more nuanced too as they were explaining how integer types can be derived, until I finished the article, and they really did just seem to be complaining that…
Thanks for your reply. It's interesting to know what the perceived weaknesses and strengths are. Nim does have pattern matching but it's rarely used, whereas it seems to be used a lot in Rust (probably because of the…
The syntax is what attracts me to Nim too. Why use Rust over Nim in this case? Is it Rust's static lifetime constraints? Is there some feature you would miss if you used Nim instead? Or would you prefer to use Rust…