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/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#LGPLStaticVsDyn...

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

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.

Regarding GUI, there is also 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).

The web example leaves a lot to be desired honestly.

Fair enough, I feel like some antialiasing on the fonts would make it look a lot nicer.

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

> , 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?

To make the output smaller for those not interested in targeting older browsers.

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.

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

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

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.

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.

I think even that is a reasonable comment to make. It's criticism of things that don't impact your decision (as in the comment I responded to) that offer negative value, in my view.

The critique is more substantive than your critique of the critique, especially when you keep dogging on them after they were kind enough to explain it further.