Why we ditched Django for Microservices - <AUTHOR> http://blog.hubblehq.com/ditching-django-for-microservices-1/ <comment><USER2> More often than not, I start my projects thinking that they would be small and don't need a comprehensive framework like Django. Then I figure I need an authentication mechanism, SQL abstraction, an admin site, a pipeline to handle, verify the requests and so on. Then I switch back to Django mostly because I don't want to rediscover the world again. Surely given enough time I could rediscover, but why would one bother?

As per staying _lean_ as stated in the article. I don't think that's staying lean at all. I must mention that I have no knowledge of the framework or codebase of the company in question, although rewriting a codebase is almost never a good idea. Well, it will require a lot of rewriting which is redundant, you would be ditching a lot of testing and bug fixing you have done ever since, and you will probably create a space a lot of new bugs.

I believe a better approach would be componentize your structure in a way that's still governed by django, every component split into apps. And if there are outlier apps that do not need to be within Django at all could be used by redirecting the requests to those services on the load balancer / reverse proxy level.

<comment><AUTHOR> We're lucky enough that we decided early enough for it not to be too big an issue.

Also we split up the re-write over stages and haven't done it all in one go. I'm gonna write more about it in another blog post but essentially we still have our monolithic Django system.

It currently powers the majority of the services except we have changed the architecture so we can split things out overtime. This allowed us to achieve what we wanted to in 4 weeks yet lay the groundwork for the future.

</comment></comment><comment><USER3> This makes no sense from a business perspective. Letting developers work using any languages and technologies sounds like a good idea to individual developers maybe but how do you intend to maintain it? If you stick to a few core languages and technologies and hire / train for those tech then you reduce your risk if one or more developers leave and reduce the total complexity of your stack. You should have a good reason for introducing a new language or technology to your stack and think carefully before diving in. Just create separate Django apps and only switch to a different tech if Django is particularly ill suited for the task.

<comment><AUTHOR> I perhaps should have explained that a bit more. Technology choices have to make sense before implemented but giving developers the flexibility opens a lot of doors for creativity and exploration.

I strongly believe that learning new languages help people become better coders overall as it increases their knowledge of different problems and solutions which can be applied across most stacks.

Also no one developer should ever be solely responsible for a particular service. But that should also be the case for apps within a Django project.

<comment><USER3> As a business if you want to encourage your developers to improve by exposing them to more different types of languages and technologies then I am all for it. You can fund a weekly Haskell class. You can implement a 20% time initiative and let developers work on prototypes using whatever tech they want. For your production systems, however, you need to have some boundaries to serve the business even if you are a tech company run by engineers.

</comment></comment></comment><comment><USER4> I don't get it: why does moving to microservices mean ditching Django? Couldn't you take your Django monolith and break it into separate (still- Django) microservices? I get that Django is seen as "too heavyweight" to do such a thing, though there are literally books ([http://shop.oreilly.com/product/0636920032502.do](http://shop.oreilly.com/product/0636920032502.do)) written about how to slim down Django.

I get that monolith to microservice is all the rage these days, I just don't understand (and the article doesn't really say) why you have to "ditch Django" to do that.

<comment><USER5> Seconding this. Could someone clarify?

I thought Django and "microservices" are orthogonal. Can't Django be used to create any service, even a micro service? I certainly used Django in the past just as a REST server, without any "web site" to speak of. It just reduces some boiler plate.

<comment><USER6> Using Django Rest Framework is practically the EASIEST tool for building microservices I've ever used. It's incredible how awesome it is for building APIs. We were recently looking at building out some new services in Flask or Express. We compared the advantages of each to DRF and quickly concluded that it wasn't worth it. DRF has so much commonly used stuff done for you and it sets up one of the best standards for REST API's I've ever seen.

<comment><USER7> Flask is so minimal. Curious what were the disadvantages that weighed against chosing Flask.

<comment><USER8> Flask is too minimal. Using DRF is like having code written for you. Because, you know, the code was written (and battle-tested) for you. Why start from a log every time when you can get a wheel for free?

</comment></comment></comment></comment></comment><comment><USER9> I think the biggest reason people are switching to microservices is that it enforces protocols and documentation between components that would otherwise never be created.

Microservices create a boundary and that forces you to create a request/response protocol to enforce that boundary. You also have to create documentation for it to be useful.

There is nothing stopping you from creating your app as a bunch of small services without the added complexity of microservices/SOA. Each slice of your system could be an isolated library with a stronger enforced protocol and documentation and you'd get largely the same benefits without having to deal with the deployment headache.

The reason people don't do that is if they build isolated components in the same monolitic system, nobody takes the time to create a proper protocol and documentation.

The only way people seem to be willing to give separate services the appropriate design respect is to physically separate them and solve them as an isolated problem. The physical separation forces better behavior for microservices to even be useful.

It doesn't help that most languages have really weak capabilities to enforce strong protocols/boundaries beyond a simple type checker via complier. A language like JS, Python, PHP, Ruby, etc. don't even have a compiler so the ability/desire to create strong protocols in most code is almost nonexistent to most developers.

</comment><comment><USER10> > A microservices architecture is (fairly) new and it doesn't tie you to a > particular language. If you want to build a service in Lisp, Go, Elixir, etc > then you can (assuming it makes sense). Good devs love to learn, experiment > and hate being bored. A microservices approach encourages all of that

The developer in me kind of likes that - fun new toys! But from a business point of view, I'm not sure it sounds like such a good idea: lots of weird, unmaintainable stuff.

<comment><USER11> And of course, ignoring the problem of duct-taping all the services together.

"Oh we'll just RabbitMQ everything together", sure, great, until you discovered certain services needed a smaller latency, more bandwidth, etc

And RabbitMQ libraries are a pain and are not smart

<comment><USER12> actually this is a question that I have - how do you render the final output ?

I mean lets say I request a web page which depends on 5 microservices. What happens ? does rails or whatver block till all five have returned the output - or do you use something like ESI ... how are the microservices composed finally ?

<comment><USER13> Adopting a microservice architecture does nothing to define how you "render your output"\- the devil is still in the details, but that is why a microservice is so interesting and flexible.

The way you will tackle this will largely depend on many questions like what services are safe to be exposed publicly, what services are dependant on other services, do you have a public API?

For example, you could have a public facing API on each service, or endpoints that render HTML templates. The services may or may not talk amongst themselves, either via the same public API, or a private one. If you make a request to one of the services, and that service needs to make a request to another service to generate the response, you've got to make a call on whether you want a blocking or non-blocking approach. Consider:

1) Blocking until the other services have responded

2) Pinging the server to check when it's done

3) Using web sockets

4) Whatever the hell else you can think of

Alternatively, you might want not want to expose your services publicly, and choose to have a single service that talks to the services on the clients behalf, a middleman. Your client speaks to this service, and the service sends of various requests to the other services. But the problem still stands. To block, or not to block?

AFAIK some big names like Amazon, Spotify, (Twitter?) have multiple public services. You may sometimes notice individual components on their [web] applications failing without bringing down the whole site, since the failures are isolated to the different services. Neat, huh?

</comment></comment></comment></comment><comment><USER14> Judging by the following statements: "we don't worry much about code quality", and "lots of moving parts isn't without its complexity", I'm just going to very politely wish him luck in his endeavors, and maybe make some popcorn.

</comment><comment><USER15> One of my previous employers had let each new incoming VP of engineering use whatever he wanted to build out new parts of the app. With the high turnover rate they had, the app turned into the worst Frankenapp piece of crap imaginable. Significant portions of the app were built in php, java, python, javascript, perl, ruby, ruby on rails, mysql, sybase, and a few more I'm forgetting.

The result was that changing the title on the homepage took two weeks of manual regression testing and it took a new developer a minimum of two weeks to get a development instance up and running. I felt so sorry for the Ops guys, I can't even imagine how terrible it was for them. There was no one, ops or dev, that knew even 25% of how the whole system worked. It always felt like the leaning tower of pisa made toothpicks and popsicle sticks held together with bubble gum and boogers.

The cost to run that Rube Goldberg machine monstrosity ruined what could have been an amazingly profitable business and great place to work. I don't recommend it.

</comment><comment><USER16> > it was becoming incrementally larger and more complicated for new team > members. Because of this, the monolithic Django system was already proving a > headache to get quickly set up, running and understood by our new hires.

So, now you have thirty smaller services for each new hire to install and link together? I can all but guarantee that this particular problem is better solved with Vagrant and some orchestration scripts. Takes your install from a list of packages to a single "vagrant up" command.

</comment><comment><USER17> I've been a big fan of microservices for years. I believe that a good microservice has a lot in common with traditional Unix commands. And I find it funny that no one here has gone off on a tangent to talk about how horrible those are.

Unix's tools and good microservices have the following things in common:

1\. They are small 2\. They are loosely coupled 3\. Shared-nothing state 4\. They enforce standards for consuming and emitting data 5\. They enforce a single standard for piping data from one process to another.

