It's disappointing that Nim has not (perhaps cannot, for backwards compatibility) learned the same lesson here that most other modern languages have, and used explicit nilability embedded in the type system.
And to preempt the argument that "you can't, for performance reasons!", you could do the same thing as Rust does and explicitly opt-in to having your code break if something is nil, via a call like `.unwrap()` which the compiler may optimize away.
[1] https://www.infoq.com/presentations/Null-References-The-Bill...
What!? What that even means? Value types can't be nil in nim-lang, these are always initialized, but you can use Option[T] when you need it.
If you mean reference types (`ref`) hopefully this PR will land soon https://github.com/nim-lang/Nim/pull/15287.
Likewise, your type system can prevent you from using uninitialized values in other languages, without the need for Option (and indeed the unwrap() call you imply you would have used) from being needed.
Though yes, I'm glad to see this is being addressed :).
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.
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...
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.}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.
> Nimx officially supports Linux, MacOS, Windows, Android, iOS, Javascript (with Nim JS backend) and Asm.js/WebAssembly (with Nim C backend and Emscripten).
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...
Why?
proc hello(greeting: string): string {.noSideEffect.}
func hello(greeting: string): stringI'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
I've yet to encounter a small enough project with low risk where I could get away with trying something completely new, but I'm looking forward to trying Nim in the (hopefully very near) future.
One negative thing that stood out to me was that commit messages are sometimes really bad, like "break" or "let me try". I'm not trying to bash the author, but I feel it's somewhat unprofessional.
Most personal projects of this scale are labors of love and I suspect most people wouldn't mind nitpicks given in good faith if it means exposing the project to a wider audience. Though I also suspect they will be triaged towards the bottom of the pile :)
Why risk the naming confusion? Doing a search for "prologue language" yields millions of Prolog results on both DDG and Google.
Real world example: Once there was a new browser from Mozilla called Firebird. There was also a previously established RDBMS called Firebird. No one believed the browser and the RDBMS would be confused, but none the less Firebird the Browser is now called Firefox. The reason is a little confused - Mozilla at the time claimed something like "Firefox was only the code name", but I think they would have left it alone if the people from Firebird RDBMS hadn't asked them to rethink the naming.
Edit: also, searching for "prolog web framework" gets you stuff about using prolog for web application development. So, yeah, naming is not great and your assertion is not entirely correct.
The first few hits I got were:
* https://www.metalevel.at/prolog/web
* https://github.com/Anniepoo/weblog
* http://www.pathwayslms.com/swipltuts/html/index.html
And no sniff of this new framework.
Prolog is a made up word, an abbreviation for "programmation en logique". Prologue means the introductory part.
So why the confusion? I believe prolog is an excellent name for a logic PL and prologue is too for a web framework. Why change it?
I could probably come with dozen more names if I knew more about the project and after a bit of brainstorming.
Same for rails, add "ruby".
"go" is also a fun one…
Nim always was a bit lacking in webdev but with Prologue and Basolato, the web is suddenly looking much more interesting.
E: I do like it, though. Don't want to bash on the project for no reason, just would prefer it if the maintainer tried to have better commit messages!
A lazy scan right now shows over a hundred "make tests green again", a dozen "fix(up|)", handful of "WIP", etc. And beyond that a huge chunk are just "update <something>". Even with ~20k commits you can catch duplicates in a single unlucky bisect session.
I think I've come to the conclusion that /we/ in this subthread may be the problem though. Loads of projects are like that, and hardly anybody else cares. I suspect it just depends on how you are treating your VCS; I think it tells a story, others seem to think it just a snapshotting tool.
Powerful to me would be “able to create systems & applications in half the time compared to...” :)
Also, nim is a mess. Very poorly designed language. I tried it a couple of years ago and was repelled by its syntax and attempts to solve every single problem for you.
That is standard for Micro service/Web framework. 2 functions and a router and you are now "Open source Web framework" author on github.
What are you talking about?