skysight-inc/HackerNews huggingface dataset:
If PRs were a instantaneous thing, I don't think it would be a problem. However, if you've ever looked at a network graph of a repo that requires rigorous code review or doesn't have a diligent maintainer, some of those forks can sit in limbo for a really long time. And, as more pull requests pile up, it's very difficult as a user to figure out which version I should be using for my code to run correctly.

I just ran into this issue the other day when I was using Node with a lot of dependencies that still haven't been patched for issues that cropped up in OSX Yosemite.
I like the project. But it says:

> Full duplex messaging

And the examples only show single direction. Is my understanding correct that everything received goes as STDIN? And is it also possible to run websocketd as a client?
You did the action, but that does not ever justify sending the email with an envelope claiming it came from you. Because you did not send the email. It could certainly put you as a Reply-To on the email, and it might possibly justify putting your name on the From line, but actually claiming to have been sent from your email address is wrong.
> which to my eyes is more useful than a "pretty" repository.

A pretty history is extremely important when you need to attract new contributors to your repository. I've maintained extremely clean git logs and extremely nasty ones too. New contributors are immediately turned off in the latter case, because a good developer will generally git log extremely early when discovering a new project.
"Whom the gods wish to destroy, they give unlimited resources."

These terse words at once explain the sophomore jinx in music, why famous scientists never outdo their work before they are famous, and some of the deepest paradoxes of my own life. Thanks for this. Classic.
Platter - Python build/deployment tool
When did I ever say anything about reply-to? Please do not put words in my mouth and then speak condescendingly to me. It's extremely irritating.
Thanks for the thoughtful response- it didn't come across as combative at all to me.

The true, provable safety of Rust was what drew me to it as well. I've always hated having to choose between un-principled memory management (with it's security and functionality vulnerabilities that can lie dormant for many years before kicking your butt) and garbage-collection forcing you away from the metal and removing deterministic reasoning about memory usage, runtime behavior, and runtime overhead.

I've been going through the academic papers, forerunners, and source-code for Rust's static memory routines and borrowing semantics. My hope and suspicion is that it can be added to Nim without core changes to the language like lifetimes. It's definitely not a guarantee, but with lots of experience in both languages now I feel very strongly that adding region-based-memory-management to Nim is possible while adding Nim's clarity, abstractions, and efficiency to Rust feels impossible.

I agree that at the moment Rust is the only responsible choice right now if provable memory safety is a primary concern, but I suspect that will change. In the mean-time, for us anyway, the price was too high in productivity when we discovered that we could do manual memory management in Nim in very well-considered isolated places and confidently use Nim's fast, real-time deterministic per-thread garbage-collection for everything else without a noticeable performance penalty.

Having said that, I don't think I actually disagree with anything you said (:
It's hijacking Alt+Left/Alt+Right (back/forward in the browser) too. Nasty.
I'll be the first one to critique whocalled.us, and tell you all the ways it could be much better. But that is a different issue than whether or not Google should completely remove it from its search results.

That page you linked to is mostly useless, and I would prefer to remove it from the index. But if I search that same phone number on Google, the #1 result is an empty page, "Be the first to comment:" (http://www.callhunter.com/numbers/2104495665).