That said, I strongly believe that this won't work for every class of problem. And while I may be putting words into Tom Watson's mouth here, I believe he would say the same. But hey, guess what? This WOULD work for quite a few problems!

Some of the sentiment in the comments here feel defensive and knee-jerk. And I don't understand why. Tom Watson isn't telling you that you should use microservices. He's only explaining why he's using it at Hubble. I'm pretty sure how it turns out is going to have no impact on anyone else here, except (obviously) his customers.

But I hope it succeeds. I think there's a lot we can learn by applying the lessons Unix taught us to web-scale utilities.

<comment><USER18> _1\. They are small 2. They are loosely coupled 3. Shared-nothing state 4. They enforce standards for consuming and emitting data 5. They enforce a single standard for piping data from one process to another._

This can all be done via libraries with clear APIs, with none of the deployment headache of a microservice.

</comment></comment><comment><USER19> Doesn't Django already encourage this type of design? Each Django project is composed of several installed 'apps'. Each app should be portable enough that it could be the only app in any project.

<comment><USER20> I have a large app in Django at my work. The thing is it doesn't make sense to split this into smaller apps (except for the shopping cart equivalent). It tracks the workflow of our organization, so all queries need to be related from the very start to the very end of the process. (Ok, not all queries, but a lot of them).

<comment><USER21> Yeah, you wouldn't really want to split a Django app across foreign key relationships unless you want to be doing your joins on the client side with REST API calls, which is more work than letting the ORM do it.

</comment></comment></comment><comment><USER22> > We don't worry too much about code quality as I believe that that is fixed > at the recruitment level. Good people write good code and, more importantly, > ship good products.

Good people make mistakes too. Having good tools to ensure code quality doesn't make it impossible to ship bad products, but it's definitely important.

<comment><AUTHOR> Not worrying too much doesn't mean not worrying at all! We still have tools in place to ensure silly mistakes aren't made or are at least rectified quickly. Just we don't expect 100% test coverage on every single feature or fix we ship.

This approach will probably change as we get larger but being a small development team means that it is fine for now.

<comment><USER22> Thanks for the clarification! This sounds quite a bit more reasonable. :)

</comment></comment></comment><comment><USER23> What about the headache of monitoring 10s of microservices, making sure they stay up and running and healthy?

I assume that REST or Thrift (or something similar) is the way most microservices talk to each other. What if the latency isn't acceptable?

I've thought about switching our architecture to microservices but these two potential issues are making me hesitate.

How important are these issues in practice?

<comment><AUTHOR> It depends on what you're building. For us, we haven't noticed any issues with latency just yet and there are plenty of steps you can take to optimise this down the line.

As for monitoring there are plenty of tools to do that. You have bigger problems if you expect your services to go down often.

<comment><USER23> _As for monitoring there are plenty of tools to do that. You have bigger problems if you expect your services to go down often._

Yes, even in your monolithic app, you probably used some tooling to monitor it. But now that single service being monitored has multiplied into 10-20 services being monitored.

Nobody expects their services to go down, but if you don't plan for it, then that means you haven't thought about high availability or disaster recovery enough.

</comment></comment></comment><comment><USER24> It's amazing how easily people swap "I can't see how to use this in the contexts I'm familiar with" to "it doesn't make any sense at all".

Being myself - just a few years ago - a long time strong proponent of tightly coupled monoliths, I can't believe how blind and foolish I was in my fundamentalist rejection of loosely coupled architectures.

Monoliths do just fine up to a certain level of structural complexity. Above that, asynchronous service-like architectures are the only viable way to go.

Microservices is an attempt to see if the services patterns work below that waterline, down to the function level. That's why I find microservices at least interesting.

At any rate, it's a cost/benefit balance game, not an ideology.

Edit: clarity.

</comment><comment><USER25> We had similar issue's. Our Designers couldn't design with that big Django app, so we split it up. Everything talks ReST to a cached AngularJS Client. We still have Authentication in Django and two of our Microservices are running with Django aswell. Some things were reimplemented in Golang, as we tried some new things out.

What people here are talking is mostly dumb, since Microservices are better in a lot of ways especially when it comes to multiple Developers. Currently my company struggled a lot with Code that got changed by two guys at the same time, which was hard to fix.

We had less unit tests than now, since they were too complicated at a certain time.

</comment><comment><USER26> Standardization is, generally, good for maintenance, learning curve and security, not always for retention (fun) though. Too much standardization is like the flip-side of too many one-offs: an extreme that can lead to unintended consequences. It's much easier to accrue technical debt and organizational bifurcation by having too many languages, with a big, painful shake out (technical debt repayment) into just a 2-3 (say Ruby|Python|Node & Go|Scala|Haskell|Erlang|C)... (I've seen this happen at a number of shops go through growing pains at scale).

Overall though, services should expose either a well/self-documented RESTful, zmq or similar API such that they can be rewritten in (your favorite whatever here). Being able to discover the API meta information automagically can be helpful for autogenerating clients.

The other aspect is that services have a risk budget: if the service is conventional and not as crucial, increase the experimentation. If the business/process model is risky/uncertain, use common, stable technologies.

