121–130 of 169 posts
Earlier quoted context omitted.
Oh, but that's OK. You can just have inform and in_form. Except you can't because Nim also ignores underscores in identifiers. Gotta make sure there is literally no way to disambiguate cases like this! (I _want_ to like Nim but this single decision seems to me so spectacularly bad that it's a non-starter.)
Sounds like you're agreeing with me?
I've been considering getting into Nim for a while now as something more lightweight/terse to write thin CLI utilities in. I'm glad to hear that it's performing well for this usecase. It's a very attractive alternative to Rust for it's simplicity and terseness. I still haven't gotten around to picking it up though, these days I just use QuickJS for anything that needs to be reasonably portable and thin. Maybe next si…
Earlier quoted context omitted.
Nim is actually case sensitive on the first character only, so your list of identifiers are not all equivalent. Just thought I'd point that out for correctness sake.
Oh, thank you for the correction, and sorry for the misinformation! In any case (pun intended?) it's the underscore insensitivity that makes it difficult to use standard search tools.
I personally don't like the feature, but what do you find difficult about using /my_?[vV]ariable/ to search for any of myvariable, my_variable or myVariable?
One thing I find annoying about Nim is the case insensitivity [0]. There was no strong reason for this "feature" and literally no mainstream language does it. Moreover it makes code search a pain. [0] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...
Disallowing these case/underscore variants from referring to differing values could be quite ok -- even a plus-- if (but only if) an additional rule is added to disallow any variations of the declaration-time casing for a variable within the same scope to prevent the need for bespoke grepping tools and discourage arbitrary variations. If that restriction was added one could argue that this improves code readability (…
Earlier quoted context omitted.
I use Nim in production. I been using it for more than 1 year in production. I like it. For me, it started out as a faster python that prevents typos. But it has really grown on me. I really like that I can share libs on server (compiling to c) and client side (compiling to plain javascript). Basically any C library is also a Nim library with a tiny wrapper. That's a huge ecosystem! I also like how Nim can integrate…
I have some code duplication between android, iOS and a webapp / PWA. How realistic is it to look at something like nim for codesharing?
I'm also working on a game that I haven't quite moved to iOS/Android yet, but that is my plan. So far targeting the desktop with SDL and HTML5/Canvas with the JS backend works very well.
Earlier quoted context omitted.
For me, I'm seeing compile times averaging around 5-10 seconds, with outlier builds taking up to 40 seconds if the files in question aren't cached. It feels faster than Go, but I think part of that is down to Nim's compile output being verbose by default.
Nim's compilation is much faster than Go.
Earlier quoted context omitted.
> Its difficult to read and understand code that does things like myvalue = myValue. I think they made the right tradeoff They could enforce case consistency instead of case insensitivity if that's the problem they're trying to solve, though. Although, even then, consider that variables like 'inform' and 'inForm' might not mean the same thing...
Oh, but that's OK. You can just have inform and in_form. Except you can't because Nim also ignores underscores in identifiers. Gotta make sure there is literally no way to disambiguate cases like this! (I _want_ to like Nim but this single decision seems to me so spectacularly bad that it's a non-starter.)
One thing I find annoying about Nim is the case insensitivity [0]. There was no strong reason for this "feature" and literally no mainstream language does it. Moreover it makes code search a pain. [0] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...
It's shocking how people whine about case insensitivity without bothering to try using Nim for a while. Case insensitivity is a feature and it's meant to allow easy interfacing with C. And it also encourages clean code. With other languages you can have variables called "startdate", "start_date" and "startDate" in the same scope leading to bugs - especially when using completion in an editor - and poor readability. I…
If this is the goal, there are many alternative ways to solve this problem, making the language case insensitive is a pretty big hammer.
One thing I find annoying about Nim is the case insensitivity [0]. There was no strong reason for this "feature" and literally no mainstream language does it. Moreover it makes code search a pain. [0] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...
Main reason for this feature is that Nim is big as a glue language. Many C/C++ libraries don't have consistent naming conventions between them. I don't want my code to look like a patch work of `__APICALL__(system_call.inspectSomething())` I just want it to look like Nim code: `apiCall(systemCall.inspectSomething())`. This is just a consistent standard on how to turn names in one style into another style backed into…
apiCall = __APICALL__