I really like it.
I have been on a quest to find very simple ssgs such as this.
I have been trying to out Zola, as mentioned in the readme, but I really want to make sure there aren't things like telemetry or other random features injected in or getting added (as seems to be the case with jekyll with ai-folio or academic pages) so it takes a while to go through everything.
Ai-folio or academic pages is basically my use case or target, but I want something with zero javascript, which tends to be a bit hard in todays age.
I did something similar a few months ago in python.
One notable difference is that I got rid of the frontmatter, instead I use the commits history to find the creation and update dates of posts.
I'm not the only one (1) that believes this is wrong direction for cargo, and is abusing it's intent and purpose.
If you want to distribute an application, there are lots of ways to do that. If it's a developer tools, for developers, `cargo install` might be suitable, sure... but I think there's a fair argument to be made that if you want a tool:
git clone foo
cd foo
cargo install --path .
Is an explicit, safe and less error prone way of doing it.
...and one that doesn't walk us down the road of (see the linked thread) the obvious desire people are going to have sooner or later to cache binary builds instead of building locally, and turn `cargo install` into some kind of binary application distribution application or app store.
If you don't believe me, read that thread, and the linked thread.
I don't understand why your suggested version is more explicit, safer, or less error prone. You'll have to justify that to me!
'cargo install ripgrep' has worked on every machine I've run it on. It's also easy for me to send to other people I work with.
Your suggestion requires me go and find the repository. If I just clone the repository it's going to get the current master branch, not the most recent release (which sounds less safe and more error prone to me!)
If you have to lookup the exact crate name (and you do, because otherwise you’re installing who-knows-what) what difference does it make?
It’s just a lazy tool for lazy installs that only works when there are a) not that many people using it (easy memorable names that aren’t easy to mess up still exist), and b) no bad actors squatting on typo names.
You can’t be more explicit than “build and install this folder I have”.
You also can't be more explicit -- and terse -- by running `cargo install ripgrep`.
You said: IF you have to lookup the exact crate name. Well, for 90% of those I use, I don't have to. And it works just fine as your parent commenter said.
You have a preference, cool, but don't try to push it as the better way in an objective sense because it's not. It's just one of the alternatives.
You have no idea what that command does. It fetches something off the internet and builds it and installs it.
It is objectively less explicit than having a local folder that you have explicitly fetched, and run a build on.
It is also objectively easier to make a mistake when you type a single command that fetches and installs as one step, than it is to clone, and review then build it.
So, apart from being objectively wrong, I do agree with you; for now, it is easy, convenient and honestly, good.
However, I think you’re being extremely short sighted.
As I said, and as you can see, yourself, from the “command-install” related issues on the cargo issue tracker, the status quo isn’t gong to last. More people will use it. More people will want to distribute binary dependencies and prebuilt binaries.
We are walking blindly into a future where a “cargo install marmelaide” (whoops, was it marmite? Did I spell it right?) installs what you didn’t expect it to, and where people increasingly pressure for more features to be added to cargo to support, the obvious lack of features cargo install currently has (again, read the issue tracker if you doubt me or for some reason think I'm making this up).
I don't support that; but sure, that's just my opinion.
There are other fully featured better designed alternatives. Cargo does not need to be, or should be, a dumpster fire of features in order to be a generic cross platform application distribution tool.
The command you suggest also festches something from the internet and builds it. You could just as easily typo and get someone else's git repository, and again, I'm not going and reading the source code to find out if I have the right program.
I'm not reviewing the source code to ripgrep, and even if I did, I'm definately not review the code of all of it's dependancies, which are getting downloaded when I build it anyway.
Also, it's not objectively easier to make a mistake when you type one command, than when you type three. I would say my error rate goes up as I type more, so I feel it's objectively easier to make a mistake with your method.
Also, why not have cargo install stuff? It already does. If it makes ten thousand's people lives easier, by letting them type one line instead of three, and have to go find the right git repository to clone, then surely that's better?
Also, you still haven't discussed that your method does the (in my opinion) clearly wrong thing of building whatever the current state of the master branch is, rather than a release.
The own thread you linked is clear as day: cargo install is good and should continue to be used as way to install binaries _by building them_
Your objection then or thinking invoking cargo install at all is abuse is highly questionable. In fact, I would wager that vast, vast majority of the Rust community vehemently disagrees with you.
In the own thread you linked there is community support for binary installs with cargo bininstall
I just tried `cargo binstall marmite`, but it feels (in this case?) that it was the same as doing `cargo install`. Anyway, if you have cargo (ergo, the whole rust toolchain), you might as well explicitly download the git repo, as things need to be downloaded when you do a plain `cargo install` as well. A rust-sanctioned way to get just binary builds that do not require the whole rust toolchain installed would be best. There is a single-binary `cargo-binstall` but that only works when there is made provision by the crate to make a binary available.
Confirmed, cargo-binstall is not configured for Marmite, so cargo will fall back to install, and the single-binary cargo-binstall will try its heuristics which do not detect
ubuntu-latest-binary.zip or
macos-latest-binary.zip.
The fact people still add "written in Rust" to HN submissions is almost as funny as how effective it is, which itself is almost as funny as the fact that people like me can't stop commenting on it.
For me it means I can fork the repo and start hacking on the code immediately, and it will have reasonable quality.
With C++/Python and even Node I often find myself wasting half a day just getting it to build.
Yep. If it's a Python project, it's about a 60% chance it won't run on the first try after a fresh clone.
When I see a CLI tool written in Rust or Go, it usually just works out of the box without having to mess around with godawful pip environments or conda.
I say this as someone who cut their teeth on and loves Python for a thousand reasons, I have to agree. Python projects are abysmal. Rye and UV are promising (and I am very excited about them), but they aren't quite ready yet.
"Written in Rust" carries with it significant promises that only Go also has. (Go has a lot of the same promises, for having good tooling and the same mostly-statically-compiled philosophy.)
"Written in Rust" tells me a project is easy to install and easy to hack on. I am far less interested in using non-Rust projects, and I am definitely disinterested in making code contributions to non-Rust projects.
Case in point: It took me much longer to write this comment than it took to install and use marmite.
This. It's basically about average quality. It's the old Python Paradox all over again. Javascript / Typescript is the bottom of the barrel in terms of quality. Python / C++ is higher than that. And Rust is at the top.
I first posted without mentioning "marmite" neither "Rust", then a friend reminded me that both things would engage. People are very triggered by those words.
Well that's sadly true, I am hopeful they'll grow up one day but who knows, there are people on HN who love their prejudice as much as they love their kids, it seems.
Indeed. The blazingly fast speeds of compiling all of the elements that make up arch from scratch (just to say "I use Gentoo"), over that of just using the iso always amazes me.
Only a few years more of my life lost to check all of the code of Linux and ensure I know what is running. I'm not bitter about and looking for better solutions to that at all.
> Marmite is a sticky, dark brown paste with a distinctive, salty, powerful flavour and heady aroma. This distinctive taste is represented in the marketing slogan: "Love it or hate it." Such is its prominence in British popular culture that Marmite is often used as a metaphor for something that is an acquired taste or polarises opinion.
Aren't trademarks attached to specific goods and services? In other words the trademark protecting the yeasty food spread based does not prevent someone from using the word for something like a record label: https://www.marmiterec.com or a static site generator.
[offtopic] I just noticed that my original post title has been edited (not by me) and the part where it said `written in Rust` has been removed.
I see other posts on the page showing `built with Python`, `Python based`, why `written in Rust` was not allowed? just curious.
I really like it. I have been on a quest to find very simple ssgs such as this. I have been trying to out Zola, as mentioned in the readme, but I really want to make sure there aren't things like telemetry or other random features injected in or getting added (as seems to be the case with jekyll with ai-folio or academic pages) so it takes a while to go through everything.
Ai-folio or academic pages is basically my use case or target, but I want something with zero javascript, which tends to be a bit hard in todays age.
You can start a new theme with marmite and remove the little JS it has to switch white/dark modes.
Have you ever written your own? Definitely worth it even just for fun.
I did something similar a few months ago in python. One notable difference is that I got rid of the frontmatter, instead I use the commits history to find the creation and update dates of posts.
https://github.com/HenriTEL/gitblog2
Interesting, it would nice to have it as optional feature, I don't want it to be dependent on git, but if git is already there would be an option.
> cargo install marmite
I'm not the only one (1) that believes this is wrong direction for cargo, and is abusing it's intent and purpose.
If you want to distribute an application, there are lots of ways to do that. If it's a developer tools, for developers, `cargo install` might be suitable, sure... but I think there's a fair argument to be made that if you want a tool:
Is an explicit, safe and less error prone way of doing it....and one that doesn't walk us down the road of (see the linked thread) the obvious desire people are going to have sooner or later to cache binary builds instead of building locally, and turn `cargo install` into some kind of binary application distribution application or app store.
If you don't believe me, read that thread, and the linked thread.
[1] - https://github.com/rust-lang/cargo/issues/13994#issuecomment...
I don't understand why your suggested version is more explicit, safer, or less error prone. You'll have to justify that to me!
'cargo install ripgrep' has worked on every machine I've run it on. It's also easy for me to send to other people I work with.
Your suggestion requires me go and find the repository. If I just clone the repository it's going to get the current master branch, not the most recent release (which sounds less safe and more error prone to me!)
Crates.io is a flat namespace.
If you have to lookup the exact crate name (and you do, because otherwise you’re installing who-knows-what) what difference does it make?
It’s just a lazy tool for lazy installs that only works when there are a) not that many people using it (easy memorable names that aren’t easy to mess up still exist), and b) no bad actors squatting on typo names.
You can’t be more explicit than “build and install this folder I have”.
/shrug
You also can't be more explicit -- and terse -- by running `cargo install ripgrep`.
You said: IF you have to lookup the exact crate name. Well, for 90% of those I use, I don't have to. And it works just fine as your parent commenter said.
You have a preference, cool, but don't try to push it as the better way in an objective sense because it's not. It's just one of the alternatives.
What you’re written it literally false.
You have no idea what that command does. It fetches something off the internet and builds it and installs it.
It is objectively less explicit than having a local folder that you have explicitly fetched, and run a build on.
It is also objectively easier to make a mistake when you type a single command that fetches and installs as one step, than it is to clone, and review then build it.
So, apart from being objectively wrong, I do agree with you; for now, it is easy, convenient and honestly, good.
However, I think you’re being extremely short sighted.
As I said, and as you can see, yourself, from the “command-install” related issues on the cargo issue tracker, the status quo isn’t gong to last. More people will use it. More people will want to distribute binary dependencies and prebuilt binaries.
We are walking blindly into a future where a “cargo install marmelaide” (whoops, was it marmite? Did I spell it right?) installs what you didn’t expect it to, and where people increasingly pressure for more features to be added to cargo to support, the obvious lack of features cargo install currently has (again, read the issue tracker if you doubt me or for some reason think I'm making this up).
I don't support that; but sure, that's just my opinion.
There are other fully featured better designed alternatives. Cargo does not need to be, or should be, a dumpster fire of features in order to be a generic cross platform application distribution tool.
I don't see that as being controversial. /shrug
The command you suggest also festches something from the internet and builds it. You could just as easily typo and get someone else's git repository, and again, I'm not going and reading the source code to find out if I have the right program.
I'm not reviewing the source code to ripgrep, and even if I did, I'm definately not review the code of all of it's dependancies, which are getting downloaded when I build it anyway.
Also, it's not objectively easier to make a mistake when you type one command, than when you type three. I would say my error rate goes up as I type more, so I feel it's objectively easier to make a mistake with your method.
Also, why not have cargo install stuff? It already does. If it makes ten thousand's people lives easier, by letting them type one line instead of three, and have to go find the right git repository to clone, then surely that's better?
Also, you still haven't discussed that your method does the (in my opinion) clearly wrong thing of building whatever the current state of the master branch is, rather than a release.
It's wild you're ending all your comments with /shrug - You made a bad take, double downed, and continue to dig.
/shrug
The own thread you linked is clear as day: cargo install is good and should continue to be used as way to install binaries _by building them_
Your objection then or thinking invoking cargo install at all is abuse is highly questionable. In fact, I would wager that vast, vast majority of the Rust community vehemently disagrees with you.
In the own thread you linked there is community support for binary installs with cargo bininstall
bininstall is a third party project.
There’s nothing wrong with building an app store in rust; I’m just saying that it shouldn’t be part of cargo.
> brew install cargo-binstall
…and it is not. It’s a great project, and if you want to use it, you can.
Using rust does not opt you into using it, just like it doesn’t opt you into using brew.
My goal is to build binaries and have it distributed to the most used package indexes out there, I didn't get there yet.
I just tried `cargo binstall marmite`, but it feels (in this case?) that it was the same as doing `cargo install`. Anyway, if you have cargo (ergo, the whole rust toolchain), you might as well explicitly download the git repo, as things need to be downloaded when you do a plain `cargo install` as well. A rust-sanctioned way to get just binary builds that do not require the whole rust toolchain installed would be best. There is a single-binary `cargo-binstall` but that only works when there is made provision by the crate to make a binary available.
Confirmed, cargo-binstall is not configured for Marmite, so cargo will fall back to install, and the single-binary cargo-binstall will try its heuristics which do not detect ubuntu-latest-binary.zip or macos-latest-binary.zip.
Good catch, I will try to learn how cargo-binstall works and provide the proper binary files.
There is an open issue to improve the Github Actions CI related to build and release.
I like cargo because it's an easy way to install programs. Pip and npm are used like apt and yum too.
This is a feature to me, not problem, and it has been this way for many years.
any chance of this supporting wikilinks and back references?
I just added support for wiki links and back references (internal)
https://github.com/rochacbruno/marmite/pull/95
Wikilinks is possible, already a feature of comrak parser, just have to enable it.
Need to think about back references.
In any case if the implementation is simple I would take a PR.
[stub for offtopicness]
The fact people still add "written in Rust" to HN submissions is almost as funny as how effective it is, which itself is almost as funny as the fact that people like me can't stop commenting on it.
For me it means I can fork the repo and start hacking on the code immediately, and it will have reasonable quality. With C++/Python and even Node I often find myself wasting half a day just getting it to build.
Yep. If it's a Python project, it's about a 60% chance it won't run on the first try after a fresh clone.
When I see a CLI tool written in Rust or Go, it usually just works out of the box without having to mess around with godawful pip environments or conda.
I say this as someone who cut their teeth on and loves Python for a thousand reasons, I have to agree. Python projects are abysmal. Rye and UV are promising (and I am very excited about them), but they aren't quite ready yet.
"Written in Rust" carries with it significant promises that only Go also has. (Go has a lot of the same promises, for having good tooling and the same mostly-statically-compiled philosophy.)
"Written in Rust" tells me a project is easy to install and easy to hack on. I am far less interested in using non-Rust projects, and I am definitely disinterested in making code contributions to non-Rust projects.
Case in point: It took me much longer to write this comment than it took to install and use marmite.
This. It's basically about average quality. It's the old Python Paradox all over again. Javascript / Typescript is the bottom of the barrel in terms of quality. Python / C++ is higher than that. And Rust is at the top.
I first posted without mentioning "marmite" neither "Rust", then a friend reminded me that both things would engage. People are very triggered by those words.
As someone who both loves marmite and is currently learning Rust I was unable to resist clicking.
And it worked. Congrats for reaching Front Page, Bruno!
You forgot the "blazing fast" part; that drives them bonkers LOL!
Blazing Fast New Project Written in Rust (it's a SSG btw)
> Go programmers are very triggered by those words.
FTFY
Huh? Why would that be the case?
People post "Something Written in Go" all the time and no-one complains about the title, every rust post that includes that gets complaints.
Well that's sadly true, I am hopeful they'll grow up one day but who knows, there are people on HN who love their prejudice as much as they love their kids, it seems.
I hope it goes full circle into "btw I use arch" levels of parody
Well, it was 90% written on Arch :(
Gentoo is faster.
Indeed. The blazingly fast speeds of compiling all of the elements that make up arch from scratch (just to say "I use Gentoo"), over that of just using the iso always amazes me.
Only a few years more of my life lost to check all of the code of Linux and ensure I know what is running. I'm not bitter about and looking for better solutions to that at all.
Perhaps it was more parody? Since becoming vegan my mind more clear and in touch with the universe. You should try it too!
I just notice that someone (admins) edited and removed the `written in Rust` part of my post.
Not fair.. other posts have `written in Python` on it.
Why was that?
rust is just a good language to use and the ecosystem is growing every month.
> people like me can't stop commenting on it
Yeah this loop will go on with this comment, it seems.
You're gonna love it or hate it, no in between?
I actually was just having breakfast with a Marmite toast, trying to come with a name for MARkdown related project.
Never thought about how the name would trigger people haha, I love Marmite BTW.
Context:
> Marmite is a sticky, dark brown paste with a distinctive, salty, powerful flavour and heady aroma. This distinctive taste is represented in the marketing slogan: "Love it or hate it." Such is its prominence in British popular culture that Marmite is often used as a metaphor for something that is an acquired taste or polarises opinion.
https://en.m.wikipedia.org/wiki/Marmite
If you hate Marmite, try putting it on cheddar
People hates it because everyone tries to use as ot was Nutella. Used in the right way, butter + marmite on a toast is awesome.
I have to google the definition of the marmite word in English because in my first language it means something like cauldron or pot.
Definitely a faux-ami.
It comes in a little black (glass) pot - maybe that's where the name comes from
I also use it in cooking, add a spoonful to a soup or a stew and it really adds some great umami flavor. Marmite roasted potatoes are delicious, too.
Nice tool. But marmite is a trademark, you may need to change it if Marmite claims infringement.
Aren't trademarks attached to specific goods and services? In other words the trademark protecting the yeasty food spread based does not prevent someone from using the word for something like a record label: https://www.marmiterec.com or a static site generator.
That's right, but beware the relatively recent* legal innovation of trademark dilution: https://www.inta.org/fact-sheets/trademark-dilution-intended.... This muddies the water.
*The US federal version of dilution law came into effect in the 1990s.
You will find out in court
Unless OP branches out into developing tasty spreads I don’t think there can be a trademark dispute
Tasty marmite would be a distinct product space free of trademark.
'Marmite' has been a word in the French dictionary for centuries though (French word for 'pot').