4 ms·

NIM really is a full stack language and ecosystem. It has a first class compiler to JavaScript (though, I admit, I don't know how tuneable it is, so I think it

NIM really is a full stack language and ecosystem. It has a first class compiler to JavaScript (though, I admit, I don't know how tuneable it is, so I think it just compiles down to ES5, it'd be nice to do a differential build where it would compile down to ES5 and/or ES2015/ES2016 at the users discretion) Only thing it needs now is a compile to CSS solution and you would never have to leave the language. Its a very thurough language in that regard. It also needs a strong GUI framework for desktop and mobile apps, as well, but still, its very fully featured! My hunch in this area is that you could just compile to Electron/NativeScript/React Native as a relatively 'quick' solution to these problems. I'm excited to see where this language goes. I'm pretty tempted to use it in production to replace Python for some things and may find it more expansive due to its flexibility of compile targets. My only gripe (and its relatively small) is I don't like its compiler directive syntax using the `{.directive.}` style, its a little ugly and noisy to me, I'd prefer something like rust's `#[]` (I think this is actually how you use a Rust macro, but its a nice syntax regardless) Not enough to stop me from thinking the language has some real upside and potential, though.

michaelsbradley 6y ago
Qt + DOtherSide/NimQML is working out to be a decent GUI framework for desktop app development. https://github.com/filcuc/DOtherSide https://github.com/filcuc/DOtherSide https://github.com/filcuc/nimqml https://github.com/filcuc/nimqml LGPL compliance is an important consideration owing to Qt's being LGPL licensed, but it's actually not a big deal despite there being a lot of FUD around it: https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...
GavinMcG 6y ago
Why even bring up that style gripe? You acknowledge it's relatively small and inconsequential. If you're excited to see where the language goes, don't drag things down with completely subjective aesthetic criticisms.
- athenot 6y ago
  I wasn't a huge fan of that style too but it's growing on me. More importantly, it's worth noting that this is also intended for experimental features which can eventually become part of the language syntax. eg: proc hello(greeting: string): string {.noSideEffect.} became func hello(greeting: string): string
- no_wizard 6y ago
  Simply, I'm not one to give praise through a rose colored lens. This is especially true in a place like HN, where its entirely possible the core maintainers of a project may read my feedback, and may or may not feel inclined to clarify, quantify, or at least acknowledge what I have to say about a project. I'm not bringing it down by being honest in how I feel. My praise for nim is genuine and forthright, and I've recommended many others looking to get more performance coming from a Python background give it an honest look. This is completely subjective, but I don't like 'ugliness' in a syntax. Sometimes it can be changed, sometimes it can't, and it is what it is, I get that, doesn't mean I won't mention it. There's a certain beauty to how a syntax looks when being written, IMO. Why else would developers spend so much time on theming, font choices etc for their editors? :) tl;dr I'm not one to shy away from giving honest feedback
  - GavinMcG 6y ago
    And where criticism is substantive, that's valuable. It isn't in this case, and it's hardly dishonest to keep subjective preferences in their place: within our own heads. There's a culture of reflexive criticism in intelligent communities, and I think it has negative side effects we haven't acknowledged. Yeah, it feels good to give one's full-throated opinion without bothering to edit oneself, but we build a better world with more encouragement and more restraint when it comes to nitpicking.
    - Aeolun 6y ago
      We’re kind of in a place where we are discussing those preferences though. Personally something that looks so silly stresses me out enough to either not use the feature or not use the language, so I’m kind of happy for the comment. You may think that’s shallow, but if I have a hundred languages to choose from, a few of which check all the boxes, I’ll go with those.
arc776 6y ago
Regarding GUI, there is also https://github.com/yglukhov/nimx https://github.com/yglukhov/nimx which is based on OpenGL. > Nimx officially supports Linux, MacOS, Windows, Android, iOS, Javascript (with Nim JS backend) and Asm.js/WebAssembly (with Nim C backend and Emscripten).
- qmmmur 6y ago
  The web example leaves a lot to be desired honestly.
  - arc776 6y ago
    Fair enough, I feel like some antialiasing on the fonts would make it look a lot nicer.
matthiaswh 6y ago
Not to harp too much on your nitpick of the syntax, but I'm curious why `#[]` rates as more attractive to you than `{..}`? To me they are equally utilitarian, and I can't figure out why one would be strongly preferable. That said, I do find the placement of Nim pragmas to be cumbersome, resulting in really long lines or awkward line breaks. I wish we could place the pragma declaration on the line before procedures. proc callme(formatstr: cstring) {.exportc: "callMe", varargs.}
- akiselev 6y ago
  Haven't used Nim yet but I've used a DSL with that syntax (in anger) - it really sticks out as distracting visual noise since I'm used to curly braces for code blocks and brackets for array/object access. Since the latter are less common in most code, take up far less space, and provide a relatively useless visual signal compared to code blocks, I've learned to tune them out during navigation and light reading, which comes free on demand when adopting a new language. The curly braces, however, draw the eye and often come as annotations on things that share names or structures with what I'm looking for or trying understand or remember, confusing the whole process and causing mental "cache misses," if you will. I find many of Rust's macros annoying for a similar reason, since they'll often be at the root of a module or function but for various complicated reasons can't have leading expressions - you can't make user macros that look like `macro_rules! your_macro_name {...}` or control flow like `match expr {...}` - so they're in an uncanny valley that's just as distracting.
hobby-coder-guy 6y ago
> , it'd be nice to do a differential build where it would compile down to ES5 and/or ES2015/ES2016 at the users discretion) Why?
- RussianCow 6y ago
  To make the output smaller for those not interested in targeting older browsers.