(Gist: Pick from the toolbox, carefully... apply common-sense... Don't get stuck on perfect now or perfect waay later... Anticipate a little now to avoid pain of changing later.)

PS: _Enterprise Rails_ is a great read. It's safe to ignore the Rails bits, because the architecture bits are universal and excellent.

Update: RESTful API metadata formats [http://apiux.com/2013/04/09/rest- metadata-formats/](http://apiux.com/2013/04/09/rest-metadata-formats/) (and also [https://en.wikipedia.org/wiki/HATEOAS](https://en.wikipedia.org/wiki/HATEOAS) )

</comment><comment><USER21> Every time I see microservices, I think of Martin Fowler's First Law of Distributed Object Design: "Don't distribute your objects." [http://martinfowler.com/bliki/FirstLaw.html](http://martinfowler.com/bliki/FirstLaw.html)

Splitting your app into multiple apps that send each other HTTP requests or MQ messages seems likely to just make your app slower.

<comment><USER27> If speed is your only requirement, write the thing in assembly.

<comment><USER21> If speed is not a requirement, just write the thing in Django (or Rails)?

I'm just not compelled by the reasons the author gave for needing to switch from Django to microservices.

</comment></comment></comment><comment><USER28> Can I be the first to say that this is a terrible idea?

>We have a multitude of parts that each could easily be self contained as their own service. For example: Messaging, Search, Authentication, etc. These all have different requirements and focuses and therefore lend themselves better to different languages.

Yeah, not really. Python is not inherently less suitable for authentication than, say, Java. Both languages are designed for general purpose programming. The only real drawback to python is that it is relatively slow and this isn't even likely to be an issue at all if you are using django (you'll most likely bottleneck on I/O).

>Also, looking at our roadmap, we have lots of sprints and projects coming up that could be implemented in their own silos. By splitting these into services this allows us to quickly test and iterate without worrying about the rest of our product.

And splitting them into separate libraries is not sufficient because?

>Whereas in a monolithic system these services are bundled together and can create a spaghetti mess of workarounds and packages.

Newsflash: you're MORE likely to make a spaghetti mess of workarounds if you use a microservices architecture because of the impedance mismatch between API layers. You'll have to create a representation of, say, a user object on both sides of the microservice divide and write code to serialize it and deserialize it. Hello massive code repetition and obscure bugs.

>Having been a dev team of 1 for a long time I'd never experienced the headache of installing all the dependencies required by our Django system. It never really occurred to me that as I installed more packages, it was becoming incrementally larger and more complicated for new team members.

If you think your headache is bad with django (which has consistent opinions - e.g. on how templates should work - that makes it possible for modules to work together), get ready for a nightmare when you start using a hodgepodge of different systems written in different languages.

>We don't worry too much about code quality

This has officially moved this blog post from bad idea to outright parody.

>However, most of the cons are part and parcel with programming.

Here's a small laundry list of the exciting issues you'll now get to deal with:

* Writing serializers and deserializers for your objects so they can be passed from one service to another. And debugging them!

* Babysitting all the new services you will need. You'll need to keep them up and running, monitor them, have a backup plan for all of them going down and lots of lovely extra error conditions.

* The headache of trying to figure out how to scale your network of microservices - probably meaning lots of time configuring load balancers.

And much, much more.

<comment><USER29> This is exact my thought as well.

If OP is more worried about maintenance of project, Django gives foundation to build upon with sane conventions.

Anyone who reads few pages of Django Docs should be able to pick up quickly.

PS. I happen to currently maintain project written by other people with no docs.

</comment></comment><comment><USER30> Adding packages doesn't make it harder to onboard new developers. Tools like virtualenv handle this for you.

</comment><comment><USER31> make sure to document well. When you're scaling up a team and moving from a coupled code base to independent codebases a good amount of assumption happens, especially around how mature each codebase is.

</comment><comment><USER32> Fixed 500px width...

</comment><comment><USER33> > For example: Messaging, Search, Authentication, etc. These all have > different requirements and focuses and therefore lend themselves better to > different languages.

What?

Every single one of those is a solved problem that has bindings to most major languages. Why in the world would you switch languages for an Auth mechanism (for example)?

</comment><comment><USER34> > Having been a dev team of 1 for a long time I'd never experienced the > headache of installing all the dependencies required by our Django system. > It never really occurred to me that as I installed more packages, it was > becoming incrementally larger and more complicated for new team members. > Because of this, the monolithic Django system was already proving a headache > to get quickly set up, running and understood by our new hires. Splitting it > up into more digestible chunks (services) therefore should allow us to scale > the team a lot quicker this year and beyond.

Yet, the dynamic language community constantly laughs at Java developers and their high overhead dependency management solutions, which just happen to have these kinds of problems solved since more than a decade.

Pathetic.

<comment><USER35> I don't believe he's talking about _code_ dependencies but rather things like LDAP, mySQL, MongoDB, etc which Java dependency management tools don't solve either. Managing code dependencies is solved in Python (as it is in most dynamic languages) using pip and virtual environments.

<comment><USER36> IME, encouraging people to only run part of the system results in a more fragile environment, and devs who can't fix problems in the wrong part of the system or change boundaries that were put in the wrong place. Everyone should be encouraged to be full-stack; specializing on one part or the other is ok, but you should be able to chase things into other components where necessary.

From the talk of "packages" I think the original _was_ talking about code dependencies. But it's worth saying that you can manage external dependencies the same way, with something like puppet.

<comment><USER35> I wasn't trying to advocate only running part of the system.

Of course you can use things like puppet, but the comment I was replying to was saying these were solved problems in the Java world for more than a decade which isn't exactly true.</comment></comment></comment></comment>


Why You Should Never Pay For Online Dating - <AUTHOR> http://blog.okcupid.com/index.php/page/6/ <comment><USER2> The folks at OKCupid are absolutely amazing data-story tellers. I've thought about doing a dating startup (w/ some new & unique features), but these amazing folks at OKCupid make me think my time would be better spent elsewhere.

<comment><USER3> Agreed. That's the most fun I've ever had reading statistics.

<comment><USER4> Their statistics cover a much more engaging domain than most.

</comment></comment></comment><comment><USER5> I recently signed up for eharmony. I was under the impression my 'message' to someone was an invite for them to talk back without paying.

That actually makes me feel slightly better. I have much, much higher success rates (and a much lower sample size) of approaching women 'IRL' as opposed to even getting a reply to a message on a dating site.

<comment><USER6> The benefit of the IRL approach is that it gives you an immediate opportunity to show positive qualities which don't always carry over very well into a dating website profile -- and you can leverage any physical attraction right off the bat.

See, the thing about dating sites is: women are in demand, men are not. When you're in a superior bargaining position, it's a lot easier to be picky. So women don't give a second thought about discarding profiles for even the most superficial reasons. Interacting in person gives you a chance to cut through that and sell your good qualities without having to pass a bunch of filters first.

</comment></comment><comment><USER7> It is quite ironic how OKCupid uses dating sites own stats to show how bad they are, using only simple math.

"It turns out you are 12.4 times more likely to get married this year if you don't subscribe to Match.com."

Wow, this was a sobering wake up call about dating sites.

"That is, a man can expect a reply to 1 in every 100 messages he sends..."

I shall pass it along to a friend who recently started using one, I can easily imagine what it would feel like to get a 99% rejection rate.

<comment><USER8> _"It turns out you are 12.4 times more likely to get married this year if you don't subscribe to Match.com."_

Also, people in hospitals die more often than people not in hospitals.

<comment><USER7> Indeed there is some trickery with the cause and effect of this statistic, but still 12.4 is big!

<comment><USER9> Let's assume that people generally date about 6 months before deciding to get married and let's assume that the average engagement is another 6 months. Given that, there is something wrong if you are signed up for one of these websites and get married in the same year. 12.4 is small.

</comment></comment></comment></comment><comment><USER10> OkCupid doesn't realize that folks who pay for dating sites are those who are serious about finding a long term relationship. okcupid, pof among others are filled with spam and folks who sign up just for fun. I was working on a dating site and may get back into coding it once I find some time. I've asked friends who use such sites and all of them said they would definitely pay. Some of them signed up for POF and refuse to use the service due the ugly gui or the fact that messages are met with auto replies.

<comment><USER11> POF is trash. I would agree.

However, almost 2 years ago I was suggested OkCupid by a hacker friend, and now I'm engaged to the woman of my dreams.

If OkCupid wants a personal success story, you know where to find me.

<comment><USER12> Exactly the same story here. I knew one of the OkCupid employees from IRC and they encouraged me to sign up to check out their matching algorithm work, and two years later I am still with a girl I met on there and very happy.

</comment></comment></comment><comment><USER13> When someone is so exasperated / desperate that they are willing to pay real money to meet somebody - their level of motivation to get married is a factor or more above non payers, that's really what you're paying for.

</comment><comment><USER14> I ended up just skimming it.

The first problem I saw is that they think they fact that the average profile only lasts 6.5 months is a -bad- thing.

When you have a relationship, you don't NEED a dating site. This means people either find a match or give up in an average of 6.5 months.

The second thing I noticed was that they are very down on the dead profiles. I haven't used e-harmony, but I suspect there's a way to tell when the person last used the site. Simply don't message people who haven't logged in for months and you won't have to to worry about it.

Much more useful is the fact that they get 12-15k new customers daily. In 6.5 months, that's a LOT of people to look through. (Yeah, they mostly won't be in your area, but most of the dead accounts won't be, either.)

<comment><USER5> There is not a way to tell when someone has last used the site with eharmony. At least not immediately.

I live in Vermont and there were like ~50 women within 60 miles within 5 years of my age on either side that showed up as 'matches' for me to view/message.

If I go another 35~ miles to montreal, there are approximately infinite women to view/message.

If I expand my search to world-wide it's exactly infinite.

</comment></comment><comment><USER15> Anecdotal counterpoint: I know of at least 2 instances of people who have met on eHarmony, via paid accounts, and have proceeded to end up in very solid relationships.

I know no such success stories with OKCupid.

<comment><USER16> I'm one. Been together 14 months, today. Recently, I joked "we should film a 'success story' commercial for OkCupid." :)

<comment><USER11> Make that two.

<comment><USER17> And three -- I met two very good friends and my wife (just had our first anniversary) through OKCupid.

<comment><USER11> I've seen enough OKCupid success stories on this thread alone I say they contact us for some free PR :)

</comment></comment></comment></comment></comment><comment><USER18> So what's Ok Cupid's marriage data?

</comment><comment><USER19> Of course they would say that - they are their competitors.

<comment><USER20> I agree with your sentiment that you should consider the motivations of the author (in any writing really), but it seems like they've done a pretty fair job of analyzing the data.

I think the 12.4x marriage rate is slightly misleading, because if you don't use a dating site then presumably you don't have as much trouble meeting potential partners, and thus are more likely to get married anyway.

But they did round several figures to benefit the match.com, and the statistic is impressive regardless.

</comment></comment><comment><USER21> There are more reasons that speak against dating sites in general. I didn't know OKCupid, so I just spent the last hour trying it out ;-) Here's the deal:

Everybody, really everybody who's a member has something seriously wrong with them. Sometimes, it takes a while to figure out but I couldn't find ONE compatible person (the experience was similar with other dating sites I tried in the past). I'm certainly no exception myself: I'm fat and ugly, and this is no self-deprecating crap, I mean it. And the girls on there are all either fat and ugly as well, or they're religious fanatics, gold diggers, trolls, creepy athlete stalkers or other kinds of groupies, future axe murderers, offensive and off-putting in their profile text, not looking for anyone right now, or (the funniest kind) their profile is one big stream of complaints about how everybody wants her sooooo much and would people please stop sending her those yucky messages already.

Hey, I might get nothing in real life, but at least RL is not as degrading as working the fruitless treadmills that are dating sites. Interesting and hot people can get dates anytime and anywhere, no online presence needed. The rest of us are just screwed.

<comment><USER22> Your notion of everyone having 'something seriously wrong with them' holds true everywhere. It's a core tenet of what makes us human, it's not isolated to people on dating sites.

Have you never heard the phrase 'no one is perfect?'

<comment><USER21> I don't want to lose any more karma over this, but that isn't at all what I was talking about.</comment></comment></comment>


Worrying - <AUTHOR> https://www.onebigfluke.com/2018/01/worrying.html <comment><USER2> > My approach is to ask them to "worry on my behalf" about the goal. Worrying > is anticipating problems before they happen. Worrying is not taking for > granted that everything will continue as planned. Worrying is finding and > fixing bugs before anyone else notices. Worrying is being pessimistic about > the quality of our codebase and the stability of our infrastructure. > Worrying is identifying and mitigating risks in advance. Worrying is > verifying the strength of relationships with more communication. Worrying on > my behalf is considering everything that might go wrong so I don't have to. > This is what I expect from people who take on responsibilities.

This isn't worrying, this is managing.

Don't tell people to worry. Worrying is detrimental to their health. If I can't do something about something right now, there's no point thinking about it. However, if I can do something, there's absolutely no reason to worry about it, just do it.</comment>


How Gmail's New Inbox Is Affecting Open Rates - <AUTHOR> http://blog.mailchimp.com/how-gmails-new-inbox-is-affecting-open-rates/ <comment><USER2> For some reason, this paragraph irked me more than it should have:

       If the subscriber has tabs but they didn't opt
       to include the Promotions tab, Gmail will deliver
       to Primary instead. That's good news. Other than
       that, we're definitely testing the new inbox and
       trying to figure out how it works. My sense is that
       Gmail wants all marketing email to go to the
       Promotions tab. Even if we did find a tricky way
       into the Primary tab, they're smart over there,
       and they'd more than likely address any reasonable
       workaround.

The Promotions tab is there _so I don 't have to see your emails_. The fact that you straight-up claim to try to bypass that makes me put you on the same level as the V1agra spammers in my mind.

I'll skim my Promotions tab when I want to. Stay out of my primary inbox.

<comment><USER3> A lot of people think that their special snowflake of a spam is the one that users actually want to see. These people deserve to be tasered in the mouth repeatedly, but sadly that hasn't happened yet.

<comment><USER4> I don't understand this attitude; every email sent through services like MailChimp contains an explicit and obvious unsubscribe link, and their policies regarding unsolicited email are pretty strict.

If you don't want to receive these emails, then unsubscribe - or, better yet, don't subscribe in the first place.

This new feature seems excruciatingly pointless anyway. I want all of my emails to arrive into my inbox, with the exception of actual unsolicited spam. If I need to filter them, I can do it myself - I suppose the feature may be useful for Gmail users who aren't comfortable doing this. At least I can disable the new inbox or continue using IMAP for now.

<comment><USER5> Just because it comes from Mailchimp and/or includes an obvious unsubscribe link doesn't mean it's not spam. There are countless sites whose default behaviour goes like this:

* require an email address to create an account to use their service

* without stating this, automatically assume that they now have permission to send you whatever email they want - admin emails, special offers, partner promotions etc

* assume that because they provide an unsubscribe link, those emails are automatically not spam.

It's those sites which I'm really glad Gmail automatically filters them out. Providing an email address because that's a requirement to have an account is not the same thing as giving approval to receive all your marketing and promotion spam.

<comment><USER6> > Just because it comes from Mailchimp and/or includes an obvious unsubscribe > link doesn't mean it's not spam.

No, but it's VASTLY more likely not to be (if the unsubscribe link is real and working).

> There are countless sites whose default behaviour goes like this:

> * require an email address to create an account to use their service

> * without stating this, automatically assume that they now have permission > to send you whatever email they want - admin emails, special offers, partner > promotions etc > * assume that because they provide an unsubscribe link, > those emails are automatically not spam. > It's those sites which I'm really > glad Gmail automatically filters them out. Providing an email address > because that's a requirement to have an account is not the same thing as > giving approval to receive all your marketing and promotion spam.

Well, if it's in their TOS (and on most the sites it probably is), then it probably _is_ okay, and you have nobody to blame but yourself (as do we all). The current state isn't optimal, but it's what the public wanted. The race to low cost/free services subsidized by advertising has led to this.

If you really want to not be contacted for a promotion from a company, put your money where your mouth is and choose services where their business plan doesn't _require_ pestering you to use them more.

 _edited to lighten the accusatory stance of "blame", as it didn't convey my real intent accurately_

<comment><USER7> _Well, if it 's in their TOS (and on most the sites it probably is), then it probably is okay_

Just because its hidden in the fine print instead of explicitly disclosed at the point of collecting the email address does not make it "okay."

It might make it legal but that's not at all the same thing - a defense that falls back on legality means they have an adversarial relationship with that customer which generally means they've lost any future business from them. That's the last place a smart company wants their customer relationship to end up.

<comment><USER8> Yes. If anything that is legal is "okay," then there is no point in discussing Gmail's new inbox because that is obviously "okay" too.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> To clarify what an 'open' is in terms of this post, it's when the recipient opens an email and has remote images load or clicks a trackable link. That's the only way you can be sure an email has been opened. If you open an email but don't load images and don't click links, then it hasn't been 'opened' in the eyes of the sender. So, for instance, folks who open and delete promotional mailings without loading images don't count as opening those emails. Basically 'open' doesn't mean what you think it means in terms of the way you use your email client.

The same way 'delivered' doesn't mean what you'd think it means. You, as a user, would think it means delivered to your inbox. It doesn't. It means it was delivered to the mail server. At that point, it could go in your inbox, your 'promotions' tab in gmail, your junk/spam folder, or be automatically deleted using a set of rules on your server/email client (bayesian, rbls, etc). So, when email sending providers talk about delivery rates, that's what they really mean. They have no idea if even the subject of the email was even seen by the recipient unless that recipient either opens the email and loads the remote images or clicks on a trackable link.

<comment> D-Coder True, but probably not relevant to this artice. The "read" vs "loaded images/clicked link" ratio is probably the same before and after, so its exact meaning isn't important. But thanks for the clarification.

<comment><USER10> It does call into question the representativity of the findings, though.

For example, people who always show external images are overrepresented; the influence of the new design on open rates of other users is not predicted reliably.

Or, from another angle, I am more likely to load external images in emails that are important to me. The influence of the new design on the open rate of emails that are important to me (which get counted) is probably different from the influence of the new design on the open rate of emails that are NOT important to me (and that don't get counted even if I open them).

</comment></comment></comment><comment><USER11> "For marketers who are trying to establish a personal relationship with their customers..."

Isn't that kind of an oxymoron? How can the relationship be "personal" when one side of it (the marketer's side) is really just algorithmically-generated (and by that I do not necessarily mean "computer-generated") and the conversation is one-way?

<comment><USER12> While I would generally agere with you completely, there _are_ marketers with whom I have a very personal relationship.

What sticks out to me (because they sent me an email today discussing gmail's new layout and how to ensure I kept getting their emails) is my comic shop. They go through effort to know what I like, what to recommend to me, etc., etc., and are super friendly to boot (not affiliated plug, Third Eye Comics in Annapolis are AWESOME).

I genuinely want the emails they send me, even their most basic one-way emails provide me active value, and the relationship does transcend a more traditional marketing relationship, like the one I have with Amazon.

In short, it would not surprise me to know that there are other businesses that share more personal relationships with their customers than the merchant- customer model.

<comment><USER13> _I genuinely want the emails they send me, even their most basic one-way emails provide me active value, and the relationship does transcend a more traditional marketing relationship, like the one I have with Amazon._

If you drag those messages from Promotions to Primary, Gmail will ask you if you want to do the same thing for all messages from that sender.

<comment><USER12> Yes. That's exactly what they emailed me to suggest, but I haven't gotten the new layout yet for it to matter.

</comment></comment></comment></comment><comment><USER14> Hacker News audience, developers or/and internet workers population in general are very sensitive to commercial newsletters. There are lots of comments that read "commercial newsletters = spam".

But reality is that for many online businesses email is the primary sales channel or a very important one. Lots of commercial newsletters are sent, but they main reason for this is because they work. Plain and simple. Lots of "normal" people (not too tech savy that will never hear about Hacker News in their whole lives) use commercial email as on their primary ways of ecommerce browsing. Just as setting up a beatiful and atractive front shop one hundred years ago made a difference in your bottom line, email is an element of crucial importance. Furthermore, lots of ecommerce companies have invested tons of money in developing this channel. Hey, maybe your salary is paid by one of this ecommerce giants! So three things:

1) Commercial email works. Many people don't bother receiving lots of commercial email. In fact, they love it. Google knows this, so:

2) one of the main reasons for Google making this change is to create an effective channel to deliver __their own __ad impressions in the format that people loves and use. But,

