Matthias Endler, a Rust developer, writes about Rust, performance, tooling, and building small web and software projects.
HN links it for Rust tips, such as faster compile times, and for the author's comments on static sites, hosting, and small tools.
> and in particular, that they are entirely inherent to the language.
But... this is true. The design of the language is biased to make slow compiling across the full pipeline.
Is possible to get into a shout contest about this :), so just look at what Pascal(Delphi) do and how absurdly fast it is, despite the fact is still a "batch compiler".
So in the presence of pascal (that is even more complex than Go, to be a really close to C/C++ in capabilities) is clear that Rust is MADE to be slow.
And to the point, I used more than +12 languages already, super popular things like this:
https://endler.dev/2020/rust-compile-times/
NOT exist for Delphi. The "how make delphi compile fast" is to just use delphi. It will compile fast.
Cat is an interesting example because it's not as trivial as it seems, especially when it comes to performance and resilience:
https://endler.dev/2018/fastcat/
https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/
I think this is one of these "not built here" discussions. It's very easy to underestimate the number of edge-cases to support especially in the case of network transfer. You start implementing your own, then you've got to handle non standard certificates, 300 redirects, temporary failures, backoff strategies, optimizing chunk size, handling proxy calls, etc. Using a standard library makes sense.
Author here. I love and use both.
For static sites, Zola is super nice: it's fast, has a great community, no thrills, and it gets better all the time. The config options are sensible and the templating engine is easy to learn. Sites I'm maintaining with Zola: https://endler.dev/, https://hello-rust.show/
For dynamic content, I love Gatsby. It can read from whatever you throw at it: Files (Markdown, plaintext, YAML), APIs (e.g. Github),...
I'm not a frontend dev so my React knowledge is quite limited, but it's enough for simple components.
Sites I'm maintaining with Gatsby: https://analysis-tools.dev/
This is a "reader mode as a service" just like the Reader View in Firefox/Safari, but with a focus on beautiful typography, it works across all browsers and it provides shareable links (without the need of extensions)
It's very basic, but it can be used to read articles on older devices such as old eBook readers and it could also make content more accessible in regions with low bandwidth or while travelling.
It's available here: https://readable.shuttleapp.rs/
The tutorial on how it was built is available here: https://endler.dev/2022/readable/
(credits to Matthias Endler)
> In our case, we are doing the same for around 50 clients, so it sums up :-)
Wow, so AWS is actually a better value for you than for most people. Being able to easily script and deploy your infra is hugely valuable when you have so much overhead.
We heavily use Elastic Beanstalk for dozens of running services, and it's amazing. We don't think about infra at all.
> for publishing something to the outside world from EKS
But why are you using Kubernetes at all? What problem is it solving for you?
See also: https://endler.dev/2019/maybe-you-dont-need-kubernetes/
Time to pull up my RSS reader!
https://drewdevault.com/
http://jvns.ca/
https://www.benkuhn.net/
https://danluu.com/
https://scattered-thoughts.net/
http://antirez.com/
https://www.kalzumeus.com/
https://neilkakkar.com/
https://zachholman.com/
http://rachelbythebay.com/w/
https://endler.dev/
https://www.expatsoftware.com/articles/
https://www.the-paper-trail.org/
https://tonsky.me/
https://dave.cheney.net/
https://blog.wesleyac.com/
https://blog.samaltman.com/