Using Julia to Build an Email Client

I’ve finished translating a few old projects from uni into Julia, among a few other languages, and am wanting to try my hand at something a little more ambitious in my learning endeavors.

Would Julia be well-suited for an email client? Is there a library available for sending and receiving messages? If not, then I wouldn’t mind trying my hand at developing one. Is there anything I should keep in mind if I go through with this?

1 Like

Not really, in the sense that this is not where the comparative advantages of the language are.

You can of course do it, but it will be a lot of hard work that makes little sense (other than the potential enjoyment derived from it).

Doing something related to scientific computing or data analysis will be much more rewarding in Julia.

To offer a slightly more positive angle, I think it’s great for you to give this a shot. It’s true that Julia is often used for technical computing and data science but it very much is a general-purpose programming language. Have a browse through Github and you will see that people have used Julia to develop database engines, GUI applications, and web servers.

In terms of building blocks, most of the things that you will need, e.g. SMTP client, bindings to Gtk, Electron, Qt (and more) are already here. The developers of these projects would love it if someone like yourself could use them and report bugs or contribute fixes.

Good luck and please keep us posted if you decide to go ahead with this project.


I’d be happy to help with any of the low-level details, like email parsing, network protocol implementations, etc. I started on an EmailUtils package but didn’t get too far because I didn’t have a huge use for it:

1 Like

Also, to actually answer your original question: Yes, Julia is well-suited to developing an email client IMO, with strengths and weaknesses in various areas:


  • The underlying libuv/Task runtime makes writing asynchronous network code trivial, and allows the UI to stay responsive even while doing expensive transfers over the network. This is further compounded by the new PARTR multithreading capabilities, if you choose to use them.
  • Julia’s excellent compiler means that computations like UI updates and email parsing can be fast without too much effort.


  • JIT latency will be an issue for client start-up, unless you work around this with PackageCompiler or something similar.
  • Julia uses a lot of memory just to do nothing (~160MB of overhead for a REPL), so unless you have other sources of egregious memory usage like Electron, users will probably notice.
  • Not much of a pre-existing email ecosystem, so you’ll need to build plenty of things from scratch (or bind to existing libraries).


  • Many UI packages as mentioned by @hessammehr, however each are at varying levels of maturity and feature completeness, and each with their own share of bugs.

Now, if I might ask you a question: what sort of email client do you want to build? Do you want a graphical client, and if so, should it be webmail-based or desktop software? Or do you want to build a text-based terminal client? Do you want to support HTML presentation/composition, or just plain text? What “backends” do you want to support (e.g. Maildir, IMAP, POP)?

1 Like

If you really want to do it, go ahead. The only limit to Julia being able to do something like this is dedicated man power to accomplishing it. I actually think that we need more non data scientists to take Julia seriously so we can get a better idea of how to improve some of the rough edges in the Julia ecosystem.



I figured this would be the case. Thank you. I was hoping that I could somehow adapt Julia’s computing power to executing encryption, parsing, and sorting algorithms.

@hessammehr These gits were a godsend, thank you! I will see what I’m capable of and will definitely keep you all updated on the progress if I do!

@jpsamaroo The help offer is greatly appreciated! :smiley: Once I’ve done my due diligence I will definitely reach out to where you can freely contribute as you please.

Like you mentioned, the overheads are definitely an issue that made me. I was hoping to build something light but powerful for its size, and I can imagine that these overheads will be unattractive beyond the test room.

Hmm, well ideally I’d like explore popular protocols like IMAP, SMTP, and OpenPGP. Being able to download mail would be pretty neat too, so I will also look into supporting POP3. Just text for now, but I want see if I can tailor html embellishments to strong typography design. Web-based for now, but then I will see if I can develop a desktop client that supports synchronization, POP3, and offline use. If all of this goes well, I want to explore supporting other features as well like message deferrals (Gmail’s snooze feature), delayed sending, shared aliases, file conversion, file preview, automated bundling, and so forth. It’s all up in the air really. It would be neat to incorporate some visualization tools as well, but I will have to look more into this to make sure I don’t end up setting my machine on fire :smiley:.

1 Like

What I would love to see from a next generation email app is the integrated encryption that just works. I mean that someone would fix the broken email security once and all, in the way that everyone thinks later on why didn’t I think of that. Sorry I don’t have any solution to offer just a wishful thinking that some day 99% of emails would be encrypted.

1 Like