Honest question: why should I care it’s written in Rust? I keep seeing these posts of new software and the authors highlight its “written in Rust.” I’ve never before seen such an emphasis on the language rather than the features it offers.
I care that it isn’t written in C/C++. Memory safety catches a lot of security bugs. And language communities have different cultures, so knowing the actual language can be a signal as well.
Okay, but in that case, it would be cool if the submission at least highlighted some of the neat use cases for which the language is relevant. E.g. if the description would at least mention an example – a particular module that’s very easy to get wrong in C, but Rust is particularly suited to, the way e.g. Julia is so well-suited for writing a FEM program. Or a “this module would’ve been 600 lines of inscrutable C but look how neat it is when you have explicit lifetime management features baked in the language”.
If there’s none of that, but it’s just a very good program, that’s great (even better, in fact) – but at least let’s talk about that. Is it remarkably fast, in which case can we have some benchmarks? Is it super secure, as in, has anyone tried to do even an informal review, it’s cool that it’s written in Rust but what I’d really like to know is if someone checked it to make sure that attempting to view an attachment called /dev/null; rm -rf ~ won’t nuke my home folder, which is a far more straightforward exploit than anything involving memory safety.
/dev/null; rm -rf ~
Better – hell, best yet – if it’s none of that, and the author just wrote a cool program and wants to share it with everyone else and wants some feedback. Great, but can we at least get that? Hey, fellow lobsters, here’s a thing I made, it’s super early, it won’t be big and professional like Outlook, do you like it? Would you like to send in a patch? What do you think about X?
Otherwise it’s just another program written in Rust. I get it’s cool but hundreds of programs get written in Rust every day.
As far as security bugs are concerned, if being written is C would be a red flag, what colour would you say is best ascribed to the flag raised by a tool whose installation script – which you’re supposed to curl straight into bash, of course – downloads an unsigned archive and `sudo mv’s the stuff in it into $PATH ;-)?
I believe 4 out of these 5 would’ve been unlikely if mutt and libraries were written in rust, for example:
Any GC language is memory-safe.
Apart from the fact that garbage collection brings its own issues (although probably none that would affect a mail client), Rust offers much more than just memory safety.
Which is why written in Go is also a popular thing, and deserves to be. People want single binaries and fast, safe programs but for whatever reason they also want to pretend there’s no reason to care what language something is written in.
What is the most likely security attack surface for a email client?
Untrusted input: message body, attachments, headers; protocol implementation (tls negotiation, authentication)? [ed: and in particular string handling and path handling]
This is a great argument for making MUAs just deal with MH/Maildirs and leaving the server interface to existing programs (mbsync, msmtp).
Not only do you sidestep a good chunk of problems you mentioned - no worries about protocols, network, etc - you also are likely to fit into existing workflows. And it engenders trust: honestly, I’m unwilling to try software that speaks to my mail server. I risk anything from a bug inconveniencing me to something more malicious. Keep it local and I’m not as worried.
HTML & images mostly
If you want to support it, html display.
I really have trouble understanding why people ask this. What’s so hard to understand about folks caring about which language a program is written in? There are literally oodles of reasons why it might be relevant. For example, if the title of the post were, “email client written in Zig,” it would actually attract my interest more than the current title. I would probably wind up spending some time reviewing the source code too. But if the title left that out, I probably would have skipped right by it.
I think “written in [L]” makes sense, if the fact that it was written in a language is interesting. If a more complex program is written in APL, it is interesting because APL is know to be diffucult. If something is written in C89 is is interesting because that will probably make it very portable. If something is written in Zig, it might be interesting because a lot of people are not familiar with it’s strengths and weaknesses in real world systems. If something is written in Go, it might be interesting because it provides a easy static binary that can be installed without a big fuss.
Most of the time, I’m not surprised about Rust because why shouldn’t you be able to write a CLI tool in Rust? It has been done over and over again. If writing something in Rust has practical advantanges (”… written in Rust making it 4x faster”, “… written in Rust avoiding 90% of all security issues”, …) then it might be interesting.
One aspect of that is that what is “interesting” varies from person to person and from time to time. Just as an example, I know I would be more interested if the title were “written in Zig,” but I’m sure there are plenty of others that would be less interested because of it. And that actually makes the “written in Zig” part of the title useful. Because it lets people filter a bit more, even if it means it’s less interesting.
More to the point, “interest” is just one reason why “written in [L]” makes sense. It’s not the only reason. As others have mentioned, some programming languages tend to be associated with certain properties of programs. Whether that’s culture, barriers to contribution (for some definition of “barrier”), performance, UX and so on. Everyone here knows that “email client written in C” and “email client written in Rust” likely has some signal and would mean different things to different people.
I truly don’t understand why people are continually mystified by this. It’s like the most mundane thing in the world to me. Programmers are interested in programming languages and how tools are built. Who woulda thunk it.
To be clear, this doesn’t mean everyone has to be interested in the underlying technology 100% of the time either. So I’m under no illusions about that. Most of the users of my software, for example, not only don’t care what language it was written in, but probably don’t even know. I’d even bet that most of my users (via VS Code) not only don’t know what language their “find in files” is written in, but probably haven’t even heard of Rust.
But we’re on a tech forum. It self selects for nerds like us that like to talk shop. What a surprise that we would be interested in the tools used to build shit.
Apologies for the minor rant. This is just one of those things that pops up over and over on these forums. People are continually surprised that “written in [L]” matters to some people, and I guess I’m just continually surprised that they’re continually surprised. ¯\_(ツ)_/¯
Yeah, I agree that the underlying tech can be interesting and makes sense in some cases to be in the title. We’re all hackers lobsters here, right?
I’m a little surprised you’d show so much interest in Zig. I think of you as one of the “gods of rust”. Are you interested in a “keeping tabs on the competition” sort of way? Or is there some use case that you think Zig might shine more than rust for? In other words: are you interested in ideas you can bring to rust, or because you’re evaluating or interested in using Zig in its own right?
No, I’m legitimately interested in Zig. I’ve always loved the “simplicity” of C, for example, for some definition of simplicity. (That one can cut a lot of different ways.) It’s also why I really like Go. And I think Zig is taking an interesting approach to memory safety and I’m very interested to see how well it work in practice. I’m also quite interested to see how well comptime does and how it balances against readability and documentation in particular.
But I haven’t written a single line of Zig yet. I’m just following it with interest. I’m also a Zig sponsor if only for the amazing work that Andrew is doing with C tooling.
Personally I care because I am trying to learn Rust and projects like this are nice to explore and figure out stuff.
I’m not sure either. I do occasionally see the “written in Go” or “written in Crystal” or “written in pure C99”, however.
This was a trend 5 years ago with Python I feel, now it’s a trend with Rust. In case of Python, in my experience, it boiled down to “we improved the UI massively (compared to existing alternatives) and our error handling is nonexistent”, while with Rust it’s more likely to be “we’re obsessed about efficiency and everything else is secondary” ;)
In practice, the “in X” is likely a call for contributors, not the users – as a user, when I see “it’s written in X” I assume that it’s probably got no real upsides aside of that, as if writing it in X was the whole point.
As an email client for users, it isn’t interesting at all (no disrespect to the creator). But, as an expression for the possibilities of an up-and-coming language, it is useful. This post has the same similar feel to a “hello world” for a new language.
It makes it interesting to me because I’m interested in Rust, so I’d like to check out the source and learn something!
People still writing new software in C in TYOOL 2021 also like to brag online about their choice of language. I don’t get it.
I first thought “written in Rust” seems boisterous, then rethought and realized it’s beneficial specifying such, not just in boistering, but as an example for folks wanting to learn.
Well,one reason to care is to make sure they don’t fall victim to the RIIR question from the Rust Evangelism Strike Force. (Have you considered rewriting it in rust?) (https://transitiontech.ca/random/RIIR).
(Note: this is a joke. You probably don’t care about rust and nor should you, but the author does.)
This reminds me of meli (https://meli.delivery/), but the idea is to provide tools to build various UIs. Kind of like git porcelain for email. Cool project. :)
I’m excited to try meli, I’m interested in its JMAP support among other things.
I hope that it remains under active development, with a lot of these little tools I fear their lone developer running out of time and I worry about making them an important part of my workflow.
I’m the lone meli dev, I’ve stopped my activity merely because it was the only thing I had to do every day under quarantine lockdown and I kind got sick of it. I haven’t given up on it though and it’s not dead.
It looks like it hasn’t received much attention in the last year or so, by looking at the mailing lists.
If you look at the source repo, there’s a bit more activity. Also the author commented above you that it’s not dead :)
I never tried submitting a story on lobster.rs – maybe I’m missing something from that page and this isn’t straightforward, and my mind is stuck in the era of phpBB boards. Maybe this is more of a meta thing, too, I’m not sure what to think of it.
I think it would be great if we could see more stories about things people here write. Over time, via IRC or PMs, I’ve learned of a bunch of cool stuff that people here do and, anecdotally, I think less than 10% of them ended up being posted here. That’s just not right, it should be the other way ’round.
On the other hand I’d love to see some substance to these things. Not an elevator pitch or some other Y Combinator bullshit. Just, you know, be friendly/nice. Even when there’s nothing specifically interesting about it, like, you had a lazy afternoon and cobbled together a program that draws the Mandelbrot set. Could you at least say hi, I wrote this little Mandelbrot hack, do you like it? Anyone else tried something like this in Rust? Has anyone tried to draw it using thislib instead of thatlib?
There’s a lot of potentially cool stuff here. In my other comment here I alluded to command injection vulns specifically because mutt was ridden with that way back, and a big part of the reason why that happened is that string processing in C is a dumpster fire. So this doesn’t have to devolve into a CVE-counting exercise, there’s more to Rust than refusing to compile things that would result in a segmentation fault.
I mean, in case you specifically want to get hung up over this being written in Rust. There are other cool things about it, too, like the overall CLI interaction model.
So there’s a bunch of cool stuff to talk about here but just throwing a link over the fence doesn’t invite that kind of talk.
There’s what are you doing this week if you’re interested. There’s a weekend edition, as well. And in this particular submission’s case, it was posted by the author.
We have a “show” tag for that and yes I agree it’s lovely to see people using it. <3
The vim integration off the bat looks great! Very compelling feature, thanks for sharing. :)
Cool. A bit like the old MH mail client system.