xyb 6y ago
> My only gripe (and its relatively small) is I don't like its compiler directive syntax using the `{.directive.}` style, its a little ugly and noisy to me, I'd prefer something like rust's `#[]` (I think this is actually how you use a Rust macro, but its a nice syntax regardless) Me too. I think the `{.directive.}` style comes from pascal[1], but put it at the end of the procedure definition line. Lines that are too long are not easy to read. It would be better if each directive syntax had its own line. [1] https://www.freepascal.org/docs-html/current/prog/progse5.html https://www.freepascal.org/docs-html/current/prog/progse5.ht...

michaelsbradley 6y ago

Qt + DOtherSide/NimQML is working out to be a decent GUI framework for desktop app development. https://github.com/filcuc/DOtherSide https://github.com/filcuc/DOtherSide https://github.com/filcuc/nimqml https://github.com/filcuc/nimqml LGPL compliance is an important consideration owing to Qt's being LGPL licensed, but it's actually not a big deal despite there being a lot of FUD around it: https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...

GavinMcG 6y ago

Why even bring up that style gripe? You acknowledge it's relatively small and inconsequential. If you're excited to see where the language goes, don't drag things down with completely subjective aesthetic criticisms.

athenot 6y ago
I wasn't a huge fan of that style too but it's growing on me. More importantly, it's worth noting that this is also intended for experimental features which can eventually become part of the language syntax. eg: proc hello(greeting: string): string {.noSideEffect.} became func hello(greeting: string): string
no_wizard 6y ago
Simply, I'm not one to give praise through a rose colored lens. This is especially true in a place like HN, where its entirely possible the core maintainers of a project may read my feedback, and may or may not feel inclined to clarify, quantify, or at least acknowledge what I have to say about a project. I'm not bringing it down by being honest in how I feel. My praise for nim is genuine and forthright, and I've recommended many others looking to get more performance coming from a Python background give it an honest look. This is completely subjective, but I don't like 'ugliness' in a syntax. Sometimes it can be changed, sometimes it can't, and it is what it is, I get that, doesn't mean I won't mention it. There's a certain beauty to how a syntax looks when being written, IMO. Why else would developers spend so much time on theming, font choices etc for their editors? :) tl;dr I'm not one to shy away from giving honest feedback
- GavinMcG 6y ago
  And where criticism is substantive, that's valuable. It isn't in this case, and it's hardly dishonest to keep subjective preferences in their place: within our own heads. There's a culture of reflexive criticism in intelligent communities, and I think it has negative side effects we haven't acknowledged. Yeah, it feels good to give one's full-throated opinion without bothering to edit oneself, but we build a better world with more encouragement and more restraint when it comes to nitpicking.
  - Aeolun 6y ago
    We’re kind of in a place where we are discussing those preferences though. Personally something that looks so silly stresses me out enough to either not use the feature or not use the language, so I’m kind of happy for the comment. You may think that’s shallow, but if I have a hundred languages to choose from, a few of which check all the boxes, I’ll go with those.

arc776 6y ago

Regarding GUI, there is also https://github.com/yglukhov/nimx https://github.com/yglukhov/nimx which is based on OpenGL. > Nimx officially supports Linux, MacOS, Windows, Android, iOS, Javascript (with Nim JS backend) and Asm.js/WebAssembly (with Nim C backend and Emscripten).

qmmmur 6y ago
The web example leaves a lot to be desired honestly.
- arc776 6y ago
  Fair enough, I feel like some antialiasing on the fonts would make it look a lot nicer.

matthiaswh 6y ago

Not to harp too much on your nitpick of the syntax, but I'm curious why `#[]` rates as more attractive to you than `{..}`? To me they are equally utilitarian, and I can't figure out why one would be strongly preferable. That said, I do find the placement of Nim pragmas to be cumbersome, resulting in really long lines or awkward line breaks. I wish we could place the pragma declaration on the line before procedures. proc callme(formatstr: cstring) {.exportc: "callMe", varargs.}

akiselev 6y ago
Haven't used Nim yet but I've used a DSL with that syntax (in anger) - it really sticks out as distracting visual noise since I'm used to curly braces for code blocks and brackets for array/object access. Since the latter are less common in most code, take up far less space, and provide a relatively useless visual signal compared to code blocks, I've learned to tune them out during navigation and light reading, which comes free on demand when adopting a new language. The curly braces, however, draw the eye and often come as annotations on things that share names or structures with what I'm looking for or trying understand or remember, confusing the whole process and causing mental "cache misses," if you will. I find many of Rust's macros annoying for a similar reason, since they'll often be at the root of a module or function but for various complicated reasons can't have leading expressions - you can't make user macros that look like `macro_rules! your_macro_name {...}` or control flow like `match expr {...}` - so they're in an uncanny valley that's just as distracting.

hobby-coder-guy 6y ago

> , it'd be nice to do a differential build where it would compile down to ES5 and/or ES2015/ES2016 at the users discretion) Why?

RussianCow 6y ago
To make the output smaller for those not interested in targeting older browsers.

xyb 6y ago

> My only gripe (and its relatively small) is I don't like its compiler directive syntax using the `{.directive.}` style, its a little ugly and noisy to me, I'd prefer something like rust's `#[]` (I think this is actually how you use a Rust macro, but its a nice syntax regardless) Me too. I think the `{.directive.}` style comes from pascal[1], but put it at the end of the procedure definition line. Lines that are too long are not easy to read. It would be better if each directive syntax had its own line. [1] https://www.freepascal.org/docs-html/current/prog/progse5.html https://www.freepascal.org/docs-html/current/prog/progse5.ht...