3) in doing so they may be invading a space in which lots of companies have invested a lot (and those same companies surely have already invested in other Google products).

Its a similar pattern with SERPs: you invested in SEO but now the first page is only made up of Google products or paid positions.

<comment><USER15> Commercial newsletters are not a problem - and having tabs for Promotions and Updates made them more friendly.

This way, users can review and maybe-read the newsletters once a week, instead of having them mixed with actually urgent emails from their family and "server is down" alerts.

</comment></comment><comment><USER16> "The word on the street is that business owners and marketers are worried about this new layout, and I get that. You want your email above the fold, on the cover, with a huge headline. You want to stand out to your customer, and instead you're on the Promotions page with all the other ads."

This blog post is like an ad for GMail. Sounds like the tabs feature works very effectively.

</comment><comment><USER17> I really liked the idea of the new inbox at first but right now its overzealousness with the Promotions tab is tempting me to merge everything back into Primary. Daily VC news emails are not promotions; digests of roguelike updates are not promotions; emails from my grandmother to try a brownie recipe aren't promotions (well, I guess they sorta are.)

(Yes, you can train it to send emails from firstname.lastname@example.com to primary by default, but at that point what advantage is the split inbox offering me?)

<comment> k-mcgrady Just drag your daily VC emails into the primary tab and they should got here from now on. Not really any training involved, it only takes a few seconds.