There are plenty of pages that have a lot more information. Try this one (http://whocalled.us/lookup/6023888058). It is a messy site, with profanity, and plenty of noisy data. But how is that "Pure Spam" as Google insists?

I'll gladly reorganize the site if there's a significant problem with how it's structured. But Google has indexed this website in this same form for many years, and it continues to index its competitors. Why delete it now?

They might've detected something I have not found yet, but why not tell me so I can fix it? They provide me with no specifics about why whocalled.us is "Pure Spam".
In my opinion you have been extremely fortunate to have made it this long before getting smacked down. Continue for my opinion which is pretty harsh:

1. Almost all of your pages probably have no content

You've got 1.9M+ calls. Some numbers like 2145627653 have multiple calls but none of them provide anything new. Others like 4802550681 have 1 or more calls but no information other than city + state which is available on like every phone now. Others have no calls, no information at all.

2. As a result, almost all search users probably bounce, immediately

People want to know who is calling them, right now. They have like 6 seconds before the caller hangs up so they need to know - when they realize there is no information they are going to bail. They are also going to be pissed off that the top result on Google is asking them for information rather than giving it to them.

3. Your traffic is probably almost exclusively from search

Again I'm guessing here but I can't imagine that you are getting more than 5-10% of your traffic from sources outside of people searching for information on a phone number. That says to me that people don't think there is a reason to come back.

Yeah, you were first, but who cares? Your site sat around pissing off search engine users (including me) for a decade and still looks like the MVP it was in 2006. You may not be actively spamming the web but your website is passively spamming Google. Those other guys might be worse but who cares? That doesn't change the other facts and their punishment will likely come soon. That argument doesn't get you off the hook with Google.

If you want to get back on top you're going to need a better offering than effectively being the first result on Google and a comments system.
I Firefox with Vimperator they're included in URL search as you start entering URLs. Based on either the URL or the page title / bookmark description.

This ... is exceptionally powerful.
Awesome response, but....

> (In case the Pedagogical Brethren wish to come and "correct" me.)

Seems very unnecessary and is a big departure from the Haskell community I'm personally used to. On top of that, it's not the tone I'm used to on HN for the most part either.

Apologies for going off topic, just felt obliged to chime in.
The first chapter of Dreyer's thesis "Understanding and Evolving the ML Module System" (http://www.mpi-sws.org/~dreyer/thesis/main.pdf) talks about generativity
WPF has not only a UI thread, but a closed-off rendering thread responsible for translating scene graph modifications into screen pixels. It was never clear to me if browsers did the same thing (dom being changed in the single UI thread, dom changes being processed in an off limits rendering thread).
I don't believe that this is true. You use the exact same patterns and tricks in both for perf-critical code: off-GC primitives and object pools rule the day. What are you considering a "much better" option available in Go?

(I considered stack-allocated structs in Go, but honestly that doesn't strike me as a particularly major thing; it may be slightly more terse, but fundamentally the same behavior.)
This is actually one of the things I miss about SVN: in addition to a record of the commit being generated on a branch, there's a record of the commit being accepted onto trunk, and when and why.

Rust has an integration robot that does all the merges into master, that records who reviewed it, what the link to the PR (and the code review on that PR! it exists!) was, etc. It was a little weird as a complete newcomer not to see humans in the `git log --first-parent` view, but I really like it now, because if I want to know why some commit was merged the way it was, that discussion is recorded nicely. (The merge commit has the subject/body of the PR, which doesn't need to match the subject/body of any commit in the PR.) Compare with, like, the Linux kernel, where the best you can do is Google for LKML threads with the same subject line. There's even a convention of [PATCH 0/10] for summaries, but those summaries are nowhere to be seen in the git repository.

https://github.com/rust-lang/rust/commits/master
I tried to mitigate some of the pains with GitHub code review UI by writing a helper userscript to track the progress of big code reviews. Some of the items listed in the link can be fixed in this way.

The idea is to expand/collapse files, store progress of the review and collapse status of the files in local storage of the browser, so you can stop and resume at any time (I also have in mind serializing this stuff into a hash in the URL so you can forward it to the other machine for instance, and recreate the progress there).

I work on it every now and then and have a number of items in the backlog. If someone is interested to contribute I'll be happy to accept pull requests (sic!) :)

https://github.com/jakub-g/gh-code-review-assistant
From the web interface, no, but you can close PRs with `git push` just fine.
It doesn't matter what the mechanism is; writing code that depends on code that changes is more complex than simply not doing that.
> and doesn't address any of the reasons why people prefer containers to VMs for some types of workloads

I was responding to one reason -- which is "running any image on any platform".

> why people prefer containers to VMs for some types of workloads

Sure but there are no magic unicorns underneath, knowing what you get from a technology requires some understanding on how it works. Saying things like "I want very lightweight but also want it to run any image on it" is asking for a trade-off. Or a complicated multi-host cabaility based platform.
I guess the next logical step is to build a virtual filesystem such that each connection is represented by a file. Then you can further decouple the connection handling from the actual application. Applications can start later to talk to a connection established before.
Hey, sorry... You're right, I shouldn't have said this. Over the past few days, certain parts of the Haskell community have been particularly vicious (toward me and others), and I have been feeling a bit beleaguered. I shouldn't have brought it here though. Cheers.
> After doing your research, you're welcome to submit a magical CL and PR that brings down the binary sizes, then you won't need to argue anymore.

The original link is titled "The State of Go". The first thing I want to know about a state of a new language is whether it works. Then how well it works. Then, maybe, how to fix it and which VCS to use. There is an issue I think is within the range of these two questions, but it is not even mentioned there.

So to make life a bit easier for people who like me expect that issue to be discussed first, I posted a comment summarizing (in my opinion) the state of Go.

My thoughts on how to fix it are hardly relevant to the current state of Go.

> It doesn't print just strings. It can print anything.

The fact it is just a string should be statically (build-time) inferable in a strongly-typed language. Reflection, at least as I understand it, implies run-time type information. So the question does make sense. Yes, I understand why it may be needed for a particular implementation of printf, this is why I called it a lesser issue.
"The choice of a pure functional language like Haskell to do lots of IO seems like a strange choice given that Haskell makes side effects like IO more difficult than other languages. I'm curious to know how that affected the implementation. I'd like to use more functional languages, but since my job is primarily IO of some sort, watching people struggle with writing to sockets leaves me more than a little hesitant."

Haskell has excellent I/O support. How do you mean that Haskell makes I/O difficult?
Android Wear smartwatches used by less than 0.1% of Android smartphone owners
Force pushes to the PR fork. We have set receive.denyNonFastForwards=true on the upstream master.
lps25:

> Consider the case of a set implemented as a binary tree. The type of such a set should be parametrised by the type of the elements and the ordering used. With applicative functors this is the case as your set type will be `Set(O).t` where `O` is a structure containing the type and the ordering. With generative functors each individual set type is abstract -- so the type itself is not parameterised by the ordering.

You make a good point about this not being strictly about type classes. But I'd say that the issue is only a problem in the presence of implicit resolution, since otherwise, you can just bind the result of the functor to a structure once and be done with it. It becomes an issue with type classes, because you don't have the choice to share a single structure during elaboration.

IMO, the generative version is still better for most use-cases (pure or not), but it's nice that you can have both in OCaml.
> I'll mention, though, that Haskell does have one form of modularity which ML doesn't really, which is the fact that you can write algorithms separately, compose them together after the fact, and expect to get reasonable performance in most cases.

I'd actually argue the opposite. MLton is one of the best whole program optimizing compilers I have ever used. There are virtually no penalties for abstraction. OCaml has a bit of trouble here, from what I've heard, but I've never personally run into serious performance problems as a result of abstraction.
this post has to be a joke, right? none of the things on the first page are universally true.
Values ("off-GC primitives?") are first class-citizens in Go. Stack-allocated structs have much more value than you think.
Thanks! (I'm the author). I focussed on JavaScript because it's what I know, it's my day job, and I wanted to share a bit of my research while trying to introduce AltJS to it.

I wasn't (and am still not) really enough of an expert in either Haskell or OCaml to talk about other differences; including a bunch of dot points I don't understand wouldn't help anyone :)
sgeisenh — wow! How cool. If that is the case, than that's awesome, and makes me very happy.
> 2. benign effects: in Haskell "proper", you do not have effects; rather you have "codes" for effects, which get interpreted into effects by the RTS; this rules out the possibility of, e.g., using effects to implement a semantically pure interface. On the other hand, OCaml has actual effects, which can be used in an open-ended way to implement all sorts of functional interfaces.

So, to be all pedantic and stuff... You've always got unsafePerformIO, first off. This is used in Debug.Trace (https://hackage.haskell.org/package/base-4.7.0.2/docs/src/De...) to allow printf debugging in pure code. This is also used in some Haskell libraries to provide restricted effects in monads other than IO. But if you don't want to use unsafe* functions, you can always use ST to get direct access to mutable memory in a safe way. If you can runST within that interface, then you can present a pure interface to users.
> the authors worked really hard to implement in Haskell something that is trivial and well-understood in Python and other languages.

So where do you get the idea that it was hard work in Haskell?

"It was a breeze to rapidly prototype and test individual components before composing them into a whole."

"Very surprisingly we got done really quickly."

> The choice of a pure functional language like Haskell to do lots of IO seems like a strange choice given that Haskell makes side effects like IO more difficult than other languages.

Haskell separates IO, it doesn't make it harder.
> I posted a comment summarizing (in my opinion) the state of Go.

Not trying to be rude, but your uninformed opinion is less valuable than you think.
Email Marketing Manager
Local history is not a concept in SVN. There is only one history which is the same for everyone.
Can only view diffs on a single page (can be very slow).

I've seen GitHub take five seconds to render a 100K line diff. In my experience all of the other tools I've used, including some of the ones listed, can take longer to render individual file sections of such a diff. It's fast enough.

Comments are sent as they are written; you cannot "draft" comments.

I'm a bit puzzled as to why you would need to draft comments inside the PR interface, especially in light of the fact that they can be edited.

Cannot compare differences between patch sets.

You most certainly can. Just use branch/revision compare.

To create a patch one must fork the repository publicly (weird and unnecessary).

Also immaterial.

Accepting a patch creates a "merge commit" (ugly repo history).

This comes closest to being a legitimate complaint. Because GitHub emphasizes recognition of contributors, it doesn't let you rewrite the commits in the PR as you merge them with the merge button, but there are multiple ways to merge on the command line that avoid the merge commit and play nice with the PR.

In general, pull request culture is not about code review.

WTF?

Sounds like a strong case of NIH.
What if that's just because people have fewer problems with Nim than they have with Rust? The number of SO questions is a better measure of how often and how many people run into problems than it is a measure of overall popularity.
From what I hear you have the funds and resources to operate at that scale.
This is brilliant, I wish it'd get more upvotes and attention. Wireless waves are such nebulous, hard to understand things. It's great to see a visual representation!
Don't use the merge button, just

This is the smell of git plumbing again. Don't use the obvious UX that's been presented to you, do some other workflow that doesn't appear in the documentation.
> The choice of a pure functional language like Haskell to do lots of IO seems like a strange choice given that Haskell makes side effects like IO more difficult than other languages. I'm curious to know how that affected the implementation. I'd like to use more functional languages, but since my job is primarily IO of some sort, watching people struggle with writing to sockets leaves me more than a little hesitant.

Disclaimer: I haven't read this yet, but your comment above caught my eye and what I'm about to comment applies regardless.

Maybe it makes IO slightly more difficult to begin with, but you can be sure that your all cases are handled after that. Plus once you know about fmap and >>= you can apply pure functions to monadic functions (functions of type IO are monadic because they implement the Monad typeclass (think of it as an interface for now)).
1. that's why I qualified it "proper". Of course there is unsafePerformIO, but in the presence of laziness, this is really unsafe. as opposed to ML, where doing IO may harm your ability to reason about stuff, but it won't be unsafe.

Debug.Trace is also unpredictable; actually, it's perfectly predictable if you understand laziness, but it's still not what's really wanted in most cases.

2. ST is a single instance of an effect that can be interpreted into "pure" code. There are plenty of other effects that don't work like this in Haskell, not to mention the problem of composing them together.

So thanks for chiming in! But what you have said is not really that different from what I have said.
...and it contains acrylamide
This with the hololens could be rather nice to debug.
Yeah, I dunno, the github PR 'culture' I've engaged in has often in fact been about code review. I don't see any problems with forking a repo publicaly to make a PR (what is there to hide?), am not really bothered by merge commits (and in some cases they are actually quite useful, some people prefer them, it's a point of some contention), and I don't really understand what they mean by 'Comments are sent as they are written; you cannot "draft" comment'

But to each their own -- I'm curious what alternative system (if any) of accepting patches they have. If it's emailed git patches on a listserv, then I would definitely find it a barrier to submitting patches, myself, compared to github PR's.

I think in general, github PR's have proven succesful at soliciting code contributions from a wider field, which seems to be the goal of their UI (over command line git itself). Of course, this can seem a downside too, as committers have to spend time dealing with those submissions.
I can't remember where I saw it (pypy dev list maybe?) but unfortunately I think the project has been mostly abandoned. Wouldn't hurt for someone to fork it though, it seems like a great idea if someone had the time to move it forward.
> This exporting of goods is what drove the British, and the Imperial powers in general, and what produced a wealthy economy in those countries.

Deirdre N. McCloskey in her book 'Bourgeois Dignity: Why Economics Can't Explain the Modern World' does a pretty good job of explaining that this imperial trade (amongst other factors) doesn't do enough to explain why The West became wealthy.

To quote McCloskey: "What's wrong with such images? This: the world did not change by piling up money or capital. It changed by getting smarter about steam engines and wiser about accepting the outcome of innovation."

If imperialist trade is what caused British wealth to increase by a factor of sixteen or more since the 16th or 17th century, why didn't countless other states become modern-day wealthy during countless other imperialist expansions?

Nor did the Industrial Revolution do it. The printing press was invented in China (1041) some 400 years before Gutenberg (1450) caught on to the idea, and the Industrial Revolution didn't happen for another 300 year after that!

McCloskey's suggestion is that Bourgeois Dignity is what caused the change. That society came to dignify innovation. That average Jane Citizen came to be able to invent and bring to market innovation. Not only that, we now glorify the innovator, rather than prosecute them.

So it wasn't British imperialism that made Britain rich. Free trade does more to cause the wealth of nations than imperialism ever could. But free trade isn't enough either.

McCloskey argues it isn't Capitalism that is so important to modern wealth, because capitalism -the accumulation of capital- has been a thing since people have been gathering seeds.

As Sam says in his article it is Innovationism that made the modern world so extremely wealthy. That we are prepared to iterate so rapidly, ever more rapidly, and dignify those who do the innovating.

So I disagree that the imperial redistribution of wealth is what has caused 'those regions' to be affected to this day. As India embraced Innovationism -in manufacture, call centres, software development- we have watched it become increasingly more wealthy.
Part of the reason Go exists is because of such issues. Believe me, it's not desirable.

My point is, on typical machines today, even a 10mb binary is not an issue at all.
Informer says Apple's car will be self driving
Well, it depends on what documentation you mean. The alternative is using standard git commands that are in the git documentation, which is exactly what OP's alternative presumably involves?

(But I am entirely sympathetic to the opinion that git itself exposes too much plumbing and has a pretty baroque end-user interface for doing certain things. And it's also certainly legit to wish or suggest that _github_'s UI worked differently than it does, although the merge commits don't really bother me, and some people prefer them, it's a point of some contention).