I've been following Nim for a while now (including back when it was called Nimrod), but the big reason I've never dug much more into it is because it repeats the Billion Dollar Mistake[1] of allowing values (yes, not all values, but important ones) to be nil without explicitly using Option types.
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.
Excellent news! I read the discussion that has since been linked elsewhere, and got the general impression that there wasn't going to be a change for backwards compatibility reasons. Glad to be proven wrong!
the default might not be changed in 1.x, but this shouldn't make it less typesafe: access to nilable types would be checked.
there are also the z3-integration related checks which might even apply to index bounds or eventually other invariants, so this kind of safety is important for Araq and Nim https://nim-lang.org/docs/drnim.html
The real question is: how much of standard libraries and broader ecosystem use them? Scala has null values, but broad usage of Option and Either so I can often write code as if null didn't exist.
Unfortunately, it'd be impossible to work effectively with C code without `nil`. You can create objects set to `not nil`. To be fair, I've had a few points when creating a new type that I forgot to allocate a new instance properly, but option types wouldn't have saved me any work. It would've produced a similar stacktrace. I think the compiler produces a warning, but I'm still working down the warning's lists. You can see more discussion on defaulting not nil here: https://github.com/nim-lang/Nim/issues/6638
Having all references that are returned from C be treated as Option types would resolve this difficulty, no?
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 :).
> Having all references that are returned from C be treated as Option types would resolve this difficulty, no?
Perhaps, but there's more than just returns. Dealing with most C code there's a fair bit of pointer passing and manipulation. It's nice being able to deal directly with C code and not have to worry about the impedance mismatch, but still be able to move up the type system. It's more a pragmatic choice.
> 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.
In this case, mostly its just me not using the type system well. :-) But that's the price I pay for a using a flexible language I can readily use in embedded work. NPE's really don't cause me any headaches compared to most of the other aspects of integrating heavily with C code in embedded systems.
Same reason as using unsafe Rust to interface w/ C/C++, to wrap the the unsafe bits and make safer API's asap. Nim's macros also making interactions with C API's safer. To be clear, I'll be glad when Nim checks these things by default (the Z3 checker will be great for that!).
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.
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:
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.
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.
> Nimx officially supports Linux, MacOS, Windows, Android, iOS, Javascript (with Nim JS backend) and Asm.js/WebAssembly (with Nim C backend and Emscripten).
> 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.
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:
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.
It's really nice to see that the Nim ecosystem is gaining more and more traction. A good web framework is indeed quite an important step towards making a language/ecosystem more appealing to a more general audience.
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.
"Unprofessional" is a tad harsh for commit messages in a personal project but the "they're doing it for free" sentiment that gets expressed in almost every HN thread about open source projects isn't helping anyone either.
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 :)
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.
> 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.
Is this a typo? I would certainly hope that a search for "prolog web framework" would not include results about a web framework written in Nim named "Prologue"
"Prolog" and "prologue" are completely different words with different meanings-- they are only homophones. It's not really analogous (at all) to the Firebird situation where the names of the projects had the exact same name, same spelling and all.
If this project were named "Sea", do you think people would conflate it with the "C" programming language?
> Is this a typo? I would certainly hope that a search for "prolog web framework" would not include results about a web framework written in Nim named "Prologue"
Unfortunately not. It's caused by fuzzy matching and happens with other words (and languages) too. Annoying but I don't think we should start avoiding certain words because google search (and some people apparently) can't make the distinction.
> searching for "prolog web framework" gets you stuff about using prolog for web application development ... And no sniff of this new framework.
The comment I replied to described that they searched for "prolog web framework", which is NOT the name of this project. The name of this project is "prologue".
"prolog" != "prologue"
Searching for "prolog web framework" should not return results about the "Prologue" web framework. What the commenter I replied to described is the correct behavior.
Edit: I understand that contrived searches might be constructed to fall victim to fuzzy matching, but what the comment I replied to confirmed is that it's probably not an issue in this case.
Well they are, but they aren't. They are both pronounced the same and if I hear one, I could easily mistake the other. If someone tells me about this "prologue web framework" I could easily transliterate that as "prolog". Also - fuzzy search as mentioned.
"Sea" and "C" are not the same ballpark. "Prolog" is a subset of "Prologue." This is more like "C" and "C#", and I can tell you that it is actually a problem.
So was your edit on the comment I replied to (repeated below) a typo?
> 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.
This is an anecdote in favor of fuzzy search not really being an issue.
> If someone tells me about this "prologue web framework" I could easily transliterate that as "prolog".
If someone told me about that “C programming language” I could easily transliterate that as “sea” or misremember it as “B”.
These are contrived situations. Imagine someone told me about “Prologue: a web framework written in Nim”, and I transliterated that to “prolog web framework”. If I searched that and it didn’t come up with a web framework written in Nim, I would think critically about the issue and change my search to “prolog web framework Nim” and would find this project.
It would be so silly to change the name or avoid the name of a completely unrelated project when ideally anyone faced with the issue would have the critical thinking skills to adjust and refine their search terms so it was not an issue.
Also it's not the first time I get garbage results from google's fuzzy matching, happens with other words too. Arguably it's annoying and should be improved instead.
As a new user, I was able to get a pronounceable(ish) 4-letter username. It's not always hard. But Prologue is an English word and a lot of English words are taken. (and probably many words in other languages, too)
When I try to search for your name, I only get hits on some country radio channel. I could search for ‘wezl hacker news’, but it would have been easier if you had chosen a non-colliding name to begin with.
sincerely asking: are you worried that anyone will suffer from this decision? Personally I can't imagine a scenario where someone actually feels any pain from this naming decision. Adding "nim" to your prologue search is par for the course for many categories of search. I laugh about how often I get guitar string ads because I'm always looking up "elixir string" documentation xD but it's not a pain point. Who suffers here? It's FOSS so the "marketing" of the project has little to do with the name I'd suspect. I mean who is going to pick a technology based on the search-ability? We're talking about decisions being made by people who are highly skilled internet searchers.
I have played around with it a bit and I just love the way the routes and middlewares are defined in this.
I think the latest and greatest v0.4 will be released shortly, so anyone who is interested, do keep an eye out.
Nim always was a bit lacking in webdev but with Prologue and Basolato, the web is suddenly looking much more interesting.
I agree. I have absolutely no idea what was changed in most of those commits. If I relied on this framework it would be a pain in the * to trace down when a potential bug was introduced, or to just get an overview of what's being worked on.
I was trying to track down a problem in the nim-lang/Nim repo, and had a similar impression. During a `git bisect` run I thought I'd made a mistake as I saw duplicate messages pop up, until I realised there are an enormous amount of duplicate messages in the repo.
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.
Thank you for this perspective: I never realized that "git bisect" is good only as long as commit messages are meaningful. I'm going to teach how to use "git" in my class next semester, and this is surely a point I will make!
I may have poorly made my point. It isn't that bisect is /only/ useful with good commit messages, but many subcommands are vastly improved when there is meaningful information about the change in the message.
For example, rebase's default output includes the previous and next commit messages when you pause to edit a commit.
It seems nothing groundbreaking. A router, some middleware and websockets.
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.
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...