101–110 of 116 posts
This is mindblowing synchronicity. I thought this article was one I had read this weekend for a second but checked the post date and saw it wasn't available yesterday. I'm working on trying to write a static site generator for my own personal site/blog in C++, been tinkering for a couple months. It started as a passion project in tribute to my dog that passed. GatsbyJS wasn't working (again) which is what my current…
Sorry for your loss.
Earlier quoted context omitted.
Markdown is lousy in significant part because its interactions with HTML are ridiculously complex and moderately difficult to learn, and almost no one tries to actively learn Markdown in a principled fashion, and even fewer try teaching it in a principled fashion, so it ends up unreliable and fairly unpredictable to almost everyone. Things like: if you start a “paragraph” (of which “what comes after a blank line” is…
I think here you are also somewhat proving the point because you can "go HTML", since the problem is more about markdown not kicking in. I'm mostly kidding but since we are talking about "blogs" (mostly pictures and text) it's OK for there to be a bit of jank. Remember, this is a script for you! You do not have to justify the jank to anyone! Seriously though, I think that what you're describing is a real failing of M…
I have a well-established track record of disliking Markdown because of how grossly technically unsound it is. I’m steadily designing a more principled replacement for at least my own use, drawing most significantly from reStructuredText, AsciiDoc and Markdown.
Why even bother with a static generator when you can run rust code at essentially wire speed and dynamically generate all the required formatting on the fly? Because Rust binaries are so secure, you can expose them over the internet safely. With a little bit of glue, you can automatically recompile the CGI binary every time the rs source is touched, for a dev experience similar to interpreted web scripts.
> Because Rust binaries are so secure, you can expose them over the internet safely. That doesn’t stand to reason. Safely in that you can confidently avoid things like remote code execution, sure. But that doesn’t necessarily protect you from denial of service attacks; for example, I expect most services built on Hyper to be vulnerable to slowloris attacks https://en.wikipedia.org/wiki/Slowloris_(computer_security) >…
You can of course still do stupid things inside the rust application that explode your number of concurrent requests, like waiting for slow external resources, databases etc. For a simple static formatter, it should not be the case, it would just repeatedly hit the disk cache and some minimal CPU.
Earlier quoted context omitted.
> Because Rust binaries are so secure, you can expose them over the internet safely. That doesn’t stand to reason. Safely in that you can confidently avoid things like remote code execution, sure. But that doesn’t necessarily protect you from denial of service attacks; for example, I expect most services built on Hyper to be vulnerable to slowloris attacks https://en.wikipedia.org/wiki/Slowloris_(computer_security) >…
Sorry for the lack of clarity, by "exposing the binary over the internet" I certainly wasn't implying re-implementing a HTTP server, HTTPS and certificate handling etc. You would of course have an nginx frontend that would cache the request and subtleties; the Rust FastCGI would see a well formed request, and rush to execute it just like any other dynamic language, PHP, Python. You can of course still do stupid thing…
Earlier quoted context omitted.
Sorry for the lack of clarity, by "exposing the binary over the internet" I certainly wasn't implying re-implementing a HTTP server, HTTPS and certificate handling etc. You would of course have an nginx frontend that would cache the request and subtleties; the Rust FastCGI would see a well formed request, and rush to execute it just like any other dynamic language, PHP, Python. You can of course still do stupid thing…
If you don’t mean exposing it directly, I’m not sure what’s special about Rust in what you’re saying. Compared to deliberately memory-unsafe languages, perhaps, but you’re normally comparing it to the likes of Python, PHP, Ruby and Go, all of which stand on level ground in that regard.
... but with an execution speed that consumes negligible CPU time from the moment the template/source is loaded into memory until it is formatted and put on the wire. Compared to that, a PHP template is dog slow. I don't have any direct experience with Go, small GC allocations for string handling might introduce non-negligible overhead.
I've been trying to make a cool static site generator numerous times. Well, yes, it actually is a quite fun thing to tinker with, but I've found myself struggling to decide on what do I want to see in the final app and what I do not; what features might be needed by other users and what features might be an overkill. So I ultimately went with Zola[1] and encourage you to try it too! Aaaand it is written in Rust, too.…
I ended up making mine with Pandoc + Make. At first i used Nextjs and Remark/Unifiedjs but then I had a realization that all that is not even needed.
I'm considering using Pandoc with Soupault to my website markup agnostic by being dependent on Pandoc. Soupault can act as a HTML processor although I'm not sure if that's enough to not need a template langauge. Or maybe I'm mistaken about Soupault.
Earlier quoted context omitted.
If you don’t mean exposing it directly, I’m not sure what’s special about Rust in what you’re saying. Compared to deliberately memory-unsafe languages, perhaps, but you’re normally comparing it to the likes of Python, PHP, Ruby and Go, all of which stand on level ground in that regard.
> Python, PHP, Ruby and Go ... but with an execution speed that consumes negligible CPU time from the moment the template/source is loaded into memory until it is formatted and put on the wire. Compared to that, a PHP template is dog slow. I don't have any direct experience with Go, small GC allocations for string handling might introduce non-negligible overhead.
Earlier quoted context omitted.
Your comment helped me want to click through and read the post. I'm very tired of all the recent Rust fanboy posts, but level-headed and earnest comparisons against real implementations make for much better understanding of a new concept or language. Here are some select quotes from the article: > Please note that this is not to say that Rust this [sic] much faster than Haskell, instead see it as a comparison of two…
I religiously refresh HN the last few months and I've seen exactly zero "fanboy" Rust articles. All of them outline what was gained by a switch to it and what problems were eliminated. The better ones also list tradeoffs i.e. they say what got a bit harder, too. Maybe you just have an axe to grind?
Dude, touch some grass
Earlier quoted context omitted.
I religiously refresh HN the last few months and I've seen exactly zero "fanboy" Rust articles. All of them outline what was gained by a switch to it and what problems were eliminated. The better ones also list tradeoffs i.e. they say what got a bit harder, too. Maybe you just have an axe to grind?
> I religiously refresh HN the last few months Dude, touch some grass
HN became boring in the last few years anyhow.