2,138 karma · joined July 28, 2016
https://notado.app/feeds/jado/hacker-news-comments
https://github.com/LGUG2Z/komorebi/
https://hachyderm.io/@LGUG2Z
https://bsky.app/profile/lgug2z.com
> Roughly every three months, the book is updated to keep up with the latest developments in the Rust ecosystem. In particular, we make sure to update all the crates we use in the book to their latest released version. If you bought a copy of the ebook, you can get the latest book revision at any time by redownloading the content from here.
90%+ of what you need for a web app that you're building as a one-person show can be handled by storing state in the URL - people these days can be quick to forget that this is how large and complex web apps like GitHub have run for many, many years.
With regards to complexity in templates, I find that you can cut down on a lot of that complexity if you enforce type constraints in your templating engine's context object.
Getting in a habit of doing this early gets you thinking about ways to shift things that require conditional logic to the pre-templating stage, and more often than not it leads you to breaking down bigger templates into smaller partials and using them to compose different template variations for different views. I like this and it makes a lot of sense to me, but I'm not sure how it would feel to people who have only ever written JS SPA web apps.
[1]: https://notado.app
[2]: Example of the only place I use HTMX in Notado (to show search results as you type): https://www.youtube.com/watch?v=KMxmf132-8k
I was very lucky to get referrals from a few folks that I social dance with in Seattle after that layoff, and I ended up with a job offer in a product area I knew very little about (networking, routing, programmable packet processing middleware with eBPF etc.)
Despite my lack of domain knowledge, I was told I received the offer largely because of my demonstrated proficiency in Rust (I did all the interview whiteboarding sessions in Rust), and although this isn't something that is measured "officially" in the interview process, because there are many hours of me live programming online[2] for people to feel confident that they're not hiring a dud who has hyper-specialized in passing interviews which are not representative of real-world workloads.
I general advise people in your situation to start looking further down the world's dependency tree, where things churn less frequently, and where the skills you acquire will last longer. This can be easier said than done, but since my very first job was as a React developer, I can at least share my path down the dependency tree:
Frontend (React etc.) -> Backend (web APIs) -> Infrastructure / Platform / DevOps (started with a cloud automation focus, moved gradually towards to bare metal) -> Networking (I'm in ur VPCs, directing ur packets)
All of this being said, the job market right now is very tough. I doubt I could walk out of this job and into another within 3 months like I did this time last year.
[1]: A lot of my technical blog posts on https://lgug2z.com/articles around that time refer to this layoff
The high level of API stability and lack of churn in the Actix ecosystem makes the book a particularly good investment for someone looking to settle on this stack in my opinion. In keeping with the topic of this submission, I doubt I'd be comfortable spending money on a similar book about building web apps with React.
[1]: https://www.lpalmieri.com/posts/2020-08-09-zero-to-productio...
Last week I shipped another new web app[1] I got an idea for in <24h to closed alpha testers and in <7d to a public beta with no issues or fanfare.
Perhaps part of the increased velocity is my having gone deep and learned the ins and outs of this stack over multiple years and projects, but it is important to note that I probably would never have gained this level of mastery over these tools if I were constantly being hit with what the author calls "dependency management fatigue".
[1]: https://blucerne.app
I'm very lucky to spend the majority of my dayjob hours working on Rust code, so everyone just runs cargo fmt && cargo clippy, and this in enforced in CI. You can't even publish a PR until those basic bars have been met.
I can't imagine the absolute insanity of working on JS projects where there are more ways to do things than there are people on a team, and where getting those people with strongly held opinions about things that ultimately just don't matter to agree on style and convention is like pulling teeth.
I built something like this in a slightly different context for myself.
I doubt it'll ever really catch on widely, but I have a bunch of people who want to read my highlights about tech and nothing else who appreciate my software dev feed.[1]
I appreciated the transparency in the "Where did you get the money?" section of the website.
She actually received a great deal of backlash from "vote blue no matter who" liberals for her criticisms of Kamala Harris and the Democratic Party.
I have written here before[1] about the tyranny of "read it later" apps and how liberating it felt to ditch them and move to a "read it now or read it never" (RINORIN) mindset.
Although this articles talks about digital ephemera in different contexts such as shared spaces, wikis, runbooks etc., I believe the underlying idea is the same.
I'm still very happy with RINORIN + archiving the interesting bits of what I read in the moment[2].
[1]: "If it's not immediately interesting enough for me to read when I see it, I just let it ago, trusting that if it's important enough, I'll be exposed to it again sooner or later, and at that point it'll be interesting enough for me to read it when I see it." (https://news.ycombinator.com/item?id=38355803)
Oh hi! You must be my teammate!
I joined a team like this and just started a personal build/dev/ops tool repo in Rust for things that I needed but were not automated. Over time it has become an "official" repo and renamed to be blessed with an official "org" package prefix.
When I started this project and people were interested, I was asked why I didn't just add to the Python repo; I said that others are free to rewrite them if they want to, but I can't justify spending days messing around with Python to achieve what I can in less than 30 minutes with Rust when I need to quickly automate a tedious task.
Edit: A lot of downvotes on this, but in case it wasn't clear - the team is happy that someone took the time to scaffold a repo in Rust that everyone feels more confident in contributing to, since the overwhelming majority of the codebase is written in Rust and the Python tools repo is full of annoying runtime errors that could be trivially caught at compile time.
The end result is more people feeling more empowered to automate repetitive and tedious tasks which can easily be fudged when executed manually instead of suffering with them because someone who isn't even here anymore decided to start a tools repo in Python for a team that almost exclusively writes code in Rust.
I started with Rocket for Notado, but because there was a long period of pre v0.5 stagnation, I went with Actix for Kullish. These days I'd be happy starting a new project with either.
As for Tera over Askama, I don't think Askama was around when I started building Notado; Tera was the first templating engine I used in Rust and I learned its ins and outs pretty well, so now it's just the default thing that I reach for whenever I'm building a web app.
Similar setups (Rocket and Actix instead of Axum, Tera instead of Askama, Diesel instead of SQLx) and overall experience (incredibly cheap, reliable, and since these projects have been running a long time, amazingly easy to return to the codebases after months/years and make changes with a high level of confidence).
I distinctly remember how happy I felt the first time I realized that I had enough paying subscribers to offset the cost of the running the service!
[1]: https://notado.app
[2]: it had a decent amount of HN discussion last week - https://news.ycombinator.com/item?id=41697228
[3]: https://kulli.sh
Right now there is support for dynamic configuration through commands executed through a script at startup (like bspwmrc etc), and declarative configuration through a static file which can be hot-reloaded.
Basically all new features and documentation are declarative-first, and there is a command that can generate a declarative configuration file from a running instance configured using a dynamic configuration script.
So if you're new to the project, you probably don't even know that the older configuration method is a thing, and if you come back to the project with a very old dynamic config script after a long time, everything you remember still just works, and you're just a command away from migrating to the format that everyone else is now using.
That being said, there is definitely a whole bunch of code that I would love to get rid of some day :)
I am pleasantly surprised to see however that this unfortunate subthread produced interesting and well-intentioned comments from others.
Again, not my experience at all. I simply don't think about any of that stuff when I write Rust, all my mental energy can safely go towards working on whatever I'm building.
If you don't believe me, you're welcome to watch the literally hundreds of hours of me live coding in Rust on YouTube.
Last week I deployed a Ruby change where a missed comma between two strings in an array did not get picked up by any of the automated tooling or by 3 other team members who code reviewed my change, and ended up cutting 50+ sev2s at 10pm.
AWS folks can probably guess which internal tool I had to touch that requires Ruby.
(I was on call, fun times)
This is not my experience at all. I never think about memory management when I'm writing Rust, let alone am I "doing it" (active voice).
Your second comment is a very weird sentence that is very difficult for me to grok.
I also maintain a very popular tiling window manager now (after years of suffering through breaking configuration changes with other twms) and this is the one thing that I will not budge on as a maintainer: Breaking configuration changes are unacceptable. Period.
From the contribution guidelines on the project README[1]:
> Breaking changes to user-facing interfaces are unacceptable
> ...
> No user should ever find that their configuration file has stopped working after upgrading to a new version of komorebi.
[1]: https://github.com/LGUG2Z/komorebi?tab=readme-ov-file#breaki...
I'm an incredibly lazy developer and Rust only makes me lazier. I can pretty much turn off the part of my brain that deals with "programming language" stuff and put all that energy towards the part of my brain that deals with "building stuff" whenever I write code in Rust, because I have a high level of confidence that the language itself isn't trying to make me shoot myself in the foot at every turn.
Rust is the only language where I can open something like Notepad without an LSP or highlighting, write code for an hour without testing or compiling, and then run clippy a few times to see and make the suggested fixes. It doesn't get any lazier than that.
On the web framework topic: Rocket is the greatest "lazy developer" web framework I've ever used.
Reproducible builds are what I've found to be the most important part of any local dev experience; standing up local databases, message queues etc required for whatever is being developed has always been relatively simple in comparison.
Congratulations on the launch!
Funnily enough I apply some of these things in a different context to READMEs for my popular GitHub projects[1], but whenever I see them applied on a product page I often click away very quickly because I associate with snake oil (it wouldn't surprise me that I'm in the minority here).