ajusa

(author here)

It's exactly this - I do regret using "db" a bit now after reading all of the comments here, as it's taken away focus from the main point. But yes, the post had to fit on a single page, and I needed to pick something that most engineers would be familiar with.

(author here)

This is actually closer to the way the first draft of this article was written. Unfortunately, some readability was lost to make it fit on a single page. 100% agree that a statement like this is harder to reason about and should be broken up into multiple statements or chained to be on multiple lines.

Which book is being read in that screenshot? Looks interesting. I did a few searches based on the text and couldn't find it.

I still have a Dell Latitude D820 kicking around at home with the same display specs. I threw in a 256gb SSD, 4GB of RAM, and might have upgraded the CPU (can't remember exactly). According to what I can find online, it retailed for $2290 USD ($3500 today adjusting for inflation). I'm assuming you are talking about the non-business line Dell had back then (Inspiron?) if it was inexpensive.

I'm always surprised by how circular technology can seem, even hardware. Obviously display technology has gotten a lot better over the years (IPS/OLED, lower power consumption, higher max brightness) but the fact that I'd be perfectly happy with a laptop with a 16:10 1920x1200 display today (almost 20 years later) is funny to me.

Honestly - CLI apps that need to run on multiple platforms. I once built a version of https://github.com/lovebrew/lovebrew (back when it was written in Nim) using Cosmopolitan 2, and I got back a single binary that ran on all major operating systems.

This greatly reduces the time GitHub actions would need to run, as you just build and release for one OS. As others have mentioned, this does not really work for native GUI apps, that isn't supported by Cosmopolitan as far as I know. But for small CLI tools it works great!

https://github.com/yglukhov/nimpy gives very, very solid access to the Python ecosystem from Nim - I've copied code from Python docs and have had it work with hardly any changes. Hopefully that's a good enough excuse to try Nim out for a personal project!

This is a really fantastic resource for learning programming with Nim. I've started recommending it to folks that are newer to programming that want to try Nim out for various reasons. The only downside is that it is written by a non-native english speaker, so some of the phrasing feels awkward at times. Of course, that's a non issue for this kind of technical material, it's very understandable and useful! You can also view the source of this material here: https://github.com/StefanSalewski/NimProgrammingBook

For folks that are more experienced and learn by doing, the two resources I would recommend are https://nim-by-example.github.io/ and https://xmonader.github.io/nimdays/. The first is a solid overview of the basic language, while the second is a bunch of example projects. Other good resources if anyone is interested:

Nim in Action (book)

https://narimiran.github.io/nim-basics/

https://scripter.co/notes/nim

The official Nim tutorial: https://nim-lang.org/docs/tut1.html

Nim also had a devroom at FOSDEM this year! You can find it at https://fosdem.org/2022/schedule/track/nim_programming_langu....

My favorite talks were on Polymorph (a really fast compile time ECS), Pararules (a super cool implementation of a rules engine) and Nim Metaprogramming in the real world (very useful lesser known patterns for using Nim's capabilities in a variety of projects).

Yeah, that must be a Safari thing. I pulled out my Nexus 5 (circa 2013) and everything feels instant. I don't have any working iOS devices lying around to test on unfortunately.

Sorry for that (and thanks to all the folks that pointed out the word matching code was wrong). I've pushed an updated version, it's 63 lines now.

Turns out, HN finds and reports bugs much faster than family and friends :)

Looks like they doubled the size by accident, in the network debugger the first is a 302 that resolves to the actual file. It shows 84kb twice because of that.

Yep, I have the wrong meta tag I believe:

        <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />

That should fix it, I'll push a new version after fixing the word matching issue others have pointed out. I underestimated Wordle's complexity :)

Yup, exactly. I've considered adding a bloom filter check for words but I've accomplished what I wanted to try out. Maybe if I'm ever interested in the future!

It'd be very easy to check against just a list of words, but that'd require more storage and be slower than a bloom filter.

Oh wow, I never noticed that myself. I'll fix it once I'm at my computer, thanks for pointing it out! The fix will probably be something like

    if letter not in (.bg-warning in first .guess).innerText then add .bg-warning

Haven't tested as I'm on my phone, but seems like a simple enough fix.

+1 to what planetis mentioned. I didn't include a full explanation of the macro because I was more or less showing off a project - not doing a full tutorial of all of the internal bits and implementation details of what libraries I was using.

