I've spent the last two years building a new email client - muszc-master https://ivelope.com/invite/InviteHNv0914 <comment><AUTHOR> I put my name on the waitlist, but instantly lost interest and confidence by: "Jump forward 5 steps in the line for every person you invite and get beta access sooner."

Why? If the product is that good I'll evangelize it. This is a desktop application, so I don't see a big boost from a network effect. All this does makes me wonder if the product is more about building hype than value

<comment><USER2> You are not alone in this attitude, so don't take this personally, but I'm going to reply to you because you're the top comment. This is an incredibly destructive point of view. Promotion is essential to any software project, even open source, and in the vast majority of cases, word of mouth is not enough. This is an ethical, up-front, straightforward ask that costs you and anyone you might contact very little and is optional in any case. He's a solo developer. Cut him some slack.

<comment><USER3> But what am I endorsing? I haven't tried the product myself yet. It's not unethical, but it's also simply not something I'm prepared to do - I will not recommend something to anyone without having been able to evaluate it myself first.

<comment><USER4> This.

In a world where publishing is essentially free, reputation is an extremely valuable commodity. The ask here is not trivial.

<comment><USER5> Yes, it is trivial. You have a warped perspective of importance if you think giving the nod to a new mail app is some holy thing.

I tell my friends about new apps, startups, and projects all the time. None of them think I'm staking my reputation when I shitpost about some new thing in Slack.

<comment><USER6> Recommending a product you haven't reviewed is a form of lying. Some of us value our integrity.

<comment><USER7> Isn't this true of all advertising, except in the rare cases where the publisher only accepts ads for products they endorsed?

How can we ever expect a reliable, non-garbage-dominate internet when it is funded by perverse incentives?

<comment><USER8> The distinction is that if I see a billboard (or magazine ad, or TV commercial) advertising a product I don't think that I have a relationship with the billboard and they know me pretty well and have my best interests at heart... so I don't think that if this particular billboard that knows me so well is promoting a product to me then it must be a pretty good product for me (especially because this billboard doesn't usually go out of their way to recommend products to me).

But if a friend of mine recommends a product to me, well, I do think all of those things.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> I find it crazy that everyone is harping on Electron instead of the cool features that this clearly has that most clients do not. Demo looked pretty polished dude. Don't let the typical HN crowd rain on your parade. The fact that you posted an actual product out to the public is more than most can say.

Also: If you can't spare Max 300MB ram and you are complaining on HN wtf computer do you use?

<comment><USER10> My compute resources are not an all-you-can-eat buffet. I'm sick of inconsiderate developers writing software in wasteful frameworks that waste my electricity and time.

You can make pretty x-platform apps in JavaFX, QT Quick, GTK, hell even Lazarus, and they don't eat CPU and memory like Electron does.

It is a shame that nearly every app released in the latter half of this decade is just wasteful Electron garbage. Don't forget your 300+mb needs to sit along side Slack's 300mb, Discord's 300mb, and so on... fuck even my Crashplan Backup client eats up three processes and another 300mb. It's inconsiderate as hell.

<comment><USER11> I'm not grandparent but I tend to agree that it's NoBigDeal(TM). I'm no electron apologist but I don't understand why using electron is considered "inconsiderate". It seems like the developer(s) used the platform that they felt was best for this app. If the platform's issues overshadow the product's value, then that's a poor choice and the market will react by not using it.

Is it inconsiderate for Ford to make a larger SUV because your garage doesn't have unlimited square footage and you only want to buy so much gas? Of course not. Why is this any different? You can decide not to buy the SUV just like you can decide not to download this application.

<comment><USER12> > I don't understand why using electron is considered "inconsiderate".

Because I chose my OS carefully and found that I like the way its native controls work. It has a number of features missing from other OSes and I want to use apps that integrate naturally with it. I have yet to find an electron app (or web app) that is 1/10th as good as a native app at fulfilling that desire. Electron apps feel like generic imitations of native apps. Yeah, they work, but everything is just off. Also, it comes from Google so I can only assume it's doing some sort of tracking of me and/or my machine resources. No thank you.

> Is it inconsiderate for Ford to make a larger SUV

It depends on which dimension they extend it and by how much. If they make it wider to where it doesn't fit in a lane on a normal road, then hell yes it's inconsiderate. That's essentially what electron does.

<comment><USER13> I'm an developer who's been using electron since it came out. At it's core electron is just a packaged NodeJS instance with a layer to access the OS API. The chrome as a GUI part does not have to be used. This makes electron a great way to distribute NodeJS apps. Instead of getting your users to install NodeJS and use the command line, you can give them an electron version of the app that works out of the box.

If you stick to using the GUI part minimally, it's easy to build very light weight applications with electron. I've been building my own music streaming server with electron and its gotten some traction since it's easier to install. The GUI layer is only used for editing config options, so the app typically runs with under 50mb of memory consumption: [https://github.com/IrosTheBeggar/mStream/releases](https://github.com/IrosTheBeggar/mStream/releases)

If used smartly, electron is a powerful tool for developing desktop apps quickly. However thanks to modern frontend dev practices, it's easy to build a bloated pile of crap.

</comment></comment></comment></comment></comment><comment><USER14> I don't think this puts enough emphasis on the fact that it is a local client and not a web service. I see some people here griping about Electron, but the privacy implications of being a local app are way more important than the performance of the framework used.

<comment><USER15> My partner actually has the opposite pain-point:

She wants an e-mail client that stores attachments remotely, only downloading them as requested by by the client. Is there an e-mail service that does things this way?

<comment><USER16> Apple Mail has this as a setting, works with any IMAP provider.

</comment></comment></comment><comment><USER17> Thanks for your interest in local email clients, more choice there is welcome!

In the description it is said one can file email with a key, by associating folders to keys. Keyboard operation is very important to me. However direct key/folder association doesn't scale to a large number of folders. Have you considered a feature like the "Nostalgy" extension for Thunderbird? [1]

With Nostalgy one type "s" to file/save an email, then a string which is matched to folder names. It's a bit like helm for emacs (except it's exact match, space is not interpreted as an "AND" like with helm). The commands are go/save/copy, and then string match. This scales very well. That could be an advanced feature, as for beginners the direct key/folder association is simpler. But I guess you will target advanced users too, and for them it may be an important feature.

[1] [https://addons.mozilla.org/en- US/thunderbird/addon/nostalgy/](https://addons.mozilla.org/en- US/thunderbird/addon/nostalgy/)

<comment><USER18> Claws mail had this by default. Thunderbird fortunately via the Nostalgy extension. It's been a lifesaver since claws mail never implemented HTML mail, forcing me to move to Thunderbird for 21st century text formatting ten years ago.

</comment></comment><comment><USER19> This looks pretty cool, I'm really pleased to see people writing new email clients, and you've clearly worked very hard on this!

I have a bunch of questions that I couldn't find out from the website (but are obscure enough that I shouldn't expect to):

* Is this a purely native app, or an Electron / Javascript app? Personally I'm only interested in native apps & Electron would be a deal breaker - but I'm weird, most people won't care.

* What format are you using for email archives? Mbox, Maildir? Can I import my Thunderbird / Postbox Mbox archives of 21 years of email?

* Can I turn off threaded & conversation views?

* Do you support POP3? (You only mention IMAP... I'm sure that would be fine, but I still have accounts configured via POP3.)

* Can I change priority of individual messages after they arrive? I sort my inbox by priority and then date-descending, not by date.

I'm a hardcore Postbox user and email is critical infrastructure for me, so I probably won't try it or switch anytime soon... but I'm always keeping an eye on powerful desktop email clients, in case I ever need to switch, or find something dependable that really blows away Postbox.

Well done! Looks very promising!

<comment> muszc-master 1\. It's an Electron app, but it is built to use as little RAM as possible, when I run it on my old Macbook Air, it consumes only around 300mb of RAM maximum, which is less than what Finder consumes, and I consider everything over this limit to be a bug.

2\. Currently not supporting Mbox/Maildir but downloading emails directly from the server, however an import of this is on the todo list

3\. Re: turn off conversation view: not at this time. Do you prefer not having it in a conversation view?

4\. No POP3 yet

5\. I think you can achieve this using folders/labels in Ivelope

Thanks for the positive encouragement!

Edit: formatting

<comment><USER20> 300MB of ram sounds like a lot to me. What are you storing in memory that is that large? If I dont use the app for 1 hour will it stop using the memory?

<comment><USER21> I'm sure that a client like Mutt would use much less but considering that many emails have embed HTML and would ideally use a modern web view to render correctly, how much overhead is there from from using Electron/chromium if you're going to load all of that anyway?

I couldn't find exact figures for MS Outlook but Office 365 seems to require 1Gb as a minimum.

A quick look at the Gmail tab I have open in Chrome seems to be taking roughly 390Mb so this would seem to be an improvement over that.

As a genuine question, what sort of size would you expect for an optimised native app with the same functionality?

<comment><USER22> For reference, when settled, Gmail in Firefox uses 200MB or a bit more, while FastMail uses around 10MB.

I'm tempted to make a FastMail Electron app just to demonstrate that Electron/HTML/CSS/JS doesn't _need_ to mean slow and heavy (it just normally does).

 _Later:_ OK, so on Windows a trivial Electron "just load [https://www.fastmail.com/login](https://www.fastmail.com/login) (and then log in)" app uses ~230MB of RAM. Not what I was hoping for, though it doesn't surprise me a great deal—Chrome is quite happy to use lots of memory. Interestingly, when I reduce it from 3000×2000 to 1600×1200 (device pixels, it's a 2× display), it goes down to about 160MB after a bit, and minimised to 180MB or 120MB for the two window sizes. Still very snappy despite this memory usage, though, for FastMail is fast.

<comment><USER23> > Gmail in Firefox uses 200MB or a bit more, while FastMail uses around 10MB.

Yes, but that's not a fair apples to apples comparison with his 300mb number. Your looking at the memory used for that tab, not the shared memory used by the browser across tabs. Open Firefox with no sites open and check your baseline memory usage. Add that to the numbers above for a direct comparison.