</comment></comment><comment><USER18> They should be _glad_ for the Promotions tab. Now that promotional emails aren't gumming up my primary inbox, I'm much less likely to unsubscribe from them. I don't mind having coupons for stores I rarely visit, or newsletters for projects I'm vaguely interested in, since I don't have to deal with them every time I open my mail.

<comment><USER19> I see where you're coming from, but I sure would have preferred if GMail asked me if this was something I wanted rather than just forcing it on me.

<comment><USER18> "Forcing" is a bit much. When it is rolled out to a user, there is a popup asking which tabs the user wants to enable. It's technically opt-out, but it's literally one click (no digging through menus) to say "I don't want this."

<comment><USER19> Now I wish I took a screenshot, but I do not recall any "I don't want this" button when it hit my inbox.

<comment><USER20> "Go ahead" was a button, and "I don't want this" was a plain link beside it.

</comment></comment></comment></comment></comment><comment><USER21> Gmail new tabs is an incredibly cool feature for people receiving tons of mails. The Gmail team realized that there is spam that's not spam, and is the promotions email, it is awesome to see them away from my inbox...

<comment><USER22> > The Gmail team realized that there is spam that's not spam

That is a very good way to put it, and is just how I feel. It's too bad they were criticized that the tab move was just all about more effective advertising (it may be a little bit true, but doesn't negate the fact that this is a really good innovation on the email management front).

<comment><USER23> I hope the backlash isn't enough to force them to change it. I think people misrepresented the (mostly positive) changes to get some google hate blog views.

</comment></comment></comment><comment><USER24> Will the issue of arriving in the Promotions and Updates tab affect transactional emails sent through MailChimp (and comparable competitors)?

For example, if I'm sending a "Here's your password reset email" via MailChimp, will I now have to worry about it not just potentially going into spam, but also under some tab that the user may not look.

I'm only really concerned about the transactional email, whilst we send list mail too I think it's reasonable that is classified however the user and the user client deems fit (if they wish to receive that at all). But when it comes to an email that the user has explicitly requested and expects immediately, not having it go straight to their visible and main inbox is an issue.

<comment><USER25> Thus far we have seen our transactional emails also going to Promotions, as well as our standard marketing emails.

This could be both good and bad. Bad because as you mention, the user won't see it immediately even if they requested it. Good because if the user actually uses and likes your service, they may start to take those transactional emails to their Priority inbox which could train it to also respect the marketing type e-mails as Priority as well. Again, this would only happen if the user actually likes your service.

<comment><USER26> I'm using Mandrill to send out my transactional email. I'm hoping this change doesn't force me to get back into the mail server business - that is something I gladly pay to outsource.

<comment><USER24> Exactly my concern.

Transactional email deliverability is more important than marketing emails to me. If needs must, I'll host my own again... but I really like not managing email servers and fighting blacklists.

</comment></comment></comment></comment><comment><USER27> This change is going to be brutal for anyone with a newsletter.

No implication that this is the reason for the change, but it probably means more spending on traditional web advertising.