So in this case, the `template` bits are doing plain code substitution at compile time, and the buildHtml `macro` is doing more advanced code generation, also at compile time. This means that it should avoid the overhead you mentioned with a key-value struct/lambda.

For what it's worth, this could also have been implemented as a `proc` which would then take in a lambda/anonymous function to generate the HTML, but that incurs additional overhead and requires a bit of extra syntax, which felt like a hassle.

If I understood your point correctly you are talking about the binary size? Me naively compiling with `nim c -d:release` and running `strip` on it gives the server binary to be around 700kb, and it's dynamically linked to glibc. There are tricks and stuff to make this smaller [1], but it's already small enough and easy enough to deploy.

Plus Nim is fast! I can load the index page of this application at 90k requests per second single-threaded on a laptop from a few years ago.

[1]: https://hookrace.net/blog/nim-binary-size/

As far as Nim's dependencies go in this case, it's literally just Karax (no dependencies), Jester (depends on httpbeast which has no dependencies) and treeform's ws library (no dependencies). So the only thing in this chain that isn't transparently being used is httpbeast. Thankfully I've read through that code and contributed a bit to that project, so I can reasonably trust it.

Nim has a smaller community, so the supply chain tends not to be more than one or two levels deep in my experience. This is also because the standard library is fairly large.

(Author here) Thanks! The inputs aren't sanitized in this example, but the output (the generated HTML) actually is in this case. Specifically this part:

  text ": " & sentMessage.getStr()

The `text` function in the Karax DSL is actually escaped once it is converted to a string, see https://github.com/karaxnim/karax/blob/c71bc927494418c3f52f9... for the implementation if you are curious. There is a way to render raw HTML using `verbatim` instead of `text` in Karax.

So in this case, I believe it would be protected against XSS to some extent, but I obviously haven't done an in depth security check for a demo/simple project. There are plenty of other potential issues as well (username collisions, websocket errors, user lists) but I judged those to be out of the scope of a simple project like this.

In case you want a quick example of a backend application in Nim, I've written a small post[1] describing how to create a room based chat using it and HTMX. In total, it's around 70 lines of code (though it doesn't cover more advanced use cases, like username collision). I too have moved from Go to Nim, the syntax and ease in which I can turn a feature into code has been much better.

[1]: https://arhamjain.com/2021/11/22/nim-simple-chat.html

I doubt it for two reasons:

1. nginx has had many more years of performance tuning (it's 17 years old) than a project made in the last few years.

2. redbean is x86 only if I'm not mistaken (it's using x86-64 from αcτµαlly pδrταblε εxεcµταblε), whereas lowtechmagazine runs their server on an ARM CPU. I think switching to a lower powered x86 chip might be costly or still draw too much power, but I don't have as much experience in that regard.

Haha, this is just a school project so I don't think they'll go after me. We struggled with coming up with a name though, just picked one so that we could submit it. If there was a ton of feedback or interest we'd probably rename, but I consider this to be a small finished utility.

Hello HN!

I'm sharing a small project I built with two other students. We built it in three weeks for a UI/design class back in April of this year. Nestly is a nested time tracker. It's similar to Dynalist and Workflowy in the sense that you can nest items as much as you want, but in this case each item is something that can be individually time tracked. It also supports rudimentary tagging (for cross item tracking) and time breakdown graphs.

Sites like toggl only supported two (maybe three?) layers of tracking, which always put me into decision paralysis - was I organizing my time categories in the right way? Would I need to revamp the whole system in the future as my roles and responsibilities changed? Infinite nesting solves that problem (though it doesn't work for everyone).

Note that the project was primarily built for a class - we don't anticipate working on it more or adding a bunch of new features. It's in a "finished" state.

The site was built with Tachyons, using the Nord color scheme, and VueJS. There is no backend - all data is persisted locally on the machine itself. I'm happy to answer any questions about the tech stack or anything else!

Nope, Ryzen 3500u with integrated graphics :)

There were quite a few issues with amdgpu that would get fixed in certain kernel/video driver updates, and broken in other ones.

The really nice thing about `dnf` is that you can easily downgrade or rollback an update. There's also an easy way to see all of the packages that have been installed by the user to help track down when or what broke a system (which I haven't had to use yet, but it is nice to have).

Flatpak + user maintained copr's have been mostly able to fill that void for me. The only package I've had to compile so far (that would have been available in the AUR) is wrk, a HTTP benchmarking tool. There is a copr available for it, but it doesn't seem to have builds for Fedora 34/35.