jongraehl

There was a story recently about this happening to a woman (a soldier who was only momentarily earning 90k/yr for hazard pay) recently with about the same result. Retarded law, retarded idea - child custody as a meal ticket. Although if this case is just about alimony, that's even worse.

Anyway, the particulars of this person's struggle don't matter. The default marriage contract is stupid and it seems you can get into bad situations that might not even be possible with a non-marriage contract; don't go into a marriage blind.

Author suggests we should consider Damon an expert on whether someone is acting. That's rather silly. Why aren't we using actors instead of torture, then?

Yes - it would be reckless to store users' login attempts (correct or incorrect) in the clear, no matter the purpose. And I've never heard of anyone doing that - it's pretty self-evident.

Huh? Why shouldn't the top 10% be more than 5 times as productive as the average?

Thanks for the direct link to relevant cites. Oh, you say they're somewhere in a book. Not great (that said, '59 seconds' is good).

Snake oil alarm: "the keys to productivity" - maybe there's proof that this approach can work, but "THE keys"? As in there's nothing else that can work? Come on.

Good luck.

Another reason to use https (though I guess IT can install a cert for transparent MITM SSL proxying). Imagine a user whose TCP connection shuts down as soon as the 4 bytes 'fuck' pass it (say, only for port 80). This should happen randomly for high-entropy binary (e.g. compressed text/image) data - about 1 in 4 billion bytes. I guess it's not that likely except for extremely large files.

Sounds fun, but everyone solves the same problems (ok, ideally not: "sets of custom-built, rapid fire coding challenges built by each employer. You can use Hackermeter’s pre-provided challenges, or build your own")? How long until copied solutions corrupt the scores? Better check performance on a held-out set before interviewing/hiring.

Let's not get into plagiarism-detection arms race; consider automatic refactorings / pretty printers with variations, and human input to vary variable names.

Dumb. Mangles Godel.

The premise is that for real world inputs some code may never be used, and so it's an advantage for late-checked types that you can have wrong code that will never cause any observed bug. I'd rather "waste" my time deleting nonsense code after it fails an early type-check. Less code = better reading/maintenance/extension.

Better to focus on the real advantages of single-type languages (usually, terser programs, although type inference can make some haskell/ML programs apparently type-less).

It doesn't follow - the type of consciousness we experience could be different. Though if you were saying that it's absurd to call single cell 'conscious' in the sense that human brains are, then I agree.

I agree that "emerges" is no explanation at all.

But we can agree that the images on the TV screen are caused by the configuration of physical matter making up the TV, just like our consciousness is caused by the physical matter making up our brain.

Granted, people have subjective (i.e. feel-happy) reasons to throw out Occam's razor and suppose we have e.g. an eternal soul, but the search for the soul-receiver in the brain will just give you fits (not so bold prediction: they'll never find it, because it doesn't exist).

Since the are so many suitable alternatives, what all the kids are doing varies from school to school. So this is just an isolated anecdote.

It's more plausible, not less, that divine inspiration is reflected in the vote of a group than in a single man's decision. Like a multiple sensor array, the noise in a single instrument (and the risk of its corruption) can't cause the whole to fail to detect the signal.

I won't hold it against them because it's already happened and inevitable, but part of me mourns the fact that most of what I'll see across social media will increasingly be A/B tested manipulative marketing crap. I have no problem with the particular touching video; I just resent the blockbuster mentality.

Imagine that everyone on HN were actively optimizing what they say according to what gets voted up. Sound good?

Presumptuous. We may as well tell the author of this slam that his mother, daughter, wife, sister, best friend, butcher, and dentist are all embarrassed for him.

This reminds me of an Amtrak ride along the CA coast, where the 50yo man next to me enjoyed sparring w/ the young female stewardess/whatever over the course of several hours, until the climax: he offered to take her into a bathroom and put her on a diaper changing table. I don't believe she was thrilled to hear the proposal.

There are men like that. So what? Long-winded article w/ poor quality of evidence and thinking.

Compilers do not restructure a causal chain of events between a client and server in a different process. It's very easy to understand this when you realize that send -> wait for response and read it will result in certain system calls, no matter the language.

[Send 4 bytes * 200, then (round trip latency later) receive 4 bytes * 200] is fundamentally different than [(send 4 bytes, then (round trip latency later) receive 4 bytes) * 200]. Whether the message content is "ignored" is irrelevant.

Or, put another way, it's ridiculous for you to modify the Go program in that way (which will very likely send and receive only a single TCP segment over the localhost "network") and report the faster time as if it means anything. If you modify both programs in that way, fine. But it's something completely different.

I agree, but your analysis is missing something: the canary-threatener may be secretly, without a public ruling, within the refresh interval, be convinced that if he doesn't keep updating (falsely) the canary, he'll go to jail. In other words, the precommitment to stop producing the canary signal isn't fully credible (though it seems much more likely to get the message out than a promise to actively say if something happens).

