lbarrow

Do you really think software architects shouldn't write code? It's very very important that someone designing the system in the large understand how it actually works day to day, and writing code is an effective way to do that.

It's hard to evaluate whether or not those examples make sense without some pseudocode showing how the classes are used.

Weaker might have been the wrong word; it's more just different than anything else. Go struct embedding doesn't do much more than forward a method call to an inner struct:

>There's an important way in which embedding differs from subclassing. When we embed a type, the methods of that type become methods of the outer type, but when they are invoked the receiver of the method is the inner type, not the outer one. In our example, when the Read method of a bufio.ReadWriter is invoked, it has exactly the same effect as the forwarding method written out above; the receiver is the reader field of the ReadWriter, not the ReadWriter itself.

https://golang.org/doc/effective_go.html#embedding

Inheritance isn't necessarily part of OO. Go has radically weaker inheritance mechanisms than classic OO languages, for example.

I concede the example is a bit of a straw man. But I'd challenge you to provide a similarly concise problem and solution where 1) inheritance is useful and 2) there isn't a better solution that doesn't use inheritance.

Right, I'm definitely not the first person to make this argument. But I still see people making these mistakes; that's why I wrote the article.

That's a fair point. Scala definitely seems to have had to compromise the quality of the language features it offers in order to achieve Java interop.

Traits are great, but Scala still has subclassing. I'll update the article to make it more clear -- thanks for pointing that out.

I've been using Dropwizard extensively at work for the last 8 months without touching XML.

Great post, I really enjoyed it. Norvig has a knack for modeling these domains in simple, powerful ways.

These aren't unit tests, they're generative tests. They're used for different things. Unit tests make assertions about how a program responds to a specific input. Generative tests make assertions about invariants in a program over a wide range of inputs.

The workflow for using them is very different. A unit test suite contains a finite number of assertions and, assuming no bugs, should run in a relatively small (or at least bounded) amount of time. A generative test, however, usually can run forever _by design_.

A typical workflow is to start a run overnight and see if it caught anything in the morning. If the generative suite finds any bugs, you turn the specific cases that caused the failures into unit tests and commit them.

C, C++ and Java generally don't break backwards compatibility in new language versions (or at least not as much as other languages), so upgrading to the next version is usually easier.

You don't have to wonder. It says at the bottom of the article that Lyft is not profitable:

  Though currently unprofitable, Lyft's ride economics appear to be going in the right direction.

Yea but the hypervisor has to know how much physical memory to give the unikernel.

Exactly. In my mind that's the best thing about these projects: the technical benefits are so amazing they might actually encourage people to look beyond the Linux-and-company systems stack.

(Although, to be fair, most people run a Linux dom0.)

Probably needs a [2013] tag. Previous discussion was here: https://news.ycombinator.com/item?id=6234736

No Venmo?

The theory that raising children in a multilingual environment impaired development was common in the 70s, but since then an overwhelming amount of evidence has debunked it. The commonly held view now is that raising a child in a multilingual environment will have no impact on how fast the child reaches developmental milestones.

A good introduction to the topic from Paul Bloom (a professor of developmental psychology at Yale) is here: http://oyc.yale.edu/psychology/psyc-110/lecture-6.

The author links to a much better critique of Pinker by Nassim Taleb. The basic idea is that Pinker uses data about very thin-tailed processes, like street crime, to make inferences about very fat-tailed processes, like casualties in war.

This article is a bit over the top and has a lot of non-sequitors, but the statistical critique of Pinker's book by Nassim Taleb the author linked to is excellent: http://www.fooledbyrandomness.com/pinker.pdf

I don't think security is produced by picking one language or another, but I do believe that it's harder to write secure code in a language like C than a language like Java or Rust. There are simply way, way more ways to shoot yourself in the foot.

How was her life ruined? She lost her job, then got a new one. Her life seems fine.

The author sums up his attitude in one of the first sentences: "I’m not a languages person (C will do, thanks)".

Go is not C, and it's not going to be like C. It's not really reasonable to expect it to have the same toolchain conventions as C. I'm not saying the choices to Go authors have made are necessarily good, but I don't dislike them only because they're different from C.

Does anyone actually ask this sort of thing in an interview anymore? (I don't mean this as a knock on the repository, which looks very nice aside from the lack of tests.)

I'm an engineer at Braintree.

Speaking only for myself, I don't see a conflict of interest between us and PayPal. PayPal has embraced our APIs and approach to support as the future of how merchants will integrate with PayPal, and we've been able to leverage PayPal's consumer brand to build better products for our merchants.

I was initially very, very skeptical of our acquisition, but I have to admit it's turned out well. I don't think there is any risk of them underfunding or cannibalizing us.

The 20% figure quoted is describing an earlier deal that eBay considered and rejected.

We already have those problems -- how will legalizing pot make them worse?

Aphyr is truly amazing. This series of blog posts has introduced me to a rigorous, careful way of thinking about distributing systems. I'm a much, much better developer for having read his blog. How many people can you really say that about?

I'm super pumped about this -- I plan to spend the weekend upgrading a graceful shutdown server I maintain to use it.

https://github.com/braintree/manners

Yea, I went back and forth on making sort of "effectiveness" into its own category. I think it makes more sense to think of overall effectiveness as the combination of the other three categories rather than its own independent thing.