Prologue: A web framework written in Nim | Hacker News Reader

Prologue: A web framework written in Nim

github.com

188 pointsflywind71 comments

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.

[1] https://www.infoq.com/presentations/Null-References-The-Bill...

I am the guy assigned to work on that: sorry for the delay, but it is being worked on.

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

This is currently being remedied as we speak:

https://github.com/nim-lang/RFCs/issues/250

https://github.com/nim-lang/Nim/pull/15287

> ... allowing values (yes, not all values, but important ones) to be nil ...

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.

Reference types were indeed what I was referring to.

https://nim-lang.org/docs/options.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.

All the convenience and all the unsafety of C code while interacting with C code? Why not just use C, or C++ if expression power is needed?

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.

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.

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.

Considering he's offerring his work up for free, it seems very nitpicky to me

"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 :)

I guess all roads do lead to Prolog.

Why risk the naming confusion? Doing a search for "prologue language" yields millions of Prolog results on both DDG and Google.

This project isnt a language, it's a framework. Searching "prologue framework" or "prologue web framework" returns this repo as the first result.

But is is confusing if you know what Prolog is.

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.

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

Re-read what the comment I replied to said:

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

> Also - fuzzy search as mentioned.

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.

The edit? No. Why would it be a typo? You assume everyone's first language is English, right?

So, it really depends on your search engine. Using 3 different ones, assuming my English spelling is less than stellar, only looking at the first page:

"Prolog Web framework"

Duck Duck Go/ Bing/ Google: all prolog

"Prologe Web framework"

Duck Duck Go: 5th hit is Prolog based

Bing: 7th hit is prolog

Google: first hit prolog

So yeah - there is a possibility of confusion.

> If someone told me about that “C programming language” I could easily transliterate that as “sea” or misremember it as “B”.

If you knew nothing about programming and technology. I counter that if someone told be about "Prologue" I would assume "Prolog". I wonder why "Nim" would come in to it? I don't know about you, but I don't go around saying "I wrote apps in MFC in C++ in the 90's", or "I write ASP.Net applications in C#". I think the framework stands alone, surely? The language is an implementation detail, and I guess Prologue might one day be ported to another platform if it is really all that good?

The issue is that your position is people something like - should be intelligent enough to know what is meant by a phrase. My position is that you are massively underestimating the issue with the words basically looking and sounding the same. Your attempt at a counter is a weak argument about how people might dramatically misremember facts anyway.

I think I looked at your history, and this is not the first time you got in to a debate like this, so I'm out... it's a bad name - the creator should probably rethink it or prefix "Nim" to make it unique, but whatever.

> The edit? No. Why would it be a typo? You assume everyone's first language is English, right?

No, I was asking if it was a typo because I interpreted it as being a counter-point to the point you were trying to make. Here it is again, emphasis mine:

> Edit: also, searching for "prolog web framework" gets you stuff about using prolog for web application development. [...] And no sniff of this new framework.

I interpreted this as being critical of fuzzy matching, but I realize now you may have been giving an example of a transliteration a hypothetical searcher would make themselves, which makes more sense. Since what you described is what I consider to be the ideal behavior of a search engine, I thought it was possibly you meant to say "also, searching for 'prologue web framework'". I'm sorry I misunderstood.

> The language is an implementation detail [...]

I don't personally agree with this. If the language is important to the project (in this case, it is since this is a web framework for Nim), I would probably make a point to add that context.

> I think I looked at your history, and this is not the first time you got in to a debate like this, so I'm out...

Sincerely asking (it sounds snarky but I don't know how else to ask): is there something wrong about the way I'm arguing my position? I am not trying to be rude or anything, I just sincerely disagree. Would it be better if I just conceded or simply stopped responding?

> it's a bad name - the creator should probably rethink it or prefix "Nim" to make it unique, but whatever.

Disagree. I suppose it's my fault for arguing what clearly comes down to your opinion.

Edit:

> My position is that you are massively underestimating the issue with the words basically looking and sounding the same.

I totally understand the hypothetical issues that can come up in this kind of situation.

My position is simply that in this case the arguments against using this name are contrived and furthermore are resolved with the slightest pinch of context.

I think none mentioned here the fact that prolog and prologue are two different words.

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?

https://en.wikipedia.org/wiki/Prolog#History

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.

It's getting to be almost impossible not to have a similar name to something else.

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.

NimPrologue, NWF (NimWebFramework) etc

I could probably come with dozen more names if I knew more about the project and after a bit of brainstorming.

A lot of different words out there.

It's no different than other languagages. If I'm searching for something about the express framework, I include "js" or "node" in my search terms.

Same for rails, add "ruby".

"go" is also a fun one…

I use "golang" as a search term for go.

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.

It just seems like a minor annoying that could be trivially avoided

yeah I don't get it either

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.

Not the most relevant point, but those commit messages don't inspire confidence :/

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!

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 does not instill confidence, for sure. 1 word commit messages, and even they have some typos, also "yeah".

“Prologue is a powerful and extensible web framework written in Nim language.“

Powerful to me would be “able to create systems & applications in half the time compared to...” :)

I don't want people to create Electron in half the time ;)

So, given that Jester exists and is a thing, how does this compare to it?

Ohhh, written in Prolog at the National Institute for Mental Health https://en.wikipedia.org/wiki/Mrs._Frisby_and_the_Rats_of_NI...

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 seems nothing groundbreaking. A router, some middleware and websockets.

That is standard for Micro service/Web framework. 2 functions and a router and you are now "Open source Web framework" author on github.

Curious in what way you said it is very poorly designed other than syntax issue?

> attempts to solve every single problem for you.

What are you talking about?

Reply on news.ycombinator.com