Yes, taking ownership of your obvious flaws is often an effective maneuver. By so doing you minimize the effect of external critics calling attention to them. ( related: http://tvtropes.org/pmwiki/pmwiki.php/Main/LampshadeHanging )

I do think he's doing the smart/right thing (now).

I've read about these topics for a long time, and I quickly concluded that the author(s) made no effort at skepticism. You absolutely cannot rely on such superficial analysis of research. Even if you don't know anything you should be suspicious (examples: women need more sleep than men "because their brains are more complicated", 8.5 hrs sleep is less healthy than 5 hrs - correlation/causation error at least; meditation doesn't just calm the mind but is also one of the best ways to buy lasting happiness (evidence: quote from meditation advocate)).

Interesting, but now I'm even more confused. How can we possibly explain that a (go client -> go server) (which are in separate go processes) performs far worse than (go -> scala server), given that the go server seems to be better when using the scala client?

The comments on the article page have a different report which doesn't suffer from this implausibility:

go server + go client 22.02125152

scala server + scala client 3.469

go server + scala client 3.562

scala server + go client 4.766823392

Are hybrid approaches worth it (exposing some details so that Go network server can get the right service from the OS)? I'm not sure how much language complexity Go-nuts will take, so they'll probably look for clever heuristic tweaks instead.

My comment was specific to this benchmark, which has 4 byte messages that cannot be buffered due to the ping (wait for pong) ping ... repetition in each client. Of course buffering matters for full-pipeline throughput.

Discussion last night ("Just got an Amber Alert ..."): https://news.ycombinator.com/item?id=6165026 had predominantly "think of the children, how can you complain about your minor inconvenience" prevailing tone.

I wonder what makes this thread so different. More people are focused on the costs as well as the benefits (I agree that the costs are significant). If it's not just a random difference in the initial seeding of comments, I'd have to guess that it's the authority of latimes.com talking about how (many!) Californians are startled etc. Now this is a safe, approved line of thought.

This calls into suspicion the independence of the typical HN comment. If you're just posting to be seen on the prevailing side, why comment at all? The less deeply you think before talking, the more you're swayed by subtle priming and attention-focusing trivia.

Also interesting, a years-ago attempt to shame Apple into enabling Amber alerts: https://news.ycombinator.com/item?id=509741

It sounds like a less intrusive amber-alert UI (a regular text, for example) would be accepted by most, although I'm sure if you tally up the attention spent vs. the increased odds of catching a criminal vs. increased harassment of near-matches, it's not a clear win.

I'm curious: are you saying Go is M:N and JVM is not? I had to look up M:N - http://en.wikipedia.org/wiki/Thread_(computing)#M:N_.28Hybri... - but ultimately I don't know anything about JVM or Go threading, and your comment didn't go enough into detail for me to follow your reasoning.

Thanks to parent (after edit) for really testing. It turns out that he was right that Go on Mac is substantially worse than Linux - my bad. Maybe the Go lib authors didn't put much effort into reading the subtly different BSD/Darwin vs Linux syscall semantics.

To explain the Nagle algorithm's irrelevance to this case, we have to understand how it works. It doesn't delay any writes once you read. It only affects two consecutive small writes (my memory was fuzzy so I checked http://en.wikipedia.org/wiki/Nagle's_algorithm ). Odds of preemption between the client's write and its read seem small, so it shouldn't matter whether you Nagle or not.

Allocated memory that's paged out and not used is nearly irrelevant (I believe this is true even though a 200mb JVM heap will likely see some unnecessary rotation in/out due to GC - ideally you'd manually configure the heap appropriately (smaller) if you intended to challenge total system memory w/ many processes).

> First of all, they're testing on MacOS, which is not going to be the platform they're actually using for the server code. The backends can be very different.

Unless you have evidence that Go has MacOS-only bugs, this is meaningless speculation (though I agree that it's possible that there's no problem on Linux and that people don't generally run mac servers, I'm not sure why we should privilege your hypothesis).

Agreed about GOMAXPROCS=4 - that seemed questionable to me (I don't know what it does, precisely, but I don't see a 4-anything limit in the Scala code).

The better performance of the Scala client+server if anything suggests less buffering, not more, since the next ping can't be written until the previous pong is received.

p.s. to parent: "the JVM TCP stack?" really?

I think you're on the right track in supposing that there can't be a huge performance difference in such a simple task, given that both languages are compiled and reasonably low-level. The most plausible explanation would amount essentially to a misconfigured library, not a fundamental advantage due to say, advanced JVM JIT. Your suggestion to try server-{a,b} x client-{a,b} is also a good one.

Your modified Go server doesn't return "Pong" for "Ping". It returns "Ping". And the "a small change" version is nonsense. It's fundamentally different. - you're firing off all your requests before waiting for any replies, and so hiding the latency in the more common RPC style request-response chain, which is a real problem.

You speculate a lot ("hiding some magic" "likely doesn't need to observe the answers") when you haven't offered any insight.

EDIT: Nagle doesn't matter here - it doesn't delay any writes once you read (waiting server response). It only affects 2+ consecutive small writes (here I'm trusting http://en.wikipedia.org/wiki/Nagle's_algorithm - my own recollection was fuzzy). If Go sleeps client threads between the ping and the read-response call then I suppose it would matter (but only a little? and other comments say that Go defaults to no Nagle alg. anyway).

> infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)

People are so good at rationalizing their preferences that they sometimes say really stupid stuff withour realizing it. This nightmare scenario of relying on boost, std::vector, or whatever - it's really basic stuff that's both open source and easy to understand/debug - e.g. https://github.com/graehl/boost/tree/object_pool-constant-ti... (reminds me - I should really get around to submitting this)

That said, avoiding libraries (especially avoiding templates and just using void*-like stuff) does keep binaries/libs smaller, but I'll gladly make the computer work slightly harder considering that the result is the same speed (C++ is often faster than C, in practice).

The downside I care about is compilation speed. Simple C projects compile/link faster than modern C++ ones, even though the code for the same functionality is far more brittle, unsafe, and opaque