<comment><USER22> I sought only to compare Gmail with FastMail, to indicate that Gmail is a poor baseline for memory comparisons.

<comment><USER23> Fair point, I agree there!

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER24> Of course I have to ask if you've looked at JMAP ([http://jmap.io/spec.html](http://jmap.io/spec.html)).

More because we're getting close to finishing the spec, and feedback from someone who's build a client recently about whether the spec suits their needs would be valuable!

<comment> muszc-master Hi! I really like the initiative of JMAP, however I haven't been able to look into it properly - I can give you a better answer once I've done that, my email is in my profile

<comment><USER22> One of the things we're really hoping with JMAP is that, by drastically lowering the barrier of entry (because doing IMAP/POP3/SMTP well is _hard_ ), people will be able to experiment much more, making things like Ivelope, because they can start making UI almost immediately rather than shaving IMAP yaks first.

I have a talk planned entitled "building a fair dinkum email client in half an hour with JMAP"—because you genuinely can make a basic but useful email client that quickly! (I'm planning to submit it for Strange Loop. Any know of other conferences that would like such content?)

JMAP's support for both labels and folders may be helpful for Ivelope too.

I love seeing a new approach to an email UI, based on the same old email that still works. Thanks for making it!

<comment> mike-cardwell I'm not convinced that JMAP existing will make it easier for people to develop things like Ivelope. I don't know in this particular case, but if I were writing Ivelope I wouldn't first write an IMAP library of my own. I'd use an existing one. And all commonly used languages have pre-existing IMAP libraries anyway.

I doubt the ability to do "var client = new JMAP()" instead of "var client = new IMAP()" will lead to a flood of new clients.

<comment><USER22> I perceive that you haven't ever tried programming against IMAP or making a MUA, or not seriously at least.

IMAP is a mess if you try to do much beyond the basic "retrieve list of folders, retrieve messages, now just leave it alone"; and most IMAP client libraries are worse than IMAP need be. There are many extensions for many features, poorly supported in various clients and servers, and various things that are slow, difficult, or impossible to do in IMAP that JMAP can express elegantly. [http://jmap.io/#why-is-jmap-better-than-imap](http://jmap.io/#why- is-jmap-better-than-imap) lists a few reasons. Bugs in clients or servers that cause data loss over IMAP are not unheard of.

IMAP is also only one part of the app: one of the hardest parts is MIME, and figuring out what to show for an email and how to craft an email; there are fewer libraries to do _this_ than there are IMAP clients—and almost none that are any good. (You'll find some that do the plain _parsing_ of most of the message, but how do I decide what to do with multipart/alternative, multipart/mixed, text/plain, Content-Disposition, Content-Encoding, &c. is answered by no library that I know of.) JMAP doesn't solve all these problems, but it handles most of them by handing you a sanely parsed message (putting the burden of sanity on the server, and the spec provides good guidance and there's a JMAP test suite being made to ensure the sanity of the server): things like exposing To, Cc, _& c._ as lists of addresses; and fields like preview, htmlBody, textBody and attachedFiles to save you the trouble of deriving the crazy convoluted rules of multipart messages. You can send messages without having to implement SMTP and grok MIME, too.

For authors of existing MUAs, JMAP doesn't have much to offer by this stuff from the last paragraph—they've already done the hard slog. But for authors of new MUAs and other programs that might want to do email at all—sending or receiving—JMAP really _is_ "all that".

Some of the experiments that I'm looking forward to seeing won't look like existing MUAs at all. They'll be other things altogether that just happen be able to send or receive emails directly, now, because it's finally easy enough to.

IMAP is not particularly well suited to being used as a purely-online client with no local storage or persistent cache. You can do it, and many clients have over the years, but you will sacrifice a lot, like the ability to search multiple folders efficiently. We couldn't make something like the FastMail web UI speaking IMAP; it just wouldn't work in too many places. JMAP, on the other hand, is _designed_ to work in such a situation, and suffers from few of those sorts of shortcomings. Sure, you'll probably want to introduce offline support and may want to reimplement search on the client somewhere down the track, but it's not necessary-work-that-must-be-done-before-the-client-is-generally- useful like it is in IMAP.

JMAP allows you to get started quickly and efficiently. Because it speaks HTTP and JSON and is deliberately designed as a synchronisation protocol, and because it lacks the cruft of decades of fragmented extension that IMAP has¹, JMAP is really _easy_ to work with. Even things like synchronisation and notifications come at very low cost even _without_ a library, especially if you are running in a web browser.

Don't forget that JMAP replaces IMAP _and SMTP_ for the MUA. And having only one thing to configure and get right, with a standard configuration procedure (SRV and .well-known, so that you can just provide an email address and it'll figure out the rest) instead of two with no consistently applied configuration procedure is a surprisingly big deal for users.

The talk that I plan will be predominantly live coding, starting from scratch—no frameworks at all—and building a basic but functional MUA in half an hour. You _really_ can't do that in IMAP/SMTP, but you can in JMAP², and it genuinely gets better beyond there.

I have no interest in making a realistic MUA with IMAP/SMTP, because I _know_ that I would spend _weeks_ on the groundwork, to produce a result that is strictly inferior to what I am confident I can produce in an hour with only a general understanding of the JMAP spec, and access to the JMAP core and mail spec docs.

Oh yeah, I just remembered another absolutely _massive_ thing about JMAP, though the dust has not yet fully settled—calendars and contacts. Because this IMAP/SMTP MUA estimate of mine just went up by a couple of months to handle them for _some_ ESPs, whereas with JMAP that groundwork will take maybe another whole hour.

Seriously, JMAP is a _big deal_.

\---

¹ For now, and it has a more thoughtful design to future extension so that it will avoid some of the troubles of aging.

² I'm delicately ignoring the matter of authentication here, which is omitted from the JMAP spec, and assuming something really basic.

<comment> mike-cardwell "I perceive that you haven't ever tried programming against IMAP or making a MUA, or not seriously at least."

Unfortunately for you, your perception is wrong. Writing an IMAP client library is my go-to project when I'm learning a new network stack / language. I am very familiar with the way it works and it's various problems, and have been paid to write software that uses it.

I am not as familiar with JMAP, but I _did_ look into it a year or so ago. I recall at the time that it didn't seem to solve that many problems, and introduced problems that I never previously had when working with IMAP. I triggered a discussion on the IETF mailing list regarding one of these problems ([https://mailarchive.ietf.org/arch/msg/jmap/7dSQsqRBJ_YlZ7wF8...](https://mailarchive.ietf.org/arch/msg/jmap/7dSQsqRBJ_YlZ7wF83i2ihi14XI)). Somebody said at the time that they would look into modifying the protocol to address that problem, but to me (and I could be wrong) it looks like this hasn't happened.

My basic perspective on JMAP is: It doesn't fix enough problems to justify the massive increase in pain it would cause developers of mail clients by having to support both IMAP and JMAP at the same time. I'm totally on-board with replacing IMAP with something better. But it needs to be a _lot_ better, or we should just stick with IMAP. To me, JMAP just looks like it will cause more problems than it solves.

<comment><USER24> \-- get the second page of top-level folders

["Mailbox/query", { "filter" : { "parentId" : null }, "limit" : 30, "position" : 30 }, "R1"]

It's happened.

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> God bless you for working in a space—native email clients—which seems utterly neglected nowadays.

<comment><USER26> I can kind of see why.

There is a lot of convenience in being able to log into any computer and access your mail. Plus Gmail search beats the search in native clients most of the time.

<comment><USER27> Gmail search is without doubt the worst search I've ever come across. It doesn't even return all the results.

Why do you think it is good?

There is nothing that says that you can't have both web and native mail clients.

<comment><USER26> It works for almost everything I try to find. It might take a few tries, but I can usually find the mail I was looking for.

Usually when I change jobs I have had another non Gmail account but I have never found the search as good. I have an outlook web client at work and that doesn't find things. Maybe its me being dumb and remembering different phrases from what is actually stored, but I almost always manage to finds what i am looking for in Gmail. I can't say the same with other clients.

Its just a pity that I have to give up my privacy to Google for it.

<comment><USER27> Well, it can't even find all instances of a single exact ID.

It's what you'd expect of a cloud service though, they really don't want to go through all of that data.

Any native client though will just go at it and return proper results.

</comment></comment></comment></comment></comment><comment><USER28> Looks great! I'm always curious what it means when people say they've worked x years on something. Was this a full time project @ 40/h a week every week, or more of a few hours on the weekends, or maybe something in the middle?

<comment> muszc-master Hello! It has been full-time for the last 2 years!

<comment><USER29> This probably means that the software is not going to be free, right?

<comment><USER30> I hope it's paid. This guy deserves to get paid for his awesome work, and I will trust it more if I'm paying $.

<comment><USER31> I agree! I'm frequently paying for software even if I won't use it after a year just to test how well it works. Unpaid is not sustainable. But having source code (Maybe GPL?) is also important.

</comment></comment></comment></comment></comment><comment><USER32> No offense but unless it's a 1st party client email clients are something that is very hard to trust.

Who controls your client has access to your inbox with most services even the few that have separate IMAP/POP3 passwords like Hushmail can be compromised through it.

If your client also integrates with encryption or worse takes charge of it my encryption key is also now at risk.

Lastly since email today is pure HTML you also inherit all the possible vulnerabilities that come with having a DOM parser and a layout engine and even modem browsers still get both wrong.

And using something like Electron or even Chromium won't implicitly save you because the way you implement them matters a lot and now you are tied with their update cycle which might break functionality forcing you to manually backport security fixes which is hard to accomplish.

So unless you have the source or show an audit from a respected firm (c53, isec etc.) its going to be quite hard to recommend to anyone to take the dive and try this out.

<comment><USER33> I've downvoted you for your sheer negativity.

This is a person who's worked 2 years on a project, in a neglected space where companies don't go because they can't make money.

He deserves praise for taking the time, creating something that's different, and thinking through the idea. Well done!

<comment><USER34> He isn't trying to take away from the achievement, just highlighting some legitimate security concerns.

IMHO this is justified since people often overlook how critical an attack vector this would be.

Imagine if a state-sponsored "hobbyist" posted a pet project like the OP to Reddit and started harvesting keys/password reset capabilities for huge amounts of users.

Hell, people flocked to use unroll.me and then it turned out they were (predictably) scraping your entire inbox and selling the data to advertisers.

I don't believe that worrying somebody's skepticism might hurt feelings is a legitimate reason to downvote (remember, downvotes aren't about whether you agree with somebody; it's about whether they add constructively to discussion).

Aside: Great work OP. Seems like an incredibly hard sector to make traction with though, so best of luck.

<comment><USER35> Yea, I kind of feel the same way about it. "Great work but not my cup of tea for reasons A, B, and C" should be valid feedback on a Show HN.

<comment><USER33> Absolutely. But the OP forgot the "Great work but...". Had they, I wouldn't have commented.

</comment></comment></comment></comment></comment><comment><USER36> > Total privacy - we do not have access to your email account, Ivelope only > sends your email data and password between your computer and your email > server.

I wish this was the default assumption these days.

</comment><comment> mike-cardwell Has anyone tested this using [https://www.emailprivacytester.com](https://www.emailprivacytester.com) yet? If not, please do so and report back here. I would test myself but I'm stuck in the queue for access.

</comment><comment><USER37> This looks great. I have two questions:

\- Is this open-source? What is the license and where is the source-code?

\- When can we expect a linux version?

</comment><comment><USER38> Super cool!

ctrl+f on "price" or "cost" turns up nothing. Well then, what is your business model going to be?

</comment><comment><USER39> This looks very impressive. I'm currently looking for a new email app but my biggest concern with email applications is their longevity, do you have any plans for funding this? (I'm not so concerned what the model is, just that there is one.)

<comment> muszc-master Yes there is a plan, and I have on-going conversations with some interested parties :)

<comment><USER40> There is also the option of Patreon

</comment></comment></comment><comment><USER41> This looks amazing, I can't wait to try it out. My main problem with Thunderbird is that it doesn't have a conversation-based UI, but this looks like it does. Good stuff!

(By the way, typo: "accessable" should be "accessible")

<comment><USER42> There is an extension for Thunderbird called Thunderbird Conversations [1] for a conversation based UI that provides a look similar to Gmail (though it may not look like chat, which is possible and would look nice only for those who exchange short one or two sentence emails). As that addon says, "Don't forget to hit View > Sort By > Threaded in the menus." to use it. Perhaps this extension would help you.

[1]: [https://addons.mozilla.org/en-US/thunderbird/addon/gmail- con...](https://addons.mozilla.org/en-US/thunderbird/addon/gmail-conversation- view/)

<comment><USER43> I consistently have performance problems with that extension.

</comment></comment></comment><comment><USER44> This is awesome. And very well done. It is clear that a lot of effort and time went into building and polishing this, especially for a single person. Impressive! I signed up for the list too. Looking fwd to trying it out.

<comment> muszc-master Thank you!

</comment></comment><comment><USER45> Speaking of desktop, has anyone else seen Proton Native?

[https://news.ycombinator.com/item?id=16978901](https://news.ycombinator.com/item?id=16978901)

</comment><comment> eigen-vector The product looks great. Feed is a fantastic idea, love it. Good luck!

<comment> muszc-master Thanks for your comment :)

<comment><USER46> Are you familiar with outlook.com's sweep feature?

It's the ultimate email management tool. And I hope you can add it fast.

<comment> muszc-master I will definitely look into this!

</comment></comment></comment></comment><comment><USER47> It looks wonderful! Finally a good candidate for a successor of Thunderbird! I just hope you'll manage to finish your project.

By the way, when do you plan to release the beta?

<comment> muszc-master Thank you! Version 0.9 is out right now, and I have released it to a few people in the waiting list, I'm fixing bugs and iterating, so expect to get a download link pretty soon

</comment></comment><comment><USER48> Does this do any kind of telemetry at all? Looks nice, would be interested to take a look if/when a Linux build was available

</comment><comment><USER49> Will definitely try it out, it's really hard to find a perfect client.

I wonder when will we be ready to finally drop copying the entire fricking thread with each email, since all email clients automatically build the thread. If you need to forward it to someone, it'd be easier to replicate that functionality on the client side.

<comment> muszc-master Thank you! This is one of the problems I'm trying to solve - although not fully implemented yet in the beta

</comment></comment><comment><USER50> Whats the business model around this or funding plans? Freemuim, paid software, ads, selling data?

How sustainable is this project?

</comment><comment><USER51> What would be the reason to limit access to the beta with a waiting queue? I can see reasons to use this approach for a web app, for which you have to ensure that it scales with the number of users. There is no such problem for a standalone desktop app, though.

<comment> muszc-master You are right in this respect, the reason for limiting access right now is that I don't want hundreds of people to experience and report the same bug, if I let a few users at a time try it, I can fix the bugs they report so the users in the next batch won't experience these bugs.

</comment></comment><comment><USER52> It looks really great!

Which frameworks/libraries and languages did you use?

What were the main challenges you came across?

<comment> muszc-master Thank you! This is built using Electron, so it is basically JavaScript. Given the interest of this post I'll try to make a blog post later on all the challenges and lessons learned

</comment></comment><comment><USER53> Wow, people really feel personally attacked by an app released using Electron. Weird.

</comment><comment><USER54> It's funny how everyone has a extremely specific set of requirements, most of time for technical reasons. Does say something about e-mail in 2018 I guess.

</comment><comment><USER55> What is the reason to build it as a native software instead of a webapp? Seems like a lot of email clients are now webapps and I can see the arguments why.

<comment> muszc-master Because of Privacy concerns! The thinking is that few people would enter their email and email password on a 3rd-party website, having it as a downloadable software ensures the privacy of users

<comment><USER56> Although, in reality, that doesn't make it more secure.

<comment><USER57> On a desktop app, you can see what kind of request the program makes and which servers it contacts. With a webapp, you'll never know what the app does.

<comment><USER58> You can do the same in your browser by opening the developer tools and in fact it comes built in to the browser whereas on a desktop you'd have to install another app like Wireshark/Fiddler to see those requests.

<comment><USER59> That only tells you what your browser sends to their server. It doesn't tell you what connections their server makes.

<comment><USER60> Nothing will. The vulnerability of what happens to your data after it is sent to a third party is the same for any app, web or native.

The biggest difference is that it's way easier to see where you're data is being sent in a browser, since it has built in tools. It's very hard to monitor native app traffic that is sent over SSL.

<comment><USER59> When the app is native there no requirement for a third party server.

You, Your mail (provider) server.

Vs

You, the server hosting the web app, your mail (provider) server.

</comment></comment></comment></comment></comment></comment></comment></comment><comment> mike-cardwell Does this have support for OpenPGP? If not, you might want to take a look at [https://github.com/openpgpjs/openpgpjs](https://github.com/openpgpjs/openpgpjs) which does all the heavily lifting for you. Although it would also be useful if it could talk to a locally running gpg-agent so it would work with smartcards/yubikeys etc.

<comment> muszc-master Doesn't support it as of yet, however it has been requested by many and is on my todolist.

<comment><USER31> Is there a public tracker for these requests? I'd be happy to be informed when OpenPGP support is available. Enigmail started to behave really weird since version 2 and your client looks incredible!

</comment></comment></comment><comment><USER61> I always thought it would be nice if the major os vendors provided some way of building these types of local run web app using a shared engine the os provided. Not just a web view, but a way to build the ui using web tech but also exposing the file system and other things. I guess it would be hard to secure but it's not any worse than running unsigned eclectron apps.

</comment><comment><USER62> looks nice - too bad it is not available for Linux.

<comment> muszc-master I've been getting a few requests to release it for Linux, and as the other commenter here, since it is Electron, it will not be very long before it can be released on Linux (compared to if it were a 100% native app)

</comment></comment><comment><USER63> Maybe sounds weird, but does it it support Usenet (NNTP) protocol? Or maybe make it support plugins so people can add features they want.

Thank you!

</comment><comment><USER64> Would be nice to see a feature comparison with Thunderbird. What exactly can this do that Thunderbird can't?

<comment> muszc-master To give some examples: quick-move folders, conversation view, feed view, one click filter-creation and newsletter/promo filter

<comment><USER64> Seems like a lot of these are covered by Thunderbird plug-ins with the added advantage of having a native application.

</comment></comment></comment><comment><USER65> This looks very neat! Does it have quick to use keyboard shortcuts like the Fastmail or Gmail web interfaces?

<comment> muszc-master Yes it does!

</comment></comment><comment><USER66> Looks very interesting. I personally would appreciate knowing I am entering my email into a waiting list rather than getting access. Also, why does there need to be a waiting list - to help stem the flow of analytics? Honestly curious.

I really want a good, modern email client and I hope this can be it.

<comment> muszc-master The reason for having a waiting list is so that I can release it to a few people at a time. I don't want to release it to everyone at once, because if there is a large or annoying bug I haven't found. If I release it to a few people, let's say 50, only they will experience this possible bug and not everyone at once

</comment></comment><comment><USER67> Can the filters be exported for import into gmail, etc?

I have a lot of gmail filters for auto archive or auto forwarding. I like to keep them at that level so that changing clients doesnlt mean I lose my filters. Does make it a pain to make new filters though if I'm in a 3rd party client.

</comment><comment><USER68> This is just advertising... showing a product on HN, but requiring you to "invite" others? Too bad, I was actually willing to try the software.

I'm not going to invite others if others can't use the software, or without trying it for myself first...

<comment> muszc-master I'm sorry if it came across as advertising, let me clarify: you NEVER have to invite others to get access, however if you do, you have the chance to get access sooner - I think this is fair. I definitely understand your concern of not sharing it and you do not have to share it to get access.

<comment><USER69> That sounds reasonable enough, but how fast is your queue moving? I'm 3,800 something - will I remember this show HN when I get access? :)

</comment></comment></comment><comment><USER70> Looks great. Would love to try it out when it goes out of beta.

For testning the privacy when it comes to email rendering, have you tried this excellent service?

[https://www.emailprivacytester.com](https://www.emailprivacytester.com)

<comment> muszc-master Yes I have and in the latest release which I'm working on, I've included features trying with the goal of fully complying with this tool.

</comment></comment><comment><USER71> Forgive my ignorance - can someone do a very short explanation of the killer features here?

I don't send or receive a lot of emails - none of the features jumped out at me as doing something gmail or the default mac mail app is missing and I wish it had.

</comment><comment><USER72> I've searched the page for the word "offline", was disappointed. Searched this thread for the word "electron", was disappointed again.

Then I've signed up nevertheless, because the need for a good modern email client is strong.

</comment><comment><USER73> Another browser running on my computer ? Thanks but no.

Also, what kind of software license does it use?

Is it open source?

is it free software?

Is it proprietary?

Once I sign up, how will my email address be used?

Will it be abused?

It did not ask for any permission nor I agreed to any terms. He seems to be from Sweden, doesn't he know about GDPR?

</comment><comment><USER74> This looks interesting. One can see the two years of work that went into this. Is there a way to follow the development as a bystander? Something like a newsletter, blog, twitter or any other kind of feed?

<comment> muszc-master Thank you for your feedback! If you sign up for an invite, I'll let you know once something like this is up and running.

</comment></comment><comment><USER75> I love the implementation, I can't wait to play with it, and even use it!

A question, is it a pure email client, or an email client behind a value added service (it relies on a server you run somewhere)? Thanks!

<comment> muszc-master It's a pure email client! We do not have a third party server processing your emails, your data goes only directly between your computer and your email server.

<comment><USER75> Excellent, thank you much! In queue. :-)

</comment></comment></comment><comment><USER76> This looks fantastic, I was just thinking about so many of these features being released in gmail. Like the chat bubble. Those things really speed up reading information. Kudos!!

Btw where are the electron haters?!

<comment><USER19> _> Btw where are the electron haters?!_

Hi! I'm here! ;)

I mentioned Electron in my comment, and Electron is a deal-breaker for me... _but_ I would much rather encourage the work and effort that is going into this. If the product is successful and profitable, maybe it can be ported to native frameworks a few versions later. And considering the rumours about macOS, probably wise to avoid writing native Mac code just now.

<comment><USER77> > And considering the rumours about macOS, probably wise to avoid writing > native Mac code just now.

What rumors?

<comment><USER19> Apple is dropping Intel chips & replacing them with their own CPUs in Macs in 2020 [1], and working on a unified development API where you'll develop one app for iPhone & iPad that will also run on the Mac, so you won't need to write Mac specific apps anymore [2] [3].

It's all rumour & could be wrong. But there's some who feel macOS only has a couple of years left before being discontinued. In that climate, an Electron app is smart because it will be easy to port to iOS / newOS.

[1] [https://www.bloomberg.com/news/articles/2018-04-02/apple- is-...](https://www.bloomberg.com/news/articles/2018-04-02/apple-is-said-to- plan-move-from-intel-to-own-mac-chips-from-2020)

[2] [https://www.bloomberg.com/news/articles/2017-12-20/apple- is-...](https://www.bloomberg.com/news/articles/2017-12-20/apple-is-said-to- have-plan-to-combine-iphone-ipad-and-mac-apps)

[3] [https://mjtsai.com/blog/2018/05/01/scuttlebutt-regarding- app...](https://mjtsai.com/blog/2018/05/01/scuttlebutt-regarding-apples-cross- platform-ui-project/)

<comment><USER78> I wish them luck, but Microsoft tried this already (Universal Windows Platform).

One thing I fear is that keyboard shortcuts, particular the F-keys, will become a thing of the past.

</comment></comment></comment></comment></comment><comment><USER79> Quite a challenge you chose for yourself, I respect that! There are very, very few _passable_ email clients in this world: Thunderbird, Mail.app (macOS and iOS) and GMail Web client.

<comment> muszc-master Indeed it was and is. My goal is to put Ivelope on that list

</comment></comment><comment><USER80> Nice! This has a ton of potential and I really like the way that you've approached things here.

Does the calendar sync up to the various calendar providers (Google, Apple, etc) as well?

<comment> muszc-master It will very soon, that's one of the most requested features by my current beta users

</comment></comment><comment><USER81> Love the work you put into this and the detail put into describing the features. One thing missing from the site. Why did you make it?

<comment> muszc-master I felt that email clients hasn't changed much in the last 20 years and that there is a lot of improvements that can be done in this space, please note, the features that exists now in Ivelope consists of just a small percentage of what will come...

</comment></comment><comment><USER82> Looks fantastic - a long queue for the beta, but would like to give it a try. Early yet - but any plans to support plugins?

</comment><comment><USER83> Can't wait to try out the Linux version!

<comment> purple-again Its made with Electron so my understanding is it should work on Windows/Linux/Mac out of the box!

<comment><USER84> Electron? The obvious snarky comment has to then be "oh and it should manage to be slower than Thunderbird out of the box, too!"

I hope he's had better luck integrating spell check than the RamBox devs have ;)

edit: yes, I would love to test it and provide numbers rather than just snark - I just have to wait for the ~5,000 people ahead of me in the queue to have their software pressed to disk and posted to them before it's my turn o.0

<comment> muszc-master Haha "pressed to disk and posted" that was a fun remark :)

<comment><USER84> I'm baffled as to why I have to queue for something that's neither a physical product nor a service platform. Doubly so when the link posted seems to just bump someone else up the queue.

As a hacker news link it does strike me as a form of clickbait (and it honestly winds me up); "Hey HN! come look at this thing I've built that I'm not letting you look at!"

<comment> muszc-master Since I am only one developer currently, and there will probably be bugs, I don't want thousands of people having the same bug, this is the reason I'm not releasing it right away.

<comment><USER84> This seems like a totally legitimate reason - but in that case maybe the announcement on HN (the tech website keeping the slashdot* effect alive) should have come once there was a public RC.

Also, if it's bugs and the reporting of that you're worried about, maybe publish a proper bugtracker (github is both adequate and free) rather than just an email address?

* slashdot effect; as in taking a webserver down just with the amount of people viewing it. Or to put it another way, if you wanted lots of people viewing your project, let them. If you don't, then don't advertise it to them!

</comment></comment></comment></comment></comment></comment></comment><comment><USER85> Not a fan of the logo in the top bar. It looks like one of those tacky "gaming" keyboards with a logo on the space bar.

</comment><comment><USER86> The demo looks great!

Consider crowd-sourcing an american voice-over actor, it might add a lot of value for very little cost.

</comment><comment><USER87> Is there any pricing information?

</comment><comment><USER88> No Linux version (yet?), unfortunately. Looks nice though from the screenshots!

</comment><comment><USER89> The field really needs this so good luck. I'll test the first release that works on my os.

I

</comment><comment><USER90> Electron = no thanks. I might as well use my provider's web interface then.

</comment><comment><USER91> I see you have registered a company. How do you plan to monetize?

<comment><USER92> Just a guess after reading on LinkedIn what projects he has been working on previosly, he might monetize by in-app purchases to unlock features.

<comment><USER93> What about default search engine integration? How one makes such deal with Bing or Google?

</comment></comment></comment><comment><USER94> Hope @pg will see this - as he called for better email years ago

</comment><comment><USER95> how did you sustain yourself working on this fulk time for free?

<comment> muszc-master Noodles and savings

</comment></comment><comment><USER96> > Use Ivelope with your current email adresses.

adresses -> addresses

<comment> muszc-master Oops, second typo found. (I'm not a native speaker if that's an excuse :P)

</comment></comment><comment><USER97> Congrats on working hard and shipping an app!

</comment><comment><USER94> I love it.

The fwd with attachment should be no 1 to fix though

<comment> muszc-master Thanks for the feedback, fwd attachment priority noted

</comment></comment><comment><USER98> The chat-like interface looks great! kudos!

<comment> muszc-master Thanks!

<comment><USER99> having recently heard of autocrypt and delta.chat, I thought time is ripe for somebody to use this view in a regular email client. The demo video seemed to have exactly implemented this, I'm impressed.

</comment></comment></comment><comment><USER100> Sweet!!

Will you support PGP?

</comment><comment><USER101> +1 for the Office Space references

</comment><comment><USER102> Fuck man, just let me use it.

<comment> muszc-master What's the features you're mostly looking forward to? I'll see what I can do :P

</comment></comment><comment><USER103> Well, I am curious. Seems so hard to get an email client right. I would not mind paying (GPG integration is a must).

If you don't go the mutt/alpine route, there aren't much options. Basically Thunderbird and Evolution. Never really got Clawsemail and iscribe to work with my IMAP server settings.

To make things worse, people do understand email less and less. Often, all ports except 80 and 443 are blocked and you can't even use IMAP/SMTP. And if you complain they tell you "What are you talking about? Gmail works...."

<comment> muszc-master During development of this client, I fully understand why there aren't more email clients out there. GPG is coming!

<comment><USER103> Also, Gmails search function is a blast. Much worse in Thunderbird, annoying in Evolution.

<comment><USER104> Gmail searching isn't really that great, it doesn't do stemming while searching, offline clients should be able to do better than that.

</comment></comment></comment></comment><comment><USER20> You are not weird. More and more people think that Electron is bad

<comment><USER105> This is an "all my friends voted for..." argument.

Electron applications such as Slack, Discord, and VS Code have ballooned in popularity over the last year or two. Hacker News comments are not representative of the whole.

<comment><USER20> It is not about popularity, it is about the resources Electron apps use vs native. The apps that you mentioned do not have good native alternatives. I cannot see anyone preferring a native app over Electron app if both offer the same features.

<comment><USER106> I prefer VS Code over native alternatives. Don't conflate your anecdotal evidence with facts. Many users don't know much RAM a process consumes or what an Electron app is, they just care about what the app can do, how fast it is, etc.

<comment><USER107> > _I prefer VS Code over native alternatives._

That's because, as the parent said, there are no good (e.g. equivalent) native alternatives.

If there was a native editor with feature parity with VS Code (including the number of plugins and dedicated MS resources speeding up its development, and free), nobody would be using it.

<comment><USER108> > If there was a native editor with feature parity with VS Code (including the > number of plugins and dedicated MS resources speeding up its development, > and free), nobody would be using it.

Is it possible that VS Code (for example) exists (in its feature specific incarnation ) only _because_ Electron is a cost cutter in terms of portable development?

In other terms: Maybe the portable native full featured VS Code is the middle of the cheap-fast-good venn diagram.

<comment><USER107> > _Is it possible that VS Code (for example) exists (in its feature specific > incarnation ) only because Electron is a cost cutter in terms of portable > development?_

It could -- though I doubt it.

But I was concerned with a more limited question: if there was a good VS Code alternative that's native, would many still prefer an Electron version?

<comment><USER108> > But I was concerned with a more limited question: if there was a good VS > Code alternative that's native, would many still prefer an Electron version?

I understood what you meant. I respect you disagreeing with my premise, but in the scenario where that premise is true, your question is not applicable.

Scenario: Would anyone choose MDF boards at IKEA if they could choose plywood or natural wood, or assemble their own furniture if given the choice (at the same price)? Barring a few applications, probably not. But IKEA wouldn't be _IKEA_ if they were just another producer of wood furniture, meaning they got to market and stayed there because of the shortcuts and limitations they could justify when reaching a price.

Same thing here (IMHO). VS Code could have some cross-platform code and some platform specific code, but the cost would be higher and the output velocity would likely be lower. Assuming that is true, your question is misleading, albeit not on purpose.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER109> > Show HN: I've spent the last 2 years building a new email client

Where is the corresponding "Ask HN: What requirements should I consider before writing a new email client?"

<comment><USER110> > "Ask HN: What requirements should I consider before writing a new email > client?"

Oh boy. I've written a mail client [1] (two actually) and I've found that people have widely conflicting requirements.

Me? I wanted to replace mutt with something that was similarly console-based, and would use the same Maildir hierarchies.

Other people demand GUI access, sometimes with IMAP, sometimes with POP3, and sometimes (very rarely) with just local Maildirs.

If I were to begin again I'd probably abandon Maildirs, and instead just work via notmuch, or some other indexed-store. That would allow "virtual folders", and other neat things.

I don't think I've got the patience to start again though, as my current client is already the second version.

1 - [https://lumail.org/](https://lumail.org/)

</comment></comment><comment><USER111> Why do you spend 2 year of your live to build a new email client? Aren't there enought software for this scope?

</comment><comment><USER112> I have a side question for those who dislike electron apps (or prefer native):

1\. Which OS do you use use? I'd love to know if it's skewed to a particular OS to know which platform to prioritize a native client.

</comment><comment><USER113> It's not a client, when gmail changed it's TOS to use your messages, I wrote gpgmda. Found sup!? alot? notmuch.

[https://github.com/jakeogh/gpgmda](https://github.com/jakeogh/gpgmda)

</comment><comment><USER111> Why do you spent 2 year of your live to build a new email client? Aren't there quite software per this scope?

</comment><comment><USER114> It's unfortunate that this wasn't build with a cross-platform core, but native, first class UIs for each respective platform.

Edit: I realized this was worded very badly. I'm saying I wish this was written with a cross platform core, _and_ native, platform specific UIs for each respective platform. For example, MS Office is written this way.

<comment><USER78> I'd personally think "amazing" is a better adjective than "unfortunate" here - the value of an e-mail client, at least to me, lies almost entirely in its user interface. If using a native stack can squeeze out a few more tidbits of usability here and there, that's a good job well done. There's still a lot of value in native if it's done properly.

Electron and similar technologies are in my opinion not quite at the point where they can compete with the best that native platforms can offer. I'm sure that will change one day, but we're not there yet.

GTK integration on windows and mac is also less than perfect - I've been using geany on multiple platforms a lot recently and it's a great tool, but there's small annoyances like that the "swipe to scroll" speed varies massively between it and Notepad++.

<comment><USER114> Whoops, see my edit. We're totally advocating for the same thing - my wording was just very very bad :(</comment></comment></comment>


Actix Web: Optimization Amongst Optimizations - <AUTHOR> https://brandur.org/nanoglyphs/008-actix <comment><USER2> The reason the rust framework is winning on the fortunes is because of the ecosystem more so than the framework itself.

For instance, any database benchmark is going to favor frameworks that have a library that implements pipelining and asynchronicity. The fact that you're not allowed to modify the library unless you want your framework to be labeled a "raw" benchmark increases the benchmarks worth but doesn't come without caveats. The implementer of h20 which is the c server framework/library just below actix in that chart has mentioned something related to this:

[https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...](https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/C/h2o#database- tests)

So rust is "production grade" because its official library handles it for the framework separately. I LOVE these benchmarks because it points out the differences in each ecosystem when you're trying to find the fastest thing. I wouldn't have found a bunch of interesting projects without it.

If you want to really know about the raw speed, just look at the plaintext bench. The top frameworks are all being limited by the 40(!) gbps connection these guys are running. After picking any one of them the code _you_ write would be the limiting factor.

</comment><comment><USER3> Great write-up, brandur!

Actix has definitely deployed a broad suite of optimizations. When we posted Round 17 of our Framework Benchmarks, we wrote [1] about the stratified Fortunes results and attributed it in large part to our agreement to support the pipelining feature of PostgreSQL's protocol.

We had a conversation with the community about pipelined Postgres [2] when it was initially brought to our attention. Initially, we were opposed because it had a smell of cheating. However, after the dialog on the mailing list and several internal conversations, we remembered that one of the reasons we created the project was to encourage friendly competition, yield higher- performance platforms and frameworks, and ultimately benefit the application developers who use those frameworks. In that light, this form of optimization is exactly what we wanted to see (whether or not its genesis actually traces to this project). We _want_ to see such creative ways to reduce the overhead of frameworks, leaving more CPU capacity to the discretion of the application developer.

As long as they continue to live up to the spirit of our tests, of course. We believed this did live up to the spirit of our tests because these optimizations did not require the application developer to do anything to reap the benefit--they just run queries as usual.

And then there's that SIMD HTML escaping, which I admit kinda blew my mind.

[1] [https://www.techempower.com/blog/2018/10/30/framework- benchm...](https://www.techempower.com/blog/2018/10/30/framework-benchmarks- round-17/)

[2] [https://groups.google.com/d/topic/framework- benchmarks/Kbd2N...](https://groups.google.com/d/topic/framework- benchmarks/Kbd2No7xrv8/discussion)

</comment><comment><USER4> I see it also as a success story for Cargo. Actix can be optimized from top to bottom, without being a monolithic framework. It doesn't have to reinvent and optimize every component itself.

The SSE-accelerated escaping, postgres driver, and state-of-the-art hash tables are all packages that can be used without Actix. And Actix can take advantage of them without undue runtime overhead (thanks to generics+inlining) and without burdening users with build/install complexity (it depends on over 140 packages, and Cargo seamlessly takes care of that).

</comment><comment><USER5> > On startup, 128 request and response objects are pre-allocated in per-thread > pools. As a request comes in, one of them is checked out, populated, and > handed off to user code. When that code finishes with it and the object is > going out of scope, Drop kicks in and checks it back into the pool for > reuse. New objects are allocated only when pools are exhausted, thereby > saving many needless memory allocations and deallocations as a web server > handles normal traffic load.

As someone not very familiar with systems programming, I would have expected this is an optimization that would already happen automatically within the system memory allocator. Is that not the case?

<comment><USER6> You still need to initialize inner structures and buffers. Cache allows to avoid that.

<comment><USER5> Thanks for the response.

So it sounds like it is not so much the allocation/de-allocation savings that matters, but rather that you get to skip initializing the memory because it is already known to be a valid instance of a given struct type?

<comment><USER7> Yes, that.

See also SLAB allocation, used in many OS kernels: [https://en.wikipedia.org/wiki/Slab_allocation](https://en.wikipedia.org/wiki/Slab_allocation)

</comment></comment></comment></comment><comment><USER8> I enjoyed this quite a bit. I had read Nikolai's comment back when it was linked in a few discussions and felt familiar with the techniques, but it's really nice to have a detailed catalog with explanations and links :D.

nit re:

        Although designed to help speed up the parsing of
        XML documents, it turns out they're also useful for
        optimizing web-related features.

HTML is syntactically very close to XML in a bunch of ways (cf XHTML's attempt to unify them IIRC?), so it seems almost exactly like the intended use of the instructions based on this description.

</comment><comment><USER9> Nice write-up. Glad to see 2.0 performing just as well.

</comment><comment><USER10> Is anyone else just completely flabbergasted at the performance levels we're seeing at the top end of these benchmarks? 880k requests per second, with each request handling a database query? 7 million requests per second without database access? All on a single 16 core server? I don't even know what to think anymore.

</comment><comment><USER11> Beware, actix web has been caught cheating at this benchmarck.

Cf: [https://64.github.io/actix/](https://64.github.io/actix/)

<comment><USER12> Can you point in more detail where was the cheating?

What you link to talks over the great `unsafe` drama, but that's not cheating. `unsafe` is in Rust for a good reason. Every C and C++ codebase is effectively one big `unsafe` block from the perspective of Rust developer, and we don't think C/C++ are cheating. Rust devs frown upon overusing `usafe` for a good reason: it leads to obscure bugs and security issues. But if you use it correctly, in place that is critical for your performance - go for it.

Having said that - a lot of frameworks in that benchmark are over-optimizing in ways that no real practical app would do and arguably are cheating.If there's anything in particular about actix here, please let me know - I'm honestly interested in it.

<comment><USER13> The post linked in the GP discusses cheating in this section: [https://64.github.io/actix/#blazingly-fast-or- not](https://64.github.io/actix/#blazingly-fast-or-not)

Note that this is for the "raw" version of the plain-text and JSON benchmarks, not the fortune benchmark covered in the OP. But I wonder why that raw version is even there. It certainly isn't "realistic", as it claims to be in benchmark_config.json

<comment><USER14> Also from that section

> In fairness, it seems other benchmarks are doing these things

Personally, I think it's pretty reasonable to sink to the same level as the competition.</comment></comment></comment></comment>


It's Time to End the War on Salt (2011) - <AUTHOR> http://www.scientificamerican.com/article/its-time-to-end-the-war-on-salt/ <comment><USER4> To me, the story of salt strongly highlights the difference between science (as in, the results of scientific experiments and careful reasoning), and "science", the things the general public is told science has found by journalists and policymakers.

Not only was there was never a strong scientific basis for telling people to reduce their salt intake, my anecdotal observation is that it's fairly easy to wind up salt-deficient and get symptoms. Sweat contains salt (1g/L), so when exercising or in high temperatures, I need to eat more of it, or I'll get fatigued and physical exertion will become impossible. (Sweat also makes exercise a confounder in studies that look at urinary excretion.)

Meanwhile, foods that we think of as "salty" are usually not actually salty, but rather, are designed to create salt pica. If you start eating potato chips, with most American brands, you'll get to 2000 calories before you get to a typical salt intake (which is 3.5g).

<comment><USER5> Just looked up a bag of chips:

       100g:
         525 cal
         1.5 g salt

Multiply by ~3.8:

      380g:
        2000 cal
        5.7 g salt

Your mileage may vary, but in Norway, a typical bag of chips contains more than 3.5g of salt per 2000 calories.

<comment><USER6> Looked up a nutrition label online: [https://healthyeatingrocks.files.wordpress.com/2012/08/lays-...](https://healthyeatingrocks.files.wordpress.com/2012/08/lays- chips.png)

        1 oz:
          150 Calories
          180 mg sodium

multiply by 20/3:

        6.667 oz:
          2000 Calories
          1.2g sodium

The kosher salt in my cupboard (ingredients: salt and an anti-caking agent) is 40% sodium by mass (480 mg sodium per 1.2 grams). Or, going by the atomic mass listed here ( [http://www.chemicalelements.com/show/mass.html](http://www.chemicalelements.com/show/mass.html) ), sodium chloride should be 39% sodium by mass. Assuming an even 40%, that's 3 grams of salt (NaCl) in 2000 Calories of american potato chips. (Or, assuming the less generous actual amu ratio, _3.05_ grams of salt per 2000 Calories ;D )

HOWEVER: the nutrition label also indicates almost twice as much potassium (330 mg) as sodium. If that potassium is also salt (KCl), the chips will handily exceed 3.5 grams of salt per 2000 Calories.

<comment><USER7> I've read somewhere before that the issue may be K vs. Na balance.

Take that with a grain of ... nevermind.

<comment><USER6> If that's true, those potato chips should be made with a lot _more_ sodium. (Or, you know, some more sodium and less potassium. I don't think people would eat the "now with 62% more table salt" version of the chips.)

Wikipedia says: an ion pump exchanges 3 sodium ions for 2 potassium ions. ( [https://en.wikipedia.org/wiki/Sodium](https://en.wikipedia.org/wiki/Sodium) )

3 sodium ions is 69 atomic mass units. 2 potassiums is 78.2 atomic mass units.

</comment></comment></comment></comment></comment><comment><USER8> Unrelated to the article directly, but a pretty fascinating story of salt:

 _By the end of the 2nd century CE, workers had devised a system of leather valves and bamboo pipes which drew up both brine and natural gas, which they burned to boil the brine (the technology they developed for the bamboo piping was eventually applied to household plumbing)._

[https://en.wikipedia.org/wiki/Salt_in_Chinese_history#Ancien...](https://en.wikipedia.org/wiki/Salt_in_Chinese_history#Ancient_China_and_the_early_empire)

</comment><comment><USER9> As someone who eats strictly keto (low-carb/high-fat), I actually have to make a concerted effort to get enough salt in my diet due to my naturally retaining less water than non-keto people.

This includes making somewhat high-salt food choices wherever reasonable — bacon, pickles, salted butter, cooking with salt in general, etc. — as well as actually adding a salt/electrolyte solution to the water I drink throughout each day. Not only is my blood pressure fine, my most recent blood test sodium levels are actually on the low end of normal (so I've been trying to bump up my salt intake even a bit higher).

Not sure if this says anything interesting about salt, except maybe that carbohydrates could be the real problem that got salt unfairly blamed.

<comment><USER10> I gotta ask. I don't mean to offend. Keto diet sounds like a good way to lose weight. But does it make ones breath smell?

<comment><USER11> I can jump in here. I lost 16kg on a ketogenic diet.

My gut is a lot happier as evidenced by more regular and better (firm, soft, not runny) bowel movements.

There is a definite smell (breath) associated with ketosis. It varies by person but it is often noticeable.

I asked my wife to track it as it's very hard to notice it yourself and she says that my system produces a slightly metallic smell the isn't objectively bad, just different to normal.

I have Muslim friends and during Ramadaan there is a noticeable smell which is subjectively bad from some of them.

A friend who works as a nurse in a very low income area says that she can detect someone who isn't eating normally by the smell - very important to spot if that person is also pregnant.

It's a long way of saying: yes there is a smell, it varies by person.

<comment><USER12> During Ramadan Muslims are not allowed to drink water, right? That probably means their mouth is very dry during the fasting time meaning there's more than usual amount of odor-causing bacteria in their mouth.

</comment></comment></comment></comment><comment><USER13> Oh good grief. Another article mangling science into sound bites?

I particularly enjoy the seemingly wilful conflation with hyponatraemia (too low sodium).

> European researchers publishing in the Journal of the American Medical > Association reported that the less sodium that study subjects excreted in > their urine —an excellent measure of prior consumption— the greater their > risk was of dying from heart disease

Nobody has ever argued that NO SALT is the right idea. So of course people with the lowest output, people with hyponatraemia and knackered kidneys, are going to have other issues. Sodium is essential for neural function and osmotic control.

And the outcome of main meta-analysis in this wasn't "DO THIS INSTEAD" it was to recommend conducting an actual long-term controlled study to see what the actual effects of sodium control are.

Either which way, repeatedly highlight articles that say "EVERYTHING YOU KNEW BEFORE WAS WRONG: DO THIS INSTEAD" just makes people give up _completely_. Especially when the meta-meta-analysis is as weak as this is.

<comment><USER14> > Nobody has ever argued that NO SALT is the right idea.

Some people have been saying exactly that, e.g.: [http://www.enformy.com/blog/benefits-of-no-salt- diet.php](http://www.enformy.com/blog/benefits-of-no-salt-diet.php)

<comment><USER13> It's called the "No Salt Diet" but it doesn't actually cut out salt completely. It's more about processed rubbish and vast quantities of added salt.

Either which way, you are probably right. If you look hard enough, there probably is _somebody_ out there saying anything you want. I should adjust the statement to:

> Nobody qualified to talk on the subject has ever ...

</comment></comment></comment><comment><USER15> In Neil deGrasse Tyson's StarTalk radio show he interviewed The author of "Salt: A World History"[1|2] who said (paraphrased) that statistically, it makes some sense to tell the public to not each too much salt, but on an individual basis you can either eat as much salt as you want or you have a health problem like high blood-pressure.

[1] [http://www.startalkradio.net/show/the-salt-of-the-earth- part...](http://www.startalkradio.net/show/the-salt-of-the-earth-part-1/)

[2] [http://www.startalkradio.net/show/the-salt-of-the-earth- part...](http://www.startalkradio.net/show/the-salt-of-the-earth-part-2/)

(I cannot remember if it was part 1 or part 2, so I linked both parts.)

<comment><USER16> Yep. And to clarify, the health problems that may make salt restrictions helpful generally involve impaired renal function or other kidney problems. If you have chronic renal disease, you need to be damn careful about your sodium intake, because you're not going to be able to excrete it properly.

</comment></comment><comment><USER17> There's a war on salt? Whole foods has an entire wall of salt. There are entire physical and online stores selling nothing but salts.

Sea salt? Would you like it from France, Alaska, or Iceland? How about colored salt? Pink from the Himalayas, green jasmine salt, blue salt that I'm not sure where it's from. Smoked salt?

Salt bath scrubs? Salt bars for cleansing? Heck, you can even buy a salt _lamp_.

<comment><USER18> A war by doctors, not businesses. I'd consider it "common knowledge" that salt raises blood pressure and that you should eat less salt if you have high blood pressure. My father and at least a couple other 50+ year old people I know try to limit their salt intake for health reasons.

<comment><USER19> This "common knowledge" is incorrect. It applies only if you have sodium- sensitive hypertension, and chances are, you don't.

[http://www.gbhealthwatch.com/Trait-Salt- Sensitivity.php](http://www.gbhealthwatch.com/Trait-Salt-Sensitivity.php)

<comment><USER18> Yes exactly, that's what the article is about.

</comment></comment></comment></comment><comment><USER20> This is one of those "listen to your body" things I'm doing.

I've done pretty physical construction work during summers. Drinking 6L of water during the day in the process. After three weeks, sucking grains of sea salt tasted better than any candy. Until they suddenly didn't.

On the other hand, during the winter pickles started to taste really bad.

I try to eat my salt so that I actually taste it. When you mix it evenly to mashed potatoes, you only get to taste fraction of the actual salt. And if you put lot's of salt to bacon, your belly will prioritize fat over getting too much salt. This is all based on the idea that my body knows what is best for it. But I have to enable that sometimes.

<comment><USER21> That sounds good for you. But there's evidence that gut microbes work against your body to serve themselves rather than your health

</comment></comment><comment><USER22> The strictly non-commercial, science-based public service called NutritionFacts.org researched the health effects of sodium and published a video two days ago summarising the evidence that salt raises blood pressure.

[http://nutritionfacts.org/video/the-evidence-that-salt- raise...](http://nutritionfacts.org/video/the-evidence-that-salt-raises-blood- pressure/)

</comment><comment><USER23> What I find interesting is that this issue about sodium being unhealthy never really reached Europe (or at least Germany). While the US was advertising "low sodium" on their products we are still mostly advertising "low fat" and have some "low carb" pioneers. It seems to me that the whole "sodium is bad" scheme was a poorly supported health tip gone viral.

<comment><USER24> Reducing sodium intake has been a thing doctors recommend in Finland, at least. Ask any nurse, and they will tell you that sodium intake is definitely connected with high blood pressure and heart disease.

Also, they will tell you need to drink lots of milk to keep your bones strong. Also a piece of "science" on it's way out.

<comment><USER25> I was under the impression that many Finns have a genetical risk of hypertension. Thus studies about the link between salt intake and hypertension have been conducted, for example [http://www.ncbi.nlm.nih.gov/pubmed/17046432](http://www.ncbi.nlm.nih.gov/pubmed/17046432). I haven't actually read the paper, but the abstract has this claim:

"During the past 30 years, the one-third decrease in the average salt intake has been accompanied by a more than 10-mm Hg fall in the population average of both systolic and diastolic blood pressure, and a 75% to 80% decrease in both stroke and coronary heart disease mortality in Finland."

</comment></comment></comment><comment><USER26> I think it's important to look beyond hypertension before completely ending the war on salt.

Very high salt intake may influence the risk of H. pylori infection - the main cause of stomach cancer. It increases the risk of atrophic gastritis (chronic inflammation of the stomach), which makes the stomach more prone to infection, and increases the susceptibility of mucosa to neoplastic change once an infection occurs.

If you think nobody consumes this level of salt, the Chinese and Japanese had extremely high levels of stomach cancer decades ago before reducing their salt intake and preservative consumption. To some extent, these problems persist to this day. Completely ignoring salt (especially in convenience foods) could reignite the issue.

<comment><USER27> > (especially in convenience foods)

I think this is the key. Most salty processed foods have enormous amounts of salt that you'd never add if you were cooking it yourself. Same with sugar in sweet snacks.

</comment></comment><comment><USER28> It tallies with what my renal dietician (i have serios kidney problems) said when I asked her about switching to low salt versions of soy salt.

"its been well marketed, but what they don't tell you is the shit they replace salt with in these lo salt versions"

</comment><comment><USER29> According the the latest news release we should be having a new jihad on salt, damn the lack of evidence.

 _You're probably eating too much salt, new guidelines say_

[https://www.washingtonpost.com/news/to-your- health/wp/2016/0...](https://www.washingtonpost.com/news/to-your- health/wp/2016/01/07/salt-new-u-s-dietary-guidelines-call-for-americans-to- lower-intake-to-a-teaspoon-a-day/)

</comment><comment><USER30> I'm another person who was avoiding salt - thinking it was bad for me - <USER3> then discovered that I wasn't getting enough salt. My body's temperature regulation was a mess - hot & not sweating with a dry mouth and dry sinus. So I started putting a teaspoon of salt into my morning fruit smoothy - <USER3> suddenly all the symptoms went away. I wish I had known sooner.

I've started using sea salt exclusively, since grocery store salt is just extracted NaCl - which isn't what traditional salt, the salt that's been eaten for centuries, really is. Sea salt is said to have a composition of trace elements which closely resembles the human body. Sea salt has a much lower percentage of NaCl than the processed salt.

I should add that I don't eat a lot of processed food. I cook basic foods and put them in the freezer so I can eat them throughout the week. That is most of my diet. So most of my salt was probably just the occasional junk food I would eat.

<comment><USER31> This is just wrong. Brine wells have been used for centuries, and industrial mining of salt, while newer, has still occurred for hundreds of years.

Further, sea salt and table salt both contain approximately 40% sodium.

If you prefer the taste or texture of sea salt, that's fine, but don't claim that sea salt is inherently better for you, because we have studies that show this isn't the case.

<comment><USER30> Well, I'm no expert on salt - but as a Neti pot user I can instantly tell when I'm using grocery store salt. And, coincidentally, I worked for several years at the shore beside salt collection fields. We all used to joke that we hoped the salt we bought wasn't from those fields - since the water was known to be very polluted (and fishing was often prohibited.) So I can't take seriously any claim that grocery store salt is the same as any given sea salt. And there are plenty of studies showing significant differences. And, at this point, the only studies I've seen about grocery store salt just tout their purity of NaCl (which, again, is not historically what salt was), and claim that the only significant consideration about salt is the things I don't care about (typically their definition of "purity").

</comment></comment></comment><comment><USER32> It amazes me how bad much of the dietary advice out there is, scientifically speaking. Somehow something like politics gets mixed in. It would be comical if it didn't lead to so much unnecessary death and suffering.

<comment><USER33> You'd be surprised. I was. It's even worse than you think. Most of nutrition "out there" is bullshit.

[http://fivethirtyeight.com/features/you-cant-trust-what- you-...](http://fivethirtyeight.com/features/you-cant-trust-what-you-read- about-nutrition/)

[https://news.ycombinator.com/item?id=10851843](https://news.ycombinator.com/item?id=10851843)

</comment></comment><comment><USER34> So excess of it ceases to cause higher blod pressure or liquid retention, especially in overweight and obese?

<comment><USER35> I'm not sure what your question is, but the complicated thing with blood pressure is that it is regulated by your body. So if you do something or eat something that raises your blood pressure, your body will respond by lowering your blood pressure. And if you do things to lower your blood pressure, as it says in the article, your body will respond by releasing renin and aldosterone to increase your blood pressure.

<comment><USER34> According to the very basics of human physiology, excess of Na in blood stream will cause water molecules to leave cells and bind to sodium, which causes dehydration of cells and higher blood pressure, to which kidney should respond. That's why we feel thirsty after salty foods - to take more water into the system so eventually cells will go back to balance.

Prolonged exess of sodium which is maintained by habitual consumption of packaged foods causes imbalance and unnecessary burden to the system, so it works much less effective with obese people.

Water retention in various places of the body is also caused by exess of salt, which is a side-effect of a chronic imbalance.

<comment><USER34> NaCl, sorry.</comment></comment></comment></comment>


A violin cold case is solved - <AUTHOR> http://www.bendbulletin.com/lifestyle/3400054-151/a-violin-cold-case-is-solved#

<comment><USER2> The violin in question belonged to NPR presenter Nina Totenberg's Father. You can hear her report on this story here: [http://www.npr.org/2015/08/06/427718240/a-rarity- reclaimed-s...](http://www.npr.org/2015/08/06/427718240/a-rarity-reclaimed- stolen-stradivarius-recovered-after-35-years)</comment>


Clickpass v. Justin.tv - <AUTHOR> http://www.facebook.com/event.php?eid=9950868902 OpenID - what is it, how do you implement it and how can you layer the magic that is Clickpass on top of it.
This Thursday, 27th March, 12pm at Justin.tv in San Francisco:
36 Clyde St. San Francisco, California 94103 <comment><AUTHOR> OpenID - what is it, how do you implement it and how can you layer the magic that is Clickpass on top of it.

This Thursday, 27th March, 12pm at Justin.tv in San Francisco:

36 Clyde St. San Francisco, California 94103

</comment><comment><USER2> Has anyone talked to nontech people about OpenID? Do they understand what it is and are they using it?

<comment><AUTHOR> That's exactly some of what we'll be talking about - they love the idea but tend to get confused by the logistics

</comment></comment><comment><USER3> Really? Stuff that requires a Facebook login to access is front-page material?

You can go take your data roach motels and cram 'em up your ass.

<comment><USER4> Its a Facebook event. Welcome to the Internet

<comment><USER5> You mean: welcome to the new AOL.

<comment><USER4> :)

</comment></comment></comment></comment><comment><USER6> Will the event be streamed on JTV Peter?

<comment><USER7> It will be streamed - you'll be able to see it at <http://www.justin.tv/hackertv></comment></comment>


Facebook, Zuckerberg say ownership contract forged - <AUTHOR> http://www.reuters.com/article/2011/06/02/us-facebook-lawsuit-idUSTRE75144220110602?feedType=RSS&feedName=technologyNews&dlvrit=56505 <comment><USER2> This is huge; saying unilaterally to the court that the documents are forged sets up a massive worst-case "you lied when you told me these are forged" scenario.

Frankly, I'm surprised. I would have guessed that they'd take a "This isn't the A Facebook you're looking for" angle.

I'm marking this as the moment that Zuckerberg steps fully into his CEO role; this is a quality counter-attack from someone who is no longer placating early co-founders.

</comment><comment><USER3> I don't know much about going public but if (or when) they prove that Ceglia is lying it will reflect quite nicely on Facebook.</comment>


Ask HN: Can anyone help me? Room needed in SF - <AUTHOR>

I got accepted to the MakeGamesWithUs summer internship in San Fran but I don't have a place to stay and I don't know anyone out there. I'm from the midwest. Being 17 kind of makes my situation a little tougher. I really want to go to the internship but finding a place to stay is my problem. I plan to be there for 4-6 weeks which makes my problem even bigger because I don't know if anyone will allow me to stay with them for that long.
If anyone can help me, please let me know. I'm sort of desperate. I need to know by June 5th. My internship is from June 17th to July 22nd at MakeGamesWithUs in San Francisco. It's located in SOMA. I might stay 1-2 weeks longer and I plan to arrive 2-4 days in advance before it starts. I'm 17, from the midwest, African American. Not sure what else to say.
If you have anything, please feel free to email me at firstname.lastname@example.com <comment><USER2> With housing costs being absurdly high in the SF Bay Area, your chances of finding a place to stay for FREE are slim to none. Maybe if you had connections in the area that could let you crash on their couch, but by the sounds of it you don't.

Best of luck to you.</comment>


New e-book: Hands-on Scala.js - <AUTHOR> http://lihaoyi.github.io/hands-on-scala-js

<comment><USER2> Wow, this page does weird and horrible things to the history. The back button doesn't work.</comment>


AMD falls despite beating Q4 estimates - <AUTHOR> https://www.cnbc.com/2018/01/30/amd-earnings-q4-2017.html <comment><USER2> This happens every quarter. There is usually a logical explanation is some sense of the word, but the stock market really is silly.</comment>


Is Zynga The Most Profitable Company Ever? - <AUTHOR> http://www.businessinsider.com/how-stupid-facebook-games-made-zynga-the-most-profitable-company-ever-2011-2?slop=1 <comment><USER2> The comment by Myzplk is quite insightful:

 _They're profit margin is impressive, but there are quite a few companies in the same range -[http://ycharts.com/calculations/rankings/sectors/Technology/...](http://ycharts.com/calculations/rankings/sectors/Technology/profit_margin) _</comment>


How to deal with "Scrooge McDucks" in my fixed-currency-amount game? - <AUTHOR> https://gamedev.stackexchange.com/q/162401/4661 <comment><USER2> As an economist, I have to tell you that fixed-currency-amount systems (such as the gold standard and bitcoin and other fixed-amount cryptocurrency systems) are derided for some very good reasons, including those expressed here: it's possible for few agents to essentially hoard all the currency the economy needs to run.

My best suggestion is instituting a heavy negative tax on funds in excess of an arbitrary large amount that remain un-moved for a certain reasonable lapse of time. The taxes would then be re-distributed equally to all other players' accounts.</comment>


TripAdvisor Architecture - 40M Visitors, 200M Dynamic Page Views, 30TB Data - <AUTHOR> http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html <comment><USER2> "You own your code and its effects - you design, you test, you code, you monitor. If you break something, you fix it."

I couldn't agree more. The more I work with code and people, the more I realize the importance of this statement. Having separate roles for "Architect", "Programmer", "Tester" and "Support" is excellent if you want to introduce bureaucracy and process into the work place and consider programmers as just "cogs in a machine". It's also excellent if you want to see how work can grind to a halt.

Let people own their work and they will only produce things that they are proud of.

<comment><USER3> The other thing it introduces though is "not my code". There used to be a guy we used to call the "Teflon Don". You couldn't get a bug to stick to him. He could always find a way to move a bug to someone else -- even if it came back, he would spend more time trying to figure out how to pass it on to someone else, rather than just fix it.

At the end of the day hire good ppl. They'll do the right thing most of the time. Hire the wrong people and you'll find that your incentive structure will always lead to deviant behavior.

<comment><USER4> (disclosure - I am the author of this article)

"At the end of the day hire good ppl. They'll do the right thing most of the time." - absolutely agree.

No system is perfect, ours is not. You need to decide what is important to your organization and emphasize it - they way we do things here at TA has its downsides, but overall, it works very well for us and what we want to do. The benefits for us significantly outweigh the drawbacks.

It is critical to have a boss who understands how software development works, and that mistakes get made. If anything, my boss wants my team to make more mistakes than we do :-)

</comment></comment></comment><comment><USER3> Really good article.

One point I do disagree with is this:

 _It is better to deliver 20 projects with 10 bugs and miss 5 projects by two days than to deliver 10 projects that are all perfect and on time._

You never actually have such a choice, but if one did exist I'd pick 10 perfect on-time projects. The problem is I don't know what the 10 bugs are. While I'd like them to all be typos in the footer of the contacts page, they could also be data corruption or a password leak.

If I had ppl that delivered on time with no bugs, but at half the speed, it then becomes my job to do a good prioritizing the projects such that the half we do are the right half. I think the constraint of being half as fast might even force us to make better choices.

<comment><USER5> For any project, you're always balancing quality, schedule, budget, scope and risk to try to get the best business outcome. Because of this, I don't believe in any of the hard and fast rules about the "right" way to code. It's far too situational.

That said, you make an excellent point about the importance of project prioritization. A management team who is good at identifying high ROI projects will stomp all over one who sprays pointless change requests at their dev team.

</comment></comment><comment><USER6> I've helped my grandmother manage her business listing on there. It has brought many happy costumers and for at least 4 months a year we have a full booking of all spaces. However, the product is poorly done. It is hard to navigate and there are no tools to share accounts or have multiple listings within one account. I've also encountered numerous technical errors and limitations that make me think the product might not be secure. It feels like the more recent features are sitting on an outdated and overly complex codebase (just a guess).

So if any TripAdvisor employees are listening - thank you for a product that has worked well for us. But if you can improve it I am sure you could bring in more costumers on both ends (managers and travelers).

<comment><USER4> Hi jokull,

Would like to understand more, is there a way to contact you ?

Andy

<comment><USER6> firstname.lastname@example.com

</comment></comment></comment><comment><USER7> Some reflections:

Culture

      - The "all engineering is organized by business function" is a business trick i've seen old dot-coms implement. When you have a business function that goes from making you money to costing you, just fire everyone in that business function and sell it off. You quickly get rid of what's dragging you down and continue your profitable business functions. However, this also creates duplication of some jobs, waste, and an insidious bureaucracy where teams are fighting each other. (I could have read that section wrong, but that's what it reminded me of)

      - Engineering Swaps: Really? You just uproot people so they have to re-learn how something else works and take time away from getting stuff done? Couldn't you just do a couple hour-long knowledge sharing sessions between developers?

Random thoughts

\- Don't design too far ahead - doesn't fighting fires and coming up on sudden, unexpected deadline changes due to lack of foresight kind of drag on your employees? You can't keep overworked code monkeys forever. It's one thing to code "quick and dirty" to get a job done. It's another thing not to plan for the future.

\- Put end to end responsibility on a single engineer - so when that guy's on vacation nobody knows how to fix the thing he owns that broke?

\- Process - Doesn't say if you require change control, but some sort of change alert/control system is really useful to tell people when you're changing something which may affect others, so they can immediately see what could have affected the broken thing and call the person who could have broken it.

<comment><USER4> (disclosure - I am the author of this article) I think this comes down to judgment.

Design appropriately. Short sighted designs are as bad as ivory tower designs. Every situation is different.

If a person does not own something, no one does - everything comes down to the individual. This does not mean that there is no overlap in knowledge.

Source control is a must. So are scripts that detect changes in your area. So are tests.

</comment></comment><comment><USER8> "It is far better to do two queries (get the set of reviews with their member ids, then get all of the member from this set of ids and merge it at the app level) than do a join."

Is this way really faster? We've been moving the opposite direction in a Rails app (from iterating over data in ruby to joins). We have a fast RDS instance that seems to far outperform our app running on Heroku for complex data manipulation.

<comment><USER9> If they are joining across partitions, then perhaps. If they are forced to localize data to make it joinable, whereas doing the "join" at the app level makes it more horizontally scalable, then that might be an impact.

However against a single instance if you can join in your app faster than on the database for a trivial join, something is seriously wrong with your implementation. I have never, ever seen such a case where it wasn't a scenario where they should have analyzed their plan, to discover a monstrous issue they need to resolve.

In many high performance database systems the IPC to the database level is actually the most expensive operation. Doing two calls instead of one is always a net negative unless you're doing something wrong or fit isolated horizonal scaling scenarios.

<comment><USER4> (disclosure, I am the author of this post)

Hi hn_decay,

Our use case goes like this: a member database of over a 100M records, and a number of content databases each with tens or hundreds of millions of records (reviews, video, lists, wiki, this, that , the other thing, one content table with over a billion records, where all the content records had a member id. Our primary usage pattern is to grab a set of content records (say 10-200 at a time) with their member information.

Putting everything in one database and doing the join there does not scale for us, and severely reduces flexibility. We would need to continue to scale up our hardware to handle the sum of the content sets, and new content sets are being created on a regular basis. By putting these all into different databases you then have the choice (not the necessity) of keeping them on one or more machines. You can put on one machine a bunch of content sets that are relatively small, and put the big ones on their own machine. You can also scale the hardware to individual content sets - infrequently accessed content sets do not have to be on powerful machines, very frequently accessed sets can be scaled on bigger machines.

There are downsides, the two-query hit being the least significant, the extra query on a tuned database is on order of 1ms. Even if the hit was larger, I would still live it, scalability != performance

Andy

<comment><USER9> I was replying to the context of the post, and specifically spoke to horizontal scalability so I am confused that you felt it appropriate to "correct" that.

Having said that, hundreds of millions of records equals a small dataset. I still don't understand when that's held as some sort of edge case when it's easily accommodated on commodity low-end hardware.

</comment></comment></comment></comment><comment><USER10> I find myself surfing to tripadvisor often when travelling. They would have the potential to build a airbnb right in there..

<comment><USER11> I think they have.. AirBnB like sites have existed for a while: [http://www.flipkey.com/?utm_source=ta&utm_medium=foot...](http://www.flipkey.com/?utm_source=ta&utm_medium=foot&utm_campaign=tamg)

</comment></comment><comment><USER12> Full Disclosure: I work at TripAdvisor.

Andy's assessment is accurate and is part of the reason I really, really like it here. The other part is the folks I get to work with.

If you're interested in joining us, drop me a line. Info in my HN profile.

<comment><USER13> Why does your site use behind-the-window popups even though I have popup blocking explicitly enabled in my browser? If I were hired at TripAdvisor could my first project be to get rid of such scumbag behavior?</comment></comment>


MacBook Air Not Selling All That Well - <AUTHOR> http://www.webpronews.com/topnews/2008/02/14/macbook-air-not-selling-all-that-well <comment><USER2> Ridiculous article.

"Still, new findings suggest that people are doing more looking than buying, and that by year's end, transactions involving the Air will account for only 16 percent of Mac sales."

Assuming this figure is correct, which is a pretty big assumption, this is _great_ news for Apple. There are 6 major mac product lines (mac pro, imac, mac mini, macbook, macbook pro, macbook air). All things being equal, each product line should expect to get 1/6 (or about 16%) of sales.

Of course, all things are not equal. The macbook and iMac will sell a lot more than the Mac Pro or Macbook Air, by design. As a result, you would expect the percentage of high priced products, like the Air, to be _less_ then their fair share. The fact that they are holding steady is a pretty good sign.</comment>


Here's why Google will acquire Uber - <AUTHOR> http://anthonypompliano.com/2014/10/08/google-will-acquire-uber-heres-why/

<comment><USER2> You submitted this a couple hours ago. Deleting then resubmitting is against HN rules.

<comment><AUTHOR> Didn't know. Thanks for heads up!</comment></comment>


An Autistic Ethos: It's All About Respect - <AUTHOR> http://www.shiftjournal.com/2010/01/08/an-autistic-ethos-its-all-about-respect/

<comment><AUTHOR> Or, "an IT ethos is an autistic ethos is an IT ethos." Jeff Ello's Computerworld article The Unspoken Truth About Managing Geeks as a template for understanding autism -- and vice versa.</comment>