<comment><USER28> So far I've found it only affecting sales-type newsletters, which is interesting. Adorama's newsletter (which I could've sworn I opted out of) goes to Promotions, but the ACM newsletter still goes to Inbox.

</comment></comment><comment><USER29>
        "I've heard a lot of people asking how they can get out of
        the Promotions tab and into the Primary tab."

You should have told them that if they are in the promotions tab then that is probably where they should be. Sending promotional bulk emails and wanting to be in the primary tab is antithesis to what customers want. Being a promotional email in the primary tab I would imagine would be more likely to be marked as spam.

<comment><USER30> I'm seeing transactional mail like signup confirmations and password resets in the promotions tab. There are lots of lists I subscribe to that are "bulk" but not promotional as well. MailChimp has over 3 million users, and zero of them are affiliate marketers. Not all of their users' mail belongs in a promotions tab.

<comment><USER31> Indeed. To give one example, I run a weekly newsletter with JavaScript tips. That probably shouldn't be categorized as Promotions. Perhaps Social or Forums instead?

<comment><USER32> I don't see any way of getting around this that isn't just rife for abuse. I guess/hope that Gmail learns from user behavior, so if enough of them start moving the mail to the Forums list (which is what I think it should be, Social Updates implies some personal update from Facebook/Twitter/G+, not newsletters), it would automatically filter there instead.

EDIT: Also, many users might feel like Promos is the right tab. For example, Weight Watchers emails me recipes, which is a bit like a developer getting Javascript tips. This also goes in Promos, and that seems like the right place for it, even though it's useful/actionable information.

</comment></comment></comment></comment><comment><USER33> Am I the only person that had a "Promotions" filter added to their Gmail ages ago? I've also not got the new tabs, either. I'm wondering if I am in some lost zone.

<comment><USER34> Settings -> Configure Inbox -> Save

That turned it on for me.

<comment><USER35> Just tried that and now I've got tabs in GMail. Thanks for the tip.

</comment></comment></comment><comment><USER36> I don't think this indicates a Google problem.

They're lucky Google even deliver them to any tab - based on their own figures it's almost a 90% chance of their email being binned by end users (OK, not opened but that's pretty much the same thing). On systems I administer that's way above the threshold I'd consider for blacklist/auto-reject.

Without trying to disparage their business, Mailchimp and associated 'services' are rarely providing 'quality' email in my experience and I don't get customers calling me up asking me to make sure such emails come through. Quite the opposite.

It's hard in the mass email business because most people (e.g. almost 90% it seems) think the emails are crap and don't want them or open them. If that's upsetting then don't complain. You need to look for a different business where you'll feel more loved and appreciated. Mass email is not it and never will be.

<comment><USER9> It's worth noting that the open rates only apply when an image is loaded from the remote server or the recipient clicks a trackable link (if the emailing system is setup properly). When a recipient opens and reads an email without showing the images or clicking a link, it doesn't count as an open as the sender has no way to track that.

</comment></comment><comment><USER37> I'm glad that Open Rates are going down.

I don't want your sales-funnel emails full of doublespeak and marketing buzzwords.

You think your email is full of helpful info about your product but it's not. It's just spam.

<comment><USER38> Except that's not the only use for mass e-mail.

I have over 120,000 developers who subscribe to my e-mail newsletters and I suspect most subscribers would not consider them "Promotions." Hopefully those who care to read every week will drag them back into the main inbox but I imagine some will fall by the wayside. (Not that I'm panicking, I'm not noticing much of a/any drop in open rates at all.)

</comment></comment><comment><USER39> I used to "open" marketing emails for fractions of a second while browsing my inbox with keyboard shortcuts. I go to the next email, and if it's a marketing email, I move to the next email.

But with the Promotions tab, I check the titles, and if they're not interesting, I mark them together as read without opening it.

So, my reading behaviour hasn't changed even though tracking my open rate with tracking pixels will now show different results. If it's an interesting email, I'll read it. If not, I won't.

<comment><USER9> If you didn't have 'show remote images' on, there's no difference as it wouldn't count as an open. And it's off by default for all senders in gmail and every other worthwhile webmail provider.

</comment></comment><comment><USER40> Internet marketers are panicking right now. I've received a dozen of e-mails to teach me how to bring their "not promotions" e-mails back to my primary inbox...Hate it or love it but I think Microsoft Yahoo Apple are going to follow that trend too... Of course the system is not perfect yet but it is something regular people are going to love...at least my mom love it. I have 5 tabs up and running.I have more control over my inbox now. I can understand why internet marketers are mad because it is a new ball game to be next to Facebook updates versus in a box alone with other promotion e-mails... In the long term your brand your goodwill are your only and best weapons...Open Rates are just one metric because you can have one open and 5 conversions versus 5 opens and 0 conversions... the main difference here could be that one open leads to 10 shares on Facebook....This new UX is a non issue...it is really time to disrupt the e-mail system

</comment><comment><USER41> "I've messed around with a ton of different content and header configurations, and anything that looks like it came from an ESP (has a list-unsubscribe header, unsubscribe links in the content, etc…) goes to either the Promotions tab or the Updates tab."

This is actually a really important UX/CX thing to keep in mind when creating newsletters or other emailed publications with actual content as the product. My Pycoder's Weekly ended up in Promotions tab. Since I don't look at it every day, my initial thought was I didn't receive it.

In order to have it show up in Primary, I had to create a rule on the sender. We'll see if this actually works.

Granted, Pycoder's Weekly is ad-supported, but that's what I opted in for.

For others creating similar subscriptions, it's probably worthwhile to mention this gmail behavior in an FAQ or some other instructions.

<comment><USER42> You can also just drag the message over to primary and gmail will learn that it's a primary message.

</comment></comment><comment><USER43> It's definitely affecting how I open my emails. Promotions just get straight deleted.

<comment><USER44> The tabs feature is a godsend. It's definitely affecting my email behavior and making me a happier person. Instead of deleting individual marketing emails or sometimes trying to unsubscribe, I can now just ignore them completely!

<comment><USER3> But how much confidence do you have in the classification? I find myself polling all the tabs so I don't miss anything important. An example: my Amazon seller notifications go the the Promotions tab.

<comment><USER45> just drag the email into the primary tab and it will always put it there

<comment><USER3> Sure, and then I have to keep polling the Promotions tab to find out if there's any new stuff being classified in there.

</comment></comment></comment></comment></comment><comment> jack-r-abbit The first thing I did when I got the new gmail tabs was uncheck them. I don't want my mail tabbed. But thanks for asking. :)

</comment><comment><USER46> Something about their analysis just doesn't sound right.

"I dug deep into our database and pulled every delivery to Gmail for the past year and half. That amounts to 12.5 billion emails".

Then he says

"As you might suspect, Gmail opens do follow these hourly, weekly, and seasonal trends, but on the whole they remain fairly steady. With that settled, I trimmed my data to a lean 6 weeks around the introduction of tabs. That's about 1.5 billion emails, which is plenty of records for a good analysis."

So, 1.5 years = 12.5B Gmail emails

But last 6 weeks = 1.5B Gmail emails

That doesn't sound right.

Unless MailChimp is on some type of unbelievable (true) exponential growth rate in the past few months.

Edit: typo

<comment><USER47> 1.5 years is 78 weeks. 12.5B emails / 78 weeks ~ 160 million emails a week.

6 weeks * 160 million ~ 960 million emails.

So the last 6 weeks is 156% of the average. That seems like good growth, not unbelievable growth.

</comment></comment><comment><USER48> As for the marketers... and you can quote me on this... "Fuck 'em" .. The issue is that you aren't the only ones vying for our attention... I get so much crap to wade through I can't keep up. What really gets me is the frequency, I see so many marketing emails from places I actually do business with, that legitimate and important emails slip through the cracks.

I have an acquaintance who had an online account compromised, his shipping address changed, and stuff ordered... He didn't notice the change/receipt emails because of all the garbage emails he receives from said vendor.

It's a serious problem. I feel the same way about technical recruiters for the most part now too... I get maybe 3-5 emails a day, and 3/4 are either out of state, and/or well below what I make now... I'm not interested in either generally speaking. That doesn't even count all the "connect with me on linked in" requests from people I don't know, and the emails that go with them.

Hell, even twitter is in on it all now.

</comment><comment><USER49> Google doesn't get paid for emailed ads. They'd rather you were paying _them_ for ads that masquerade as genuine emails.

<comment><USER50> But they both are displayed in the promotions tab so how does paying for an ad in the promotions tab that looks like a email solve the problem of a marketing email being displayed in the promotions tab?

</comment></comment><comment><USER51> This makes me very happy to not be in the email marketing business anymore.

</comment><comment> martin-adams I'm really not surprised it's bringing down open rates. I find I'm ignoring far more emails in my inbox as they are out of view and in the promotions tab.

Ultimately, if I don't open the email, the content isn't that useful. Before I would quickly open and delete when done, just to keep my inbox clean.

Does it mean I pay less attention to the marketing messages? No.

</comment><comment><USER52> Off topic, but does anyone else here think the UI for the new tabs is god- awful? I wish they could become custom labels, and be treated as such.

I feel like the fact that they're now explicitly tabs is a compromise that allows a marketer to still get the user's attention without filling up the "inbox" with what might be considered spam.

<comment><USER53> Yes, the minute I saw it I disabled everything back to the old UI.

At home I use an IMAP client anyway.

</comment></comment><comment><USER54> _The word on the street is that business owners and marketers are worried about this new layout, and I get that. You want your email above the fold, on the cover, with a huge headline. You want to stand out to your customer, and instead you're on the Promotions page with all the other ads._

News flash: you don't own my inbox.

</comment><comment><USER55> Huh, before reading this article - I didn't know you could turn the tab interface off. I thought I'd try it, just so I would be able to nitpick and say "Hey! You think it's a choice for them, but it actually ain't!".

If you'd like to disable the tab interface in GMail, here's how you do it: Log on, click the gears in the top right corner - below your user profile icon. Select "Configure inbox" and de-select "Social" and "Promotions".

I first thought it was impossible to do this when I found this configuration page, because the first option is "greyed out" and unclickable.

This seems like the first time you're allowed to not eat the Gone Google Again-bullet - which is good for me as a user! Sometimes I really don't want to get your new feature or design.

</comment><comment><USER56> One big problem is that it's hitting event emails which tend to use similar email services for distribution. If an event has to be cancelled last minute or if there is some major changes and the announcement email gets missed it could easily cost someone a significant amount of money.

</comment><comment><USER57> This is yet another reason why you need to look past e-mail for personalized communication with your customers. Personalized messaging inside your web site or app is much more effective for certain use cases.

Are you e-mailing your users to tell them about a new feature? Why not show them an in-app message instead, when they are logged on and engaged? Are you e-mailing a custom offer to a certain segment of your user base? Show them the offer when they're on your site.

Obviously, if you are contacting users that are not visiting your site at all, then e-mail is still king.

Personally, I am glad to see Gmail implement this kind of separation so well.

Full disclosure/plug: I work for Evergage ([http://evergage.com](http://evergage.com)) and we provide this behavioral- driven in-app messaging.

<comment><USER58> The use case and purpose of email marketing is totally different from in-app messaging. Email drives return visits; in-app messaging drives conversions.

Edit to add analogy: it's like saying JCrew does not need to send catalogs because they have great signage in their stores.

<comment><USER57> Yes, they are fairly different, but there is a fair amount of crossover. Specifically, much of the crossover is there because the state of the art in marketing automation in e-mail is much higher than outside of it. It's much easier for a marketing person to work with an e-mail marketing automation system. Implementing targeted in-app messaging campaigns, on the other hand, typically requires development team cycles (not with us though).

But I'll run with your analogy. JCrew can send me a targeted 20% off coupon, for example because I am a store cardholder or it's my birthday month. However, the purpose of that coupon is not solely to drive return visits. I might frequently stop by a JCrew while in a mall to look at merchandise, but I might be much more likely to convert if I knew I had a coupon.

However, when I am actually at JCrew in a mall, JCrew won't have signage with my coupon and won't recognize it's my birthday. It sure would be nice though.

</comment></comment></comment><comment><USER59> As a data scientist, the lack of error bars hurts me deep inside (i.e. are these statistically significant drops?)

Nevertheless very insightful, and I appreciate the use of data as opposed to many of the anecdotal reviews of Gmail's new inbox swirling around HN these days.

</comment><comment><USER60> I believe that this can be very useful for the mainstream user.

It is however much much more useful for Google from a business perspective.

Lower openrates mean less eyeballs and revenue, which will in turn translate into more adwords and display placements. Obviously not directly, and probably not in most cases, but it should, even if it's only a few percent or less, translate into more revenue for Google. How much is anybody's guess.

If I were an E-Mail marketer or a big brand though, I'd be furious and try any other channels but Google's. In my eyes, it smells like Google using its market power to bully their own customers. They pulled a classic Facebook with this one ;)

</comment><comment><USER61> > For marketers who are trying to establish a personal relationship with their > customers, this change can be frustrating.

This, even without any further context, describes what 99% of Gmail users would consider an overwhelming positive.

</comment><comment><USER62> There is one point to understand. This greatly benefits Google as it allows to reduce the response rate of competing marketing products, and increase the response of their own. Not that they should care about being fair. Gmail is theirs. They can do as they please. People should understand that they will simply optimize for their benefit, not for the benefit of some other platform (in this case Mailchimp.

Want to increase your rates? Send your email to the user's facebook account. Those get read almost instantly.

</comment><comment><USER63> I think a lot of people were already using filters before these tabs came along; I know I was. All that junk and even stuff I did care to look at every once in a while is and will continue to skip my inbox and go into my filtered folders. In fact, the only good thing about the "new" tabs is that I don't have to click on the filter folders. Anyways, marketers should be selling things worth selling and not trying to find a workaround to get into our inbox.

</comment><comment><USER64> My theory is that the reason for Google implementing the Promotion tab is so that they can put ads into the INBOXs of people who use desktop and mobile clients. Doing it this way won't be too intrusive to people who use the web client, which already has a place for ads to be viewed.

</comment><comment><USER65> If you don't like it, go to Settings > Inbox > change the "Inbox type". I'm already back to the one tab model. I had some important emails in promotions tab, so I can't just ignore that tab.

<comment><USER32> Were they coming from different senders? Would moving the email and/or setting up a filter not fixed this? I'm wondering what you think of as being "important" that would have ended up there. The classification for me has been very good.

</comment></comment><comment><USER66> Interesting, but is it really true 'normal' open rates are also only 13%? Or is this how it's measured, e.g. only including people who click 'show images', and thus load the tracking pixels?

<comment><USER67> Typically the open rate is the combination of unique users who download images (along with the tracking pixel embedded) and unique users who click on tracked links from within the email.

</comment></comment><comment><USER68> In general, I think it would have been smart to offer tabs to high volume users. When I only have 10 new things, tabs are ... stupid.

(Amusingly it put an old girlfriend's "my new page is at" in promotions.)

<comment><USER69> I'm not really a high volume user (0 unread most of the time) but I have tons of tabs and filters. I really only want to be notified of a new email when it's from someone I personally know.

<comment><USER68> I'm not saying there should be no tab/filter options (I used filter/folder options before tabs arrived). I'm just suggesting sticking the 3 defaults on everyone was a bad idea. Just adding the "+" and directing to a how-to would have been IMO appropriate.

</comment></comment></comment><comment><USER70> I'm confused, tabs has been rolled out slowly across Gmail users. I know people with and without it still. SO how do they define a point of 'release'?

</comment><comment><USER71> What i find disturbing is the whole article revolves around trying to get spam back into the primary tab, exactly where no one wants it other than the sender

</comment><comment><USER72> Oh waaaaah, poor spammers are losing money.

</comment><comment><USER73> What new inbox? I have seen no change for months, and I view my gmail inbox on the web daily.

<comment><USER74> There is a new inbox header [1] in Gmail, which adds tabs for your normal inbox, social, promotions, etc.

[1] [http://mail.google.com/mail/help/intl/en- US/features.html](http://mail.google.com/mail/help/intl/en-US/features.html)

<comment><USER73> Weird that I haven't seen this, but I've been using exactly this label filtering system for years -- I literally have had a "Social" label since 2008.

(I added "Financial" and "Sales" labels later)

Edit: apparently it was turned on but not displaying any tabs. In the settings gear I found "Configure Inbox" where I disabled these.

</comment></comment></comment><comment><USER75> It would be way more valid to analyse click through rates than open rates.

</comment><comment><USER76> tl;dr Mass email "opens" have dropped from 13% to 12.25% (more or less, according to the chart), where "open" is according to MailChimp's definition/mechanism.

</comment><comment><USER77> You can remove the promotions tab..

</comment><comment><USER78> This is off-topic, but if people don't like ads, why don't they just use Gmail with POP3 or IMAP?

<comment><USER79> Because then there's basically no reason to use GMail, it has no value add without the UI.

<comment><USER80> Even without the UI, gmail is free email storage of fairly large capacity, which is also extremely reliable, accessible, fast, professionally-backed-up, and unlikely to go out of business any time soon...

</comment></comment></comment><comment><USER81> Keep in mind, correlation != causation.</comment>


I Accidentally Some Machine Learning – My Story of a Month of Learning Elixir - <AUTHOR> http://fredwu.me/post/147855522498/i-accidentally-some-machine-learning-my-story-of <comment><USER2> > About a month ago I was in-between jobs - I had two weeks to rest up, > recharge and get ready for my new job. So I thought, I should use those two > weeks to learn something new.

After this, people are still wondering why developers earn $100,000+ salaries.

<comment><USER3> I don't get it.

<comment><USER4> Developers get paid market price for their labor, right now employers pay them above median salary, some commenter on HN wants to point out a correlation between this particular developer's choice to spend their time to learn a new skill and their current market valuation suggesting that the latter follows from the former.

<comment><USER5> Agreed, welders for example spend a lot of their spare time working on side projects, learning new ways of welding, etc. Carpenters spend a lot of time on family and friends home projects. There is no correlation between a programmers willingness to learn and the median salary for the industry

<comment><USER6> There is. Programming is a non-linear field, while welding is a linear one, unless you become a successful welding-artist.

<comment><USER5> If you ask welders, there is definitely an art to it. Check out /r/welding sometime.

</comment></comment></comment></comment></comment></comment><comment><USER7> Why did Python get a bunch of mschine learning frameworks but ruby has little or nothing ? Was it because scientists just started to use Python more ?

<comment><USER8> It was a combination of:

1) The language was created by a researcher (Guido Van Rossum) at a research facility in the Netherlands [1]

2) Network effect - as more machine learning researchers and engineers in academia used it, the need for a language that could integrate with FORTRAN with similar performance came about, which lead to NumPy, SciPy, etc.

3) The language itself is pretty simple to grasp. There's multiple ways in Ruby itself to do something, while in Python there's at most one way to do something. Anecdotal - a lot of researchers I've worked with care more about the usability and ease of adoption of a language, compared to the expressivity.

[1] [https://en.wikipedia.org/wiki/Python_(programming_language)#...](https://en.wikipedia.org/wiki/Python_\(programming_language\)#History)

<comment><USER9> Not disagreeing with the relative simplicity of Python compared to Ruby, but the degree to which the Python community is adamant that there is always only one way to do something has always baffled me. What about `map` versus a list comprehension, or `glob` vs `os.path`? Obviously Python has pretty clear standards about what the correct way to do something in the language is, but I feel like the persistent claim that there's always exactly one way to do something can range from oversimplified, misleading, or just plain wrong.

<comment><USER10> Extreme pro-Python statements about "one way to do it" are usually made by relative newcomers who are caught up in their enthusiasm for purity. (This exuberance is natural, and is a big part of the language adoption cycle.) Extreme anti-Python statements about "one way to do it" are usually made by outsiders viewing Python through accounts given by enthusiastic newcomers. This exuberant-newcomers-vs-skeptical-outsiders dichotomy isn't representative of the actual Python culture, which is much more sensible and practical than all of this implies. If you go to PyCon and attend talks by long-time Python folks, you won't find them advocating anything like blind adherence to "one way to do it".

To get specific, the wording in PEP 20 is: "there should be one, and preferably only one, obvious way to do it". Note that the dominant idea here is that there should exist _some_ obvious way. It's merely _preferable_ that there be only one way. Again: this is sensible, but it's not good fodder for newcomers craving purity, or for detractors craving straw men.

PEP 20 itself is often elevated to religious levels of importance, as if it were a design document that served as a blueprint for the design of Python. It's absolutely not that; it was written by Tim Peters (not Guido!) fully eight years after Python's first release. Here's the original email that Tim sent to comp.lang.python on 4 June, 1999: [https://groups.google.com/d/msg/comp.lang.python/B_VxeTBClM0...](https://groups.google.com/d/msg/comp.lang.python/B_VxeTBClM0/L8W9KlsiriUJ). Note how he finishes: "If the answer to _any_ Python design issue isn't obvious after reading those -- well, I just give up <wink>." Tim is very particular about his winks, and that's not even a <0.5 wink> or a <0.9 wink>, but a full, unqualified <wink>.

To put all of those pieces together: (1) we have a short, tongue-in-cheek document written after-the-fact. (2) It's misinterpreted as a design document for an entire language and ecosystem. (3) A secondary portion of one of its points is misinterpreted to be the entirety of the point. (4) This is done by exuberant newcomers and skeptical detractors who don't accurately represent the Python culture as a whole. This is why you get the impression that the community is adamant about "one way to do it". It's a reasonable extrapolation from the visible evidence, but it's not true.

<comment><USER9> Thanks, that's a very clear and well thought out explanation. I'll make sure not to take the skeptical detracting too far in the future!

</comment></comment></comment></comment></comment><comment><USER11> Interestingly, i think most of your speed on Stemmer come from using String.replace_suffix, which use binary pattern matching instead of regex.

Nice learning :)

<comment><USER12> I wonder if the new regexp code in Ruby 2.4 would address some of that

<comment><AUTHOR> Author here. When I was benchmarking my library against a ruby one, I did actually try the ruby one on 2.4. Interesting findings are:

\- Switching from =~ to Regex.match? did not yield significant speed improvement

\- Without any changes though, 2.4.0-preview1 ran the stemming in 19s, compared to the 25s on 2.3.1.

The ruby stemmer I used is this one: [https://github.com/NeilNjae/porter2stemmer](https://github.com/NeilNjae/porter2stemmer)

</comment></comment></comment><comment><USER13> The headline is missing the word "Did" after "Accidentally", both on HN and on the post itself.

<comment><USER14> All your base are belong to us.

Sometimes typos lead to memes.

<comment><USER15> Sometimes memes lead to people learning incorrect grammar (as I beat down my former benevolent grammar dictator within).

</comment></comment></comment><comment><USER16> Does anybody know of a good benchmark between Elixer, GO and Scala?

<comment><USER17> Over a year ago, there was a benchmark of web frameworks. It compares the performance of frameworks written in Elixir, Go, Java, Node and Ruby.

[https://gist.github.com/omnibs/e5e72b31e6bd25caf39a](https://gist.github.com/omnibs/e5e72b31e6bd25caf39a)

<comment> david-given That's really interesting --- how come Elixir does so well? I thought that the BEAM VM was good for concurrency and reliable systems, but wasn't so great at raw number crunching compared to the JVM and compiled code?

<comment><USER18> it's web framework benchmark there is no number crunching</comment></comment></comment></comment>


Toyota to buy $1B stake in Grab - <AUTHOR> http://www.thehindu.com/business/Industry/toyota-pumps-1-bln-in-grab-in-auto-industrys-biggest-ride-hailing-bet/article24156807.ece <comment><AUTHOR> Please remove if it is a repost. Reminds me of this Steve Yegge post: Why I left Google to join Grab

[https://firstname.lastname@example.com/why-i-left-google-to-join- gr...](https://email@example.com/why-i-left-google-to-join- grab-86dfffc0be84)</comment>


A Modified ElGamal for Passwords Only - <AUTHOR> https://kring.co.uk/2017/09/a-modified-elgamal-for-passwords-only/ <comment><USER2> While I can write down D-H key exchange and ElGamal without thinking too hard, there's no guarantee when I do so that I will be using the same letters for the same components as you have here. So I'd have to work out the bijection between the letter you've used and the letters I've used, and it all becomes a lot of work, and just obscures the point.

Why don't you (assuming you're the author, based on your username and the author's name) either include the definition, or at least give a pointer to a definition that uses the notation you are using?

The result of _not_ doing so is that I've read this and thought: That will be a _lot_ of work to interpret.

Closed it and moved on.</comment>


Why Your Phone Can't Really Replace Your Credit Card - <AUTHOR> http://www.wired.com/epicenter/2010/08/phone-credit-card/

<comment><USER2> This article makes a lot of assumptions and is generally completely wrong.

"For one, apps require 3G connectivity in order to verify a transaction."

This is irrelevant at least with a system like the one we've developed (<http://www.facecash.com>). First of all, you can pay with your paper barcode. Second of all, we've designed the app to work on devices with flaky connections, or no connection at all, like an iPod Touch outside of a wi-fi area. The merchant needs a connection, but you don't.

"So, the same middlemen will take their cuts for all the same reasons when we switch from credit cards to credit phones..."

Our system has no middlemen.

"Instead, MacPherson says, start-ups should continue focusing on areas where they can gain ground — municipal parking systems, public transportation, vending machines and the like — because all other attempts to disrupt the credit card status quo have failed miserably."

I wonder how much MacPherson gets paid, directly or indirectly, by the credit card companies in his position as "IDC Financial Insights practice director for payments and security" to scare away competitors?</comment>


Why haven't you made the jump to ssd? - <AUTHOR>

I just dropped my first ssd in and have been using it for 2 days now.  It really is a world of difference, quick video - macbook boots in under 20 seconds: http://www.youtube.com/watch?v=yj5pE_kUnps
Also: http://www.youtube.com/watch?v=odSSI_9KAkI
A good side by side comparison with a standard hdd.
So if you haven't made the jump what is holding you back? <comment><USER2> I totally want to, but it all comes down to cost.

I'm a college freshman without a job, using my 2009 Macbook Pro's stock 320GB HDD (275GB used so far). A 256GB SSD is too expensive ([http://www.newegg.com/Product/ProductList.aspx?Submit=ENE...](http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=100008120%20600038487&IsNodeId=1&name=256GB)) for me to dip into my savings when my HDD still works (and has more space).

Sure I'd like a faster boot time and for apps to snap open, but I don't know if that's worth $500.

</comment><comment><USER3> Still waiting for the prices on larger capacities to drop. Was spec'ing a 15" laptop with 2x hdd's, one 80GB SSD for / and one 500GB platter for /home, but then realized the 15" form factor is bigger than I want. 13" still have to choose one or the other.

Also, haven't been paying close attention, but do they have any issues these days with short/limited media durability/endurance/lifetime?

<comment><AUTHOR> yeah I went with a 64Gb on newegg last week, with a mail in rebate and the coupon I got it for $60. For that price you cant go wrong. I have found that moving my itunes/office/virtual machines to a external I can get by fine. Right now I am eyeing the OptiBay to replace the superdrive with my old 500Gb hdd. Seems like the best of both worlds. ([http://store.mcetech.com/Merchant2/merchant.mvc?Screen=PROD&...](http://store.mcetech.com/Merchant2/merchant.mvc?Screen=PROD&Product_Code=OBSXGB- UNB&Category_Code=STORHDOPTIBAY&Product_Count=0))

</comment></comment><comment><USER4> Dropped a gang last fall for the most badass build I can get, and was glad I did. The SSD speed is amazing.

</comment><comment><USER5> Waiting for the price/capacity to drop. IE: waiting for them to become a touch more mainstream.</comment>


How to Store Data Forever - <AUTHOR> https://drewdevault.com/2020/04/22/How-to-store-data-forever.html <comment><USER2> I guess I shouldn't be too disappointed but I read this hoping to find a permanent storage solution, after all thats what the title says.

If it's too good to be true it probably is.

I suppose etched gold laminated in glass (simlar to plastic laser discs) might provide a very long term storage solution with high enough data density for the current times. Other than that I can only think of punch cards which dont have the density for a current long term storage schemes.

I have heard murmurs of some sort of genetic engineering system that theoretically allows for the storage of data in a GMO plant that could in theory last forever.

Maybe some sort of space radio telescope system that bounces back signals?

Anyone else know of a way, or have an outside the box idea to store data for a very very long time?

<comment><USER3> Author here. The problem is, on a long enough time scale, you don't just need your data to be intact - you need it to be interpretable and relevant, too. How would you communicate with someone 10,000 years in the future? I _did_ address this in my article: the answer is, you need a real life chain of human beings between you and there which is maintianing the data to ensure it is understandable and useful.

<comment><USER2> Yes I did read it all, like I said the title is a quite click baity. As far sharing data with people(or other lifeforms) 10k years from now,that is an entirely different problem than "How to store data forever".

I'm not saying I have the answer to your title or the other problem, both good questions that I wish I did have answers to. I believe that the voyager team created a golden record as they faced a simmilar communication/interpretation issue.

Another "out there" idea that might solve the problem would be attaching a transmitter to a comet with a regular and frequent orbit, possibly Halley's comet which returns every 75 years, it is a short enough duration that the technology should still be available to receive the data. The comet idea would work well in preventing future generations from corrupting the data. Eg history is written by the victors of war.

Other than those ideas, short of creating a religion I cant see too many ways to store data forever and keep it useful and uncorrupted. Which is kind of too bad and "too good to be true too!" as per my original comment! ;)</comment></comment></comment>


Rust: Rocket will compile with stable rust from v1.45 - <AUTHOR> https://github.com/SergioBenitez/Rocket/issues/19#issuecomment-630650328 <comment><USER2> How close are we to something a Rust newbie could easily pick up? I'd be coming from Flask - how would the experiences compare?</comment>


S-expression Compiler in Scala - <AUTHOR> http://brianmckenna.org/blog/sexp_scala <comment><USER2> I hate to denigrate mini-compiler projects, but calling this a "Lisp to JVM bytecode compiler" is a bit much, isn't it? Unless I'm missing something, it looks like the language it compiles is just prefixed arithmetic expressions.

<comment><USER3> Author here. You're not missing anything - it really does just compile prefixed binary expressions.

It is a bit flippant to call it a "Lisp compiler". Saying that, I _did_ set out to write a simple Lisp compiler - I only managed to get those expressions working in the 2-3 hours I spent on it.

I deliberately tried to call it a "Sexp compiler" instead of a "Lisp compiler" but I probably did a bad job when I wrote:

        So, I set out to write a Lisp to JVM bytecode compiler.

Sorry :)

<comment><USER4> FWIW, here's a small Scheme-to-JVM compiler I wrote many years ago: <http://wry.me/~darius/software/yabe.tar.gz> \-- I'm sure it'd be shorter in Scala.

</comment></comment></comment><comment><USER5> wow - pretty cool! great example of the power a newer language can provide. the regex parser is pretty clean.

</comment><comment><USER6> I guess GCC is a text compiler then.</comment>


Hacker News IRC chat room? (the 2nd) - <AUTHOR>

I found this: http://news.ycombinator.com/item?id=85189 But nobody is on freenode/#news.yc. Is there another hn irc room? <comment><USER2> <http://news.ycombinator.com/item?id=85191></comment>