Ask HN: www.site.com or site.com? - <AUTHOR>

Which is preferred and why? <comment><USER2> Well, chrome has decided "www." is implied. I am reserving judgment about this, but in all modern browsers you can ignore the www. Honestly, without the "www." you have a much stronger chance to define your brand. Which do you remember better? "www.iamawesome.com" versus "iamawesome.com"?

</comment><comment><USER3> I use www.site.com on all printed material, advertising, etc. It seems to be more recognisable for casual web users. Redirect (301) site.com to www.site.com. I think there is a RFC recommending this.

</comment><comment><USER4> I think www vs. non-www is a matter of personal preference. More important is that you stick with one and use that sitewide. Don't forget to 301 the other one to your preferred one. People are so used to typing www before a domain name, so I stick with that and force www with a redirect.

</comment><comment><USER5> I like site.com because the url is shorter. Just a preference. In these days of browsers on phones and url shorteners, it makes sense to keep the base domain as short as possible. If you redirect from the www, it takes care of everything.

</comment><comment><USER6> It shouldn't really matter, but may well do if you're considering less tech savvy visitors. Either way, you should support both with a HTTP 301 redirect to avoid search engines thinking that you have duplicate content.

</comment><comment><USER7> Anecdote of dealing with average users: When I am over shoulders and ask people to go to various sites, the first thing they do is slap in a "www.", assuming that every web site must begin with it. In some situations, I have to specifically tell them NOT to put the www.

</comment><comment><USER8> Technically, it does not matter. Its more of a personal preference.

How does your domain sounds better? With www or without www?

</comment><comment><USER9> You can set your server to respond to both, and should.

I love when I can hit two different web pages on the same URL based on whether or not I included the 'www'.

This is a sign of a poor IT setup.

When you spell it out over the phone, you should include the <http://>, though. (Haha! It's also useless!)

</comment><comment><USER10> I default, (by which I mean redirect non-'www.') to 'www.' simply because if you have a few subdomains too, it makes sense in a 'grand scheme of things' kind of way ...

www. dev. old. cdn.

etc etc ...

</comment><comment><USER11> It's largely a matter of personal preference, but an important consideration is that using site.com will mean any cookies served from site.com will also be served on any subdomains. For more reading on the subject: <http://www.phpied.com/www-vs-no-www-and-cookies/>

"Basically you should always use www if you're planning to use any other sub- domains and you want them cookie-free."

<comment><USER12> You get to set the domain when setting cookies so its not a huge issue either way.

<comment><USER9> Usually, but some browsers won't accept forged cookies. It'll only accept cookies from the domain it requested from.</comment></comment></comment>


Why Startup Founders Should Stop Reading Business Books - <AUTHOR> http://www.softwarebyrob.com/2010/08/05/why-startup-founders-should-stop-reading-business-books/ <comment><USER3> No, they shouldn't choose more specific books, they should just friggin get to work. Startups are all about hard work, not about sipping coffee and reading.

<comment><USER4> Hard work which apparently leaves times for reading posts linked on HN.

<comment><USER5> Maybe he already sold his company?

</comment></comment></comment><comment><USER6> I think the key lesson (and this is independent of the above article) is to start emphasizing doing over reading.

Ie your day you should be a constant stream of action after which you force yourself to read for a bit.

My dad was like this when he was working. He hardly ever read during the day. He'd work like crazy through the day and then would catchup on reading in the evening for about 1 hour. He was an officer in the navy and went from plowing the fields as a kid to pay for college to a very high ranking officer.

The only "meta" principle that I observed, about him, is that he is fearless in a very strange way. It always seems to me that he doesnt even think about starting to do something. He just does it ...

Someday I hope I'll figure out what drives him.

</comment><comment><USER7> I read a lot of books. The biggest benefit I get from them is that my thoughts on current projects will get tweaked a bit, and a few gems come to me that I wouldn't have thought of otherwise if I was too focused on my specific project(s) and books that relate directly to them.

I read for enjoyment, relaxation, and learning, in that order. A lot of times, the benefit I get is similar to when you have an idea in your head then actually talk to someone about it. It's amazing the sort of ideas that pop into your head when you just start TALKING about what you're doing instead of just thinking about it. Books, however high-level or fluff-filled, often have the same effect for me.

</comment><comment><USER8> "For entrepreneurs, reading business books is the new television"

Could not agree more with the author. Most of these books are just waste of time. There are few good business books, though, the ones that look at things though skeptic's eye, the ones that disillusion you. But even those books are probably not worth reading.

Moreover, most of these books were written by authors who have never done any significant business in their life.

</comment><comment><USER9> Except for "How to Get Rich". That one is great.

<comment><USER10> Author? Thanks.

<comment><USER11> Felix Dennis

</comment></comment></comment><comment><USER12> Good article. I think it would be better if he used a counter-example or two, to make sure readers knew what he meant by "Business Books". For example, according to Amazon, "Getting Things Done" is a business book (two of the three categories it's in are subcategories of "Business"), but has specific actions that could help many startup founders.

[http://www.amazon.com/Getting-Things-Done-Stress-Free- Produc...](http://www.amazon.com/Getting-Things-Done-Stress-Free- Productivity/dp/0142000280)

</comment><comment><USER13> Summary:

I read the same trendy business books "everyone" is reading.

They didn't help me.

Therefore, don't read _any_ business books.

(except mine)

<comment><USER14> Yeah... it seemed like kind of an odd article from someone who is trying to sell a business book.

</comment></comment><comment><USER15> Just because there are a lot of over-simplified, tabloid-headline creating blogs that are trying to get to the front page of Reddit or Hacker News, it doesn't mean I am going to tell people to stop reading all blogs. In the same vein, there are a ton of amazing business books that entrepreneurs should be reading in spite of the others. The Map of Inovation for example. The key to to pick the right ones and read faster.

</comment><comment><USER16> A better bet is to read the distilled wisdom of all the best business books of all time - The Success Manual - something I helped edit - is one of them. Check it out at <http://thesuccessmanual.bighow.com>

</comment><comment><USER16> Another option is to read The Success Manual - which contains summaries from 100+ best business and self help books. <http://thesuccessmanual.bighow.com>

<comment><AUTHOR> Along those lines, I had a site called Squeezed Books that does free summaries: <http://www.squeezedbooks.com> \- I sold it though, and it remains to be seen how it'll end up.

</comment></comment><comment><USER17> Leadership is an Art and The Abilene Paradox are great business books - <USER2> you've ever made mistakes managing people like I have both of these books are very instructive on the people aspect of running a startup.

</comment><comment><USER18> ... and business blogs.

</comment><comment><USER19> Very ironic that she emphasises that the business books are general and not applicable and what you need is tailored advise, yet goes on to give very general, and absolute advice, and also make very general comments such as "we" are "addicted" to... blogs?

I don't even read any blogs! And I am not addicted to anything on the internet! And my ability to process information is hardly "plummeting" and basically you should stop just giving out opinions as a wise old man in the age of 80 telling the great youth of what life is really like.</comment>


What Golang Is and Is Not - <AUTHOR> http://danmux.com/posts/what_golang_isnt/ <comment><USER2> As someone who writes Go every day for work, I can't agree that Go is simple. Using a language for analytics without generics can be quite painful and error prone.

Go is a language that pushes remembering corner cases and failure conditions onto the programmer rather than the language and runtime itself.

When you already have to remember a myriad of corner cases for business logic, also remembering so many corner cases for your code hurts productivity.

I also believe that languages exist to make getting to an end result in given domains easier. Go does not make my life easier.

I really hope it gets generics. I wish it would do away with nil/null.

Nim is a very good language that actually accomplishes the simplicity Go wanted imo.

Go affords simplicity to the Go compiler writers at the cost of burdening Go users with having to remember inane things.

<comment><USER3> > Go is a language that pushes remembering corner cases and failure conditions > onto the programmer

Can you elaborate on this? I write go for 3+ years and I have no idea what corner cases and failure conditions do you mean.

<comment><USER4> A corner case about Go which makes me absolutely crazy: calling Reset() on a timer which has already fired has the biggest gap between "What I expect to happen" and "What actually happens" of any stdlib I've ever worked with.

[https://gist.github.com/patio11/bc883d566778c323742432c203e6...](https://gist.github.com/patio11/bc883d566778c323742432c203e69541)

(You can see it here in the playground, but try it on your local machine if you don't believe me and/or think the playground has an inconsistent understanding of what time actually means: [https://play.golang.org/p/ltdV9dI609](https://play.golang.org/p/ltdV9dI609) )

<comment><USER5> You never drained the longTimer channel, so when you say "We agree that longTimer has fired, right?"; that's not quite true. After you call Reset(), you're still getting the value from the first firing, because that's the first time you read from the channel at all.

The docs are quite clear on this behavior and say "Timer will send the current time on its channel after at least duration d." \-- key words being _at least_ and says nothing about when you choose to read from the channel.

<comment><USER6> It's even worse. The longTimer _has_ fired, and it sent a message on the channel just as it was supposed to. When Reset() is called, it causes a second firing and a second message. Here is the code, corrected to illustrate. The output times are exactly as one would expect.

[https://play.golang.org/p/lntgH6tkiF](https://play.golang.org/p/lntgH6tkiF)

</comment></comment></comment></comment></comment><comment><USER7> What we like to keep missing is that golang innovates not as a language, but as a tool to contribute to software project success.

Project success in the software industry is abysmal, and we still keep thinking we can spin up another language that will contribute to project success because it let's us express ourselves in new ways. Well, how's that working out so far?

The reason why golang appears to have such wide adoption in such a short period of time is that it really does seem to contribute to helping devs get their shit done. Massive amounts of working code are being written in golang, and that's good for the software industry as a whole.

Currently I run a massive project written in the standard issue kitchen sink corporate language (C#). It's got generics, functional extensions, all kinds of shit to make the most discriminating programmer happy. Well guess what, IMO C# for all it's features still doesn't serve the business of software dev as well as golang because it doesn't pull off what golang is brilliant at (easy to code for wide range of skill levels, easy to mentor, easy to test, easy to hire for). The result is difficulty finding productive devs, and a code base that is not up to my preferred quality standards.

This may be hard to swallow, but it might really be the case that you can get more quality work done with more devs if toolchain simplicity is emphasized over language features. If the evidence continues to bear this out for golang, then it's time for me to shed some language biases just so I can remain competitive.

<comment><USER8> Go has been around nearly a decade with the backing of none less than Google and yet it remains a fairly fringe language. Elixir is on a _much_ steeper adoption curve. So is Swift, but Elixir doesn't even have a tech heavyweight behind it.

<comment><USER9> Go 1.0 is released in March 2012 so it is not even half decade old.

<comment><USER10> You know Go existed before 1.0, right?

<comment><USER11> The question was about adoption curves, and i think version number is a signalling factor in adoption.

Pre-1.0 version number would certainly hamper adoption in my $DAYJOB.

</comment></comment></comment></comment></comment><comment><USER12> As some people like to point out, I'd also like to remind that in 1968 Algol had:

        - user defined record types
        - user defined sum types
        - switch/case statement with support for sum types
        - unified syntax for value and reference types
        - closures with lexical scoping
        - parallelism support
        - multi-pass compilation

Given that many mainstream languages don't offer even what Algo68 had, I personally understand how a Go developer might thing that "nothing is new under the sun" since the 80's. After all, Go ignores all progress in programming languages for the last 40 years.

I recommend watching "Growing a Language", a legendary presentation by Guy Steele: [https://www.youtube.com/watch?v=_ahvzDzKdB0](https://www.youtube.com/watch?v=_ahvzDzKdB0)

I do love the attempts of Go developers to rationalize Go's choices. But in the end it will end up being a hated language, universally recognized as a net negative in the industry. But that won't stop the working programmer from doing the same mistake again and again.

<comment><USER13> >After all, Go ignores all progress in programming languages for the last 40 years.

I've seen this meme being spouted so much every time Go's mentioned it's ridiculous.

No, piling up feature upon feature is not _progress_ otherwise we wouldn't be using anything but C++.

Go is a language you pick for the right situation. If it's not enough for what you're trying to do, go for a different one instead of trying to expand in the wrong direction leaving you with warts, like Java's done, C++'s done, Python, JavaScript etc... which you will have to end up avoiding in order to write performant and clear code, counting on luck not to have to deal with code that abuses those features to create anti-pattern upon anti-pattern.

<comment><USER14>
      >After all, Go ignores all progress in programming
      languages for the last 40 years.

      I've seen this meme being spouted so much every
      time Go's mentioned it's ridiculous.

Is it a meme when it is true? To support this question, witness the statements of Rob Pike[0] below.

\---

Regarding the utility of supporting first-order functions[1]:

      I wanted to see how hard it was to implement this sort
      of thing in Go, with as nice an API as I could manage.
      It wasn't hard.

      Having written it a couple of years ago, I haven't had
      occasion to use it once. Instead, I just use "for" loops.

      You shouldn't use it either.

\---

Regarding progress in programming languages[2]:

      One thing that is conspicuously absent is of course
      a type hierarchy. Allow me to be rude about that for
      a minute.

And[2]:

      Programmers who come to Go from C++ and Java miss
      the idea of programming with types, particularly
      inheritance and subclassing and all that. Perhaps
      I'm a philistine about types but I've never found
      that model particularly expressive.

\---

The part about "particularly inheritance and subclassing and all that" is ironically a meme spouted by Go's community so much it is, if you'll pardon my borrowing your description, ridiculous. For the curious, there are many community "Go-isms" explainable by the Pike talk[2].

Even a casual reading of the "list of significant simplifications in Go"[1] (35 in all) is enough to reasonably support the "ignoring all progress" position.

Of course, YMMV.

0 - [https://en.wikipedia.org/wiki/Go_(programming_language)](https://en.wikipedia.org/wiki/Go_\(programming_language\))

1 - [https://github.com/robpike/filter](https://github.com/robpike/filter)

2 - [https://commandcenter.blogspot.com/2012/06/less-is- exponenti...](https://commandcenter.blogspot.com/2012/06/less-is- exponentially-more.html)

<comment><USER13> > [1]:

I don't see how that helps your argument. For loops are more than enough for that task, it's easily readable and universal.

And Go does support first-class and higher order functions so not sure what you're talking about here.

> [2]:

How's ditching inheritance in favor of composition "ignoring the last 40 years"? It's the biggest example together with goroutines that proves that phrase is a meme, and that we've learnt a lot on typing best practices as an industry over the past couple decades.

And as an added bonus, another thing that's a good example of Go actually looking back and improving upon what's been done before is the select statement. Most popular languages fall through by default with the switch statement.

Outside of examples on the internet, I can't recall right now the last time I've seen a switch statement in the wild that didn't break at the end of every case. Making the case (pun not intended) for a fallthrough statement and having switch/select break by default.

</comment></comment></comment></comment><comment><USER15> The author is quite correct. Go is super boring, and runs fast. Two great points for it.

For me however I just never felt happy writing Go code. I have a couple of open source projects with it, so I have put it through it's initial paces to see if we fit.

The language that did make me happy was Elixir. Everything about the language and the surrounding tooling is polished. You end up with significantly less lines of code that's easy to understand.

Here's just one example from me - both examples scrape some info from HTML:

Elixir: [https://github.com/sergiotapia/magnetissimo/blob/master/lib/...](https://github.com/sergiotapia/magnetissimo/blob/master/lib/parsers/demonoid.ex#L36)

Go: [https://github.com/sergiotapia/gophers/blob/master/scrape.go...](https://github.com/sergiotapia/gophers/blob/master/scrape.go#L39)

You tell me which one is nicer to look at and easier to understand.

<comment><USER16> +100 Go is super boring and that it's a selling point. Code is a tool, not a device for entertainment. I'm yet to meet a 20+year developer who is wowed by extensive/unique/complex features, which makes me think as I also mature as a developer I'm going to find those things less important.

However, the Go version is way easier to understand. Mind you, I have very little experience with Elixir. In the interest of being pragmatic, the easier code is to understand, the easier it will be to maintain, and we spend much more time maintaining code than writing it fresh.

<comment><USER17> > Go is super boring and that it's a selling point. Code is a tool, not a > device for entertainment.

It is a balancing act.

As an industry we don't "do" training on work time.

So how do you convince developers to work on learning and development during their own time?

One way is to make the language fun and interesting.

> I'm yet to meet a 20+year developer who is wowed by extensive/unique/complex > features

20+ year devs don't like jumping onto the latest unproven technique/language. Don't mistake that for wanting few/limited features in a language.

20+year developers arent driving transitions to go. It is fairly new developers wanting to switch because it's cool, it's new, and it helps level the playing field by bringing experienced developers down a peg or two.

</comment></comment></comment><comment><USER18> So, Go is designed to be an engineering language and not an academic toy. Contrary to other languages, Go programmers "deliver" and have a pragmatic view of the _real_ development world, not just their own commits. Go programmers need a deeper understanding of computer science because other programmers are lazy and have everything given for free and probably don't need to know how it works.

A whole page discussing the virtues of Go by insulting people.

<comment><USER2> Go doesn't make real world programming easier. It makes you work hard for pointless things. Most of its problems are from a lack of generics.

<comment><USER19> It may be harder to _write_ some things, but it definitely is easier to _read_ Go code.

Besides, while the language itself may be more verbose than it could be, the standard library is extremely pragmatic and terse. It's like the opposite of the standard C++ library. E.g. to see if a string starts with another string in C++:

        std::mismatch(prefix.begin(), prefix.end(), toCheck.begin()).first == prefix.end()

In Go:

        strings.HasPrefix(toCheck, prefix)

The Go standard library is _full_ of things that do exactly what you want them to, whereas in other languages you have to manually do it yourself.

<comment><USER20> In your C++ example you're giving `std::mismatch`, which is a generic algorithm. If you're so inclined you could provide a wrapper that has the same interface as the Go example, but you're comparing apples to oranges. I'd argue that `std::mismatch` is much _more_ pragmatic than the Go example, in that I can use it to check any lists of user defined types.

In reality, these two methods do completely different things. `std::mismatch` is a completely generic algorithm that 'returns the first mismatching pair of elements from two ranges', which can be used for much more than `strings.HasPrefix`.

<comment><USER21> Did you read the article? The fact that there is 1 way to do it in Go, and 100 different ways to do it in C++ (or some other older language) is a feature, not a bug.

<comment><USER22> Where are the 99 other ways? I see one way to do this for any set of data types. Golang is the one with 100 implementations.

</comment></comment></comment></comment></comment></comment><comment><USER23> The article mentions a keynote speech by Rob Pike* from 2012 which is quite illuminating. The trade-offs made were all centered around google-scale and the pain points of such a massive operation. It stands to reason that people working outside of that environment may be less pleased with the language.

[*] [https://www.infoq.com/presentations/Go- Google](https://www.infoq.com/presentations/Go-Google)

<comment><USER24> Google is not the only entity that operates at scale, and simply because google does it does not mean it is the correct choice. That's kinda cargo cultish.

In distributed systems, go is fragile and dangerous -- because it will panic. IT has no supervision system, and it has the potential for deadlocks, in fact, unless you engineer around it, all coroutines and channels will produce deadlocks and can silently kill your program. When that happens you have no idea why things are broken-- nothings happening.

And this is a language without a decent debugger!

<comment><USER25> > In distributed systems, go is fragile and dangerous -- because it will > panic.

Do you know when it will panic? Do you know you can recover from panic if you for example want to communicate with other systems that this node is going offline?

> it has the potential for deadlocks

I could write that for most of languages that have mutexes. This is design problem, not language problem.

> When that happens you have no idea why things are broken-- nothings > happening.

It's only true if you do not know how to use debugger and don't know how language features you use works.

</comment></comment></comment><comment><USER26> > To provide any solution in Go that needs a dynamic data structure you can > choose between hand rolled linked structures or a Slice or Map (or compose > with them). As they are quite different the choice is normally obvious. > Contrast this to the choice between map, set, hashset, bag etc etc, or > rolling your own in a language that makes this a lot harder.

I can't help but think the whole article is filled with bursts of dishonesty.

A language like C++, which let you use the proper data-structure in about two lines of code, is _a lot easier_ when it comes to data-structures. While the Go programmer implements a multi-map, priority-queue or red-black tree, anyone else will have moved on to an actual topic of interest.

If you need a particular data-structure, surely having one ready in the toolbox is a net positive, not a negative.

</comment><comment><USER27> I'm not much of a Go programmer but I would definitely regard Go's multiple return and error handling (save the 'no assertions' clause) as very cool. I'm not sure if any other languages have experimented with that approach before the rise of Go, but to me at least it appears much saner than the prevalent ridiculousness of exception handling.

<comment><USER28> Some languages support tuples - you can also use stuff like ADTs to the same effect. I think Go's advantage here is that it's the _only_ way to handle non- panic exceptions, so you won't have systems where half of the errors are handled with exceptions and half with returning tuples, for instance...(I personally like the lack of "throwing exceptions" part, but find the multiple- return somewhat exotic)

<comment><USER27> Handling it as tuples is just as fine, but it's important that a language intending to do so be devoid of verbosity and cruft. For example, D supports tuples, but I would not want to attempt Go-style error handling in it: [https://rosettacode.org/wiki/Return_multiple_values#D](https://rosettacode.org/wiki/Return_multiple_values#D)

You make a good point, too, that multiple-return being the only way to do errors is more ideal than the language saying "oh, we support that, but we also have exceptions, too!" At least in a language with Go's philosophy, you can expect other people's libraries and your own code to play by the same rules.

</comment></comment></comment><comment><USER29> > Finally, in certain problem domains the power and flexibility of a hash-map > is also unavoidable, therefore Go provides a Map built in

Not a fan of this sentence. Why try to make it sound like Maps are unusual or bad? Just as fundamental as the list to real programming.

</comment><comment><USER30> > Custom data structures can be composed from the well understood builtins, > rolled in under 100 lines of code and can can exist close to the place they > are used (yes repeated!). The effect of this approach on readability, > maintainability, decoupling, ... adds so much more value to the whole > lifecycle, than the cost of the omission.

It's interesting to me that this philosophy comes from the Go designers at Google, and that Google is also well known for keeping vast amounts of source code advancing in lock-step in a single repository. From reading the recent article on Google's source code repository structure, I believe that being able to reuse code (e.g. data structure implementations) without versioning headaches is one of the intended and actual benefits. It's of course not that surprising that two different areas (Go design and repository structure) might pull in two different directions, but these are two important high level issues so it does seem a little inconsistent to me.

</comment><comment><USER31> > It is not 'missing' comprehensions, or inheritance, or generics, they are > omitted (and I pray, always will be). In some way, in the context of the > current fashion of returning to more functional languages, or the evolution > of good old languages to include more functional paradigms (I'm looking at > you Javascript and Python for two examples) then in a tenuous convoluted way > Go has 'innovated' by avoiding that trend.

That's such a weird statement. If anything, those are likely more OOP-related than FP-related, and he didn't really point out what's so bad about "more functional paradigms", besides the implication that it might be harder for new hires to pick up etc.

Anyways, I see that Go reduces the learning curve and simplifies lifecycle of huge projects, but at considerable costs about language features and expressiveness. I myself if working as a developer would rather not bear those costs just for the sake of the whole clogs of the organization running a bit more smoothly, and also so that myself would not just program day-in day-out en masse with everybody else out there in an overly simplified language that potentially puts me at more of a disadvantage in my career path. Maybe the leaders of huge companies would have other thoughts and there will definitely be developers who are happy to fill those roles, it's just not me.

</comment><comment><USER32> > "There is nothing new under the sun" rings true in all languages since the > 80's.

Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go.

Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to check an error result. This is a runtime thing you need to discover. Is this actually simpler?

Go made the decision to allow for Null, even after nearly every other modern language and other older ones are trying to kick it to the curb; Swift, Rust, Scala, Kotlin, no nulls (the JVM ones have a compatability problem, as does swift with ObjC, but still). Is it simpler to delay discovery of Null data to runtime?

Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Like lambdas, it can be a complicated concept to learn, but once you unlock this in you code, you write less code and accomplish more. So yes, it's simpler, but at too high a cost IMO.

To me the innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy. This is a million times better than JVM, Ruby, Python, Perl, etc. This is a huge improvement over Java, and something every language should have an option for. Ironically this is also the least innovative feature, because this is how static binaries in C and C++ have worked for years.

I think this article is very well written, but I don't think it's fair to the innovation going on in other languages.

(Disclaimer: I used Go, discovered the three primary flaws as I listed above, and then searched for a better language. It would be fair to call me a hater, usually I try to avoid this, but in this case that's fine with me)

<comment><USER33> >innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy.

Is rust the only good alternative here to golang if you one doesn't want to write c/c++ ?

<comment><USER34> OCaml and Haskell build self-contained binaries, and have done for decades. OCaml has very fast compile times, and an ordinary C-like linking system. You can even directly link C *.o files. Go certainly isn't "innovative" here.

<comment><USER35> And if you don't need types, there's LuaJIT with all the dynamic features, best inline C FFI ever done, runtime performance in par with native compiled languages, and tools for producing self-contained binaries if needed - [https://luapower.com/bundle](https://luapower.com/bundle)

</comment></comment></comment></comment><comment><USER36> The irony in all of these comments is that they almost all fall back to, or start with, discussing language design, and on the whole ignore the tools and processes that have a consistency from Go team to Go team. The value of this power and consistency is probably overlooked in this and many other conversations because they are complex to discuss, and it is simply easier to focus on the almost provable value of the language features, missing or present (maybe another availability bias at work?). The point of the article was to try and refocus on Go as an engineering tool in a much broader context.

</comment><comment><USER37> Accusing other languages of suffering from paralysis of choice and fragmentation and offering "go get" as an example of solving this is truly ironic: [https://github.com/avelino/awesome-go#package- management](https://github.com/avelino/awesome-go#package-management)

<comment><USER19> Why? `go get` is an obvious _default_ choice for package management. You don't have to make a choice.

There would be paralysis of choice if when you install Go you were forced to choose from that list, but you aren't.

<comment><USER38> I don't see how something that doesn't allow pinning versions can be an obvious default choice for dependency management.

</comment></comment></comment><comment><USER39> If you make a program that is executed a million of times or more a day, it make sense to have a language that is "near the CPU", and allows to optimize and speed up the most. This is what Go is. It will be a mistake to use it elsewhere.

<comment><USER40> C++, otherwise a deeply flawed language, gives you more abstraction than Go _and_ allows you to optimize and micromanage things more.

<comment><USER41> I love how C++ has had simple features like default arguments / function overloading for decades, while modern languages like Go and Rust require awkward workarounds.

Swift 3 looks good, though. They've learned the right lessons.

<comment><USER33> C++'s problem was never 'not enough features' it was precisely the opposite.

</comment></comment></comment></comment><comment><USER42> I'm not a Golang programmer, but the mere fact that GOOG decided Java for android is convincing enough that even GOOG does not believe in its Go.

(Frankly, I doubted that a little, until I realized Al-*-Go was not actually written in Go!)

<comment><USER43> Android predates Go. And it wasn't even started by Google.. Android was it's own company and had already made it's decision on Java well before Google decided to buy it.

Not to mention Go is focused on a different use case. Go is gunning for microservices (with it's concurrency chops) and CLI based tools (being a single compiled binary).. whereas Android apps are a totally different beast that stands little to gain from either of those. In fact shipping multiple binaries for different architectures is a bit of a detractor for Android considering it supports MIPS, ARM, and x86.

> until I realized Al-*-Go was not actually written in Go!

Again, AlphaGo was based off technology from DeepMind, a company Google acquired.

Please atleast do some quick wikipedia browsing before spewing FUD.

<comment><USER42> > Android predates Go...

So? Apple introduced Swift after Obj-C to make developing iOS apps easier. What about GOOG? Couldn't they at least use Dart or Go (both of which they developed) for android app development after Java? BTW, last time I checked, they're still in for a lot to come from Oracle.

> Again, Al-*-Go was based off technology from ...

So let me get this straight. They bought a technology which was apparently written in C++/JS and rewrote it in another lang, but then again, they did not choose Go or Dart.

Seems like some one needs a wikipedia browsing...</comment></comment></comment>


Crowdsourcing a real-time solution to air terrorism - <AUTHOR> http://markmaunder.com/2009/crowdsourcing-a-solution-to-air-terrorism/

<comment><USER2> "Give passengers a way to quickly and discreetly report suspicious activity to officials, both before boarding and during the flight. A button that simply reports suspicious activity within a 3 passenger radius may be all that's needed."

Yeah, then every time anyone with a thick beard boards a 747 they'll get 200 reports. That will solve the problem.

Also passengers who don't speak English is not cause for suspicion on a flight from Nigeria.

<comment><USER3> Never mind that the passenger in question attended University College London: He speaks English.

And if acting nervous on a plane is reason enough to move a person to the back of the plane to conduct a full-body search... well, let's just say the airlines had better have a significant rubber-glove budget.

<comment><USER4> No, they just reuse the rubber gloves. The security people at LHR doing the body pat-downs are a great example. I watched one sneeze all over his gloves, and then immediately pat someone down. Mmmm, body fluids...

<comment><USER5> So thereby it becomes clear who the gloves are protecting. Not the passengers.

<comment><USER4> It's funny because they are supposedly looking for (sharp?) syringes, but are only protecting themselves with a 1mm thick piece of latex.

</comment></comment></comment></comment></comment><comment><USER6> Why not post all the x-ray images on mechanical turk and give $1000 to anyone who can catch a weapon the TSA misses. That way we'll have an army of people trying to improve the TSA's awful success rate. I suspect the only reason we don't already do this is that it would expose the fact that the TSA catches only a tiny fraction of banned weapons.

<comment><USER7> No, you'll have an army of people falsely pointing out random shapes as weapons, hoping they'll win the lottery.

<comment><USER8> 3 wrong guesses and you are banned for 3 months.

<comment><USER9> Which would cause people to ignore things that _might_ be weapons.

</comment></comment></comment></comment><comment><USER10> _Yawn_

Another ineffectual "solution" to a problem that cannot be solved. The idea of some nosy, self-important passenger on a flight deciding who is and is not a terrorist is ludicrous.

</comment><comment><USER11> I think one reason that crowd sourcing works as well as it does on the web is because there is an actual crowd. What this article is referring to is more like "small group sourcing".

The benefit of the crowd is that there are generally enough people to counter act false alarms, prejudices, etc (not always, but generally). The proposed system would have only a few people one which to draw information rather than the hundreds, thousands or millions that these kinds of operations usually are deployed towards. Basing information on just a handful of people exposes many flaws that are generally evened out over actual crowds of people.

</comment><comment><USER4> Is air terrorism a problem? More people have died from the pilot flying the plane into the ground than have died in terrorist attacks. And that "more people" is "not very many".

</comment><comment><USER12> This seems to be a way to launder the racial profiling that we're unwilling to say we'll do through making the decision to profile diffuse among an arbitrarily large crowd of people who are not subject to feedback loops for doing it.

Phrased like that, I'm not sure if I oppose it or not.

Sidenote: This is a really good line: _[T]he TSA continues to treat passengers as self-loading cargo that may harbor a terrorist._

</comment><comment><USER13> This article was impossible to read on 1024x768 screen because the wrapping DIV was set to a width of 1000px.

Particularly irritating because it's a really interesting post.

<comment><USER14> Keep this Readability bookmarklet on your browser toolbar.

<http://lab.arc90.com/experiments/readability/>

<comment><USER13> I just changed the CSS with firebug, but thanks for the link

</comment></comment></comment><comment><USER15> You say Solution as if there's really a problem? What's the statistic, one incident for every 16m miles? The real problem is the culture of fear these kinds of ideas perpetuate, ie letting the "terrorists" win in their main goal, which is to increase fear.

<comment><USER16> Agree.

I'd put both words -- "the terrorists" -- in quotes. There definitely are individual terrorists in the world, but the notion of a unified red team of "the terrorists" has motivated a lot of bad decisions.

<comment><USER12> I've always thought that elements of the terrorist infrastructure -- plots, operatives, muscle, money, connections -- are sort of cloud-provided and available to pretty much anybody capable of implementing the API. Al Quaeda is sort of the 37 Signals of terror: they aren't the central nexus, they're a media-savvy early adopter whose core competence is marketing and have a happy little Italian restaurant-scale kill-the-Jews-and-Crusaders business, and they inspire people all over the globe to quit the day jobs, try a little lean jihad, iterate rapidly, and blog about the whole process.

Sadly the I in API does not stand for Interface and we are totally unwilling to discuss what it does stand for so War on Terror it is.

<comment><USER17> Does it stand for "Basque"? No, wait, that doesn't start with "I". Oh! "I.R.A." No, wait, that's itself an acronym. It's not FARC... no, hrm, not "Shining Path", either. And clearly not Aum Shinrikyo. Wait, waitwaitwait... you couldn't mean "Islamism", could you? But what about all the terrorist organizations that _aren't_ Islamist?

<comment><USER12> See, that is exactly why the War on Terror naming doesn't make sense (+). All of the above are terrorists (and contemptible), none of the above are even a remote threat to American air travel, and approximately none of our War on Terror related activities target them except incidentally.

</comment></comment></comment></comment></comment><comment><USER18> [http://upload.wikimedia.org/wikipedia/commons/3/39/Emblema_S...](http://upload.wikimedia.org/wikipedia/commons/3/39/Emblema_Stasi.svg)</comment>


The Introvert and the Startup - <AUTHOR> http://blog.iancackett.com/2015/10/10/the-introvert-and-the-startup/ <comment><USER2> Thanks for the share, rubikscube. Much appreciated!</comment>


2011: The Year of the Personal Robot? - <AUTHOR> http://www.scientificamerican.com/article.cfm?id=personal-robot-research

<comment><USER3> The PR2 robot seem to be overpowered and overengineered, making it cost too much.

I think the robot could do better by being easily producible by hobbyists and by using off the shelf component.

That being said, I am not an electrical engineer.

<comment><USER4> Agreed, no reason for this thing to have 8 core processors and insane amounts of RAM. It's not like this thing is sentient, there's only so much data to process.

<comment><USER5> I've done some work on image processing and read a substantial amount of literature, and nowhere have I seen anyone seriously trying to achieve sentience.

I have seen people using 30 node clusters where every node has roughly the processing power of this robot to track a ball with two cameras. Now, this was undergrad stuff and certainly could have been done better, but I'm sure the engineers who built this robot knew what it needed to do its job.

It's done as cheaply as anyone has done it up to now, which is important. Though it probably is still too expensive to be widely used, it sounds like a good step towards research to bring down costs to a reasonable level for consumer use.

</comment></comment></comment><comment><USER6> A common platform for robot development could really boost innovation in robotics. I smell disruption.

<comment><USER7> Sorry, there will be no disruption in personal robotics for many years. There have been articles proclaiming the year of the personal robot for at least a decade. The biggest problems in personal robotics are not computer hardware or software, but mechanical components and actuators. It still costs too much to build something that doesn't get boring after a week of working with it. Look at the Abio. It was beautiful but it got boring after a week because it couldn't do anything. Why not? Because it was too limited mechanically. If it was simply a matter of more computer power, there'd be people people hacking on more powerful processors and more memory, but there aren't. People want there $10K personal robot to be able to do something more useful than running a demo program. That requires power and robust and flexible mechanical system that can mimic what people can do. It may even require new materials (muscle wire, anyone?). Just my 2-cents.

<comment><USER6> It got boring because it wasn't part of a platform that could extend it - <USER2> be extended by it. It's like an operating system that only has a drawing program.

Edit: let's say the Aibo was an open sourced software plus blueprints for a 3D-printer. Anyone who wanted a "walking"-component for their robot could simply download it and build and extend it themselves. You could even run the entire thing in an emulator and then just press "print" when you wanted it in the physical world.

Now that _is_ disruption.

<comment><USER7> Yeah, we saw a lot of that happen with the Abio.

</comment></comment></comment></comment><comment><USER8> What about the Linux desktop :(</comment>


Show HN: Better Visualization for Pandas DataFrames - <AUTHOR> https://github.com/man-group/dtale <comment><USER2> This is a revolutionary tool for pandas data visualization. It integrates many data processing functionalities with visualization part, which really brings benefit to the end user. Thank you for creating this awesome tool !!!

</comment><comment><USER3> Nice. Looks like a great solution that I've seen many companies build internally. Glad you open sourced yours.

<comment><AUTHOR> Happy to do it! Please submit any features you'd like to see added :)</comment></comment>


The future of PHP, at a distance - <AUTHOR> http://pooteeweet.org/blog/0/2259 <comment><USER2> I think this is very true:

"There were a bunch of old devs opposed to adding this documented "processes", saying that "open source is about fun and processes kill the fun". But to me that was always shining through that argument was that there is always an implicit process and that process is usually ideal for the current people "in power"."

Jo Freeman has an essay called "The Tyranny of Structurelessness" which focused on how this issue (lack of explicit process) played out in left-wing political movements in the 1970s, and she does a great job of explaining how the lack of explicit process allows those with implicit power to keep control of things.

[http://www.bopsecrets.org/CF/structurelessness.htm](http://www.bopsecrets.org/CF/structurelessness.htm)

"Contrary to what we would like to believe, there is no such thing as a "structureless" group. Any group of people of whatever nature that comes together for any length of time for any purpose will inevitably structure itself in some fashion. The structure may be flexible; it may vary over time; it may evenly or unevenly distribute tasks, power and resources over the members of the group. But it will be formed regardless of the abilities, personalities, or intentions of the people involved. The very fact that we are individuals, with different talents, predispositions, and backgrounds, makes this inevitable. Only if we refused to relate or interact on any basis whatsoever could we approximate structurelessness — and that is not the nature of a human group."

</comment><comment><USER3> PHP related:

Sensio Labs (Symfony) announced a $7 million investment yesterday:

[https://sensiolabs.com/en/a_propos/communique_de_presse_fund...](https://sensiolabs.com/en/a_propos/communique_de_presse_funds.html)

More here:

[http://fabien.potencier.org/article/71/sensiolabs- raises-5-m...](http://fabien.potencier.org/article/71/sensiolabs- raises-5-million-euros-to-boost-the-symfony-ecosystem)

</comment><comment><USER4> The only advantage of using PHP in my eyes is: incredible cheap and hassle- free hosting for beginners. If you change something when introducing HHVM to the masses, then you would have a game-breaker.

If you can afford/achieve anything better than "drag'n'drop" your "index.php" there, and open your browser to "test if it works", do it.

Except, of course, you have to maintain tons of legacy stuff already written in PHP.

<comment><USER5> > _The only advantage of using PHP in my eyes is: incredible cheap and hassle- > free hosting for beginners._

Well, clearly the engineers working on Facebook's PHP (and several other large projects, from Yahoo! to Wordpress.com) aren't "begineers" neither looking for "cheap, hassle-free hosting".

I don't buy the "it's so crap, it's ONLY used because of cheap hosting" argument.

It's also a pragmatic language, with tons of libraries and features for web use.

So, it might be far from perfect, but than again, Javascript is far from perfect too, C++ is also flawed and Java has tons of bad decisions in its design (and culture). Still, those are some of the more widely used languages.

<comment><USER6> > So, it might be far from perfect, but than again, Javascript is far from > perfect too, C++ is also flawed and Java has tons of bad decisions in its > design (and culture). Still, those are some of the more widely used > languages.

Still, I wouldn't take a job in any of them. Javascript is crap, only used because it runs in the browser. C++ is pretty crap, only used because it has manual memory management. Java has its problems, but it has a decent design at least for the time; there is a terrible culture that I think adopted Java because it was popular rather than the other way around.

But yeah, in 2013 there are really much better languages than PHP available; if you want a similar-feeling replacement Python or Ruby are much saner, if you're willing to step further afield there are wonderful modern languages that push the boat a bit further (I'm in love with Scala at the moment).

<comment><USER7> Define 'better'. Personally I think Clojure has a lot going for it, and it's better than a lot of languages in a many ways. However, for the kind of application I work on PHP is significantly better fit than Clojure. Most of the points made in this talk apply to my situation. [http://www.infoq.com/presentations/php- history](http://www.infoq.com/presentations/php-history)

<comment><USER6> The main "better" I care about is "fewer gotchas and special cases to memorize"; that's not the only thing that matters about programming languages, but it's a big factor. I don't have time to watch a 40-minute video; arguments I remember hearing from something similar are the very fast coding feedback cycle (easy with modern-day rails/django/etc.), "it's better than it used to be" (not really an argument), availability of frameworks (but I've never seen an actual example of the advantages that you don't get in other languages/frameworks), large standard library (again, present in other languages), dependency management (which seems more like php catching up with other languages than overtaking them), deployment (may have been a good argument in the pre-wsgi days and when Apache was the only webserver around, but not true any more IMO). What is it you see PHP as better than ruby/python at?

<comment><USER7> Well firstly the gotchas very rarely get me. I found the same with Javascript. The inconsistent and odd data conversions make fun slides to denigrate the language, but in practise they seem to be easily avoided.

I realize posting a 40 minute video to support my point is a bit lazy and unfair but you seem aware of some of the key points fortunately.

First let me admit that we have a php legacy codebase, so porting that to another language, even if we had a strong desire too would probably be prohibitive.

I definitely feel super productive in PHP. I've been able to knock out a new app feature in 1 day, which to build the equivalent in Java would have been at least 5. It's very easy to write code fast, and then come back and refactor it later. Using PHP Storm as an IDE with a very good debugger and PHPUnit to build a suite of tests for everything we do means that gotchas are always eliminated before production, and with PHP I find things are either working or completely broken with not much in-between.

I guess having a strong unit test suite, or really it's more of an acceptance test suite, is something you can do in most languages, but the assurance it gives us enables us to share large code bases between teams, doing frequent merges of features. You can have large numbers of programmers with varying abilities and even programming styles hitting the code without too much headache.

The talk also mentions state. Not sharing state between requests except explicitly. You don't have to worry about complicated background threads, resource leaks, memory leaks. Even crashes are less of a big deal since you just lose one request to it, not the whole server like with Java et al.

PHP's array is a swiss army knife with lot's of useful functions for transforming data, which is a lot of what we do on the server. I can map, reduce and filter data. I can dynamically handle arrays or single objects in the same function, or handle arrays of different kinds of data without any fuss. In short going from what I want to happen to having it happen is very fast.

Background tasks are queued and run on other systems including some written as bash scripts or in Python, Go and node.js. These languages are a better fit for these jobs and so we ditch PHP for those.

What Facebook is doing with HHVM (run faster) and Hack (add type safety as needed) is pretty interested and we've adopted the first but not yet the latter.

Hopefully that's flavour of what I like about using PHP. I have not written more than a few lines of Ruby so I cannot comment on that. I have done some maintenance work on a Python server but not with a modern framework. I'm not sure Python with a modern web framework offers all of the advantages I've mentioned above but I am open to being enlightened on that.

<comment><USER6> > the gotchas very rarely get me. I found the same with Javascript. The > inconsistent and odd data conversions make fun slides to denigrate the > language, but in practise they seem to be easily avoided.

They don't tend to actually "get" me, but I feel like they're always there in the back of my mind, taking up space that could be used for something more useful. It's not a huge difference, but it's there.

> I definitely feel super productive in PHP. I've been able to knock out a new > app feature in 1 day, which to build the equivalent in Java would have been > at least 5.

Well sure, we're talking about a very different style of language. But I think Ruby or Python get you the same thing. Certainly you have map/reduce/filter (and Python's for comprehensions go one step further), and dynamic typing.

> with PHP I find things are either working or completely broken with not much > in-between.

Interesting; what bothers me the most when using PHP is that it feels easier to introduce security flaws than other languages. Not that it's _hard_ to code safely, but sometimes the most obvious way to e.g. access a database is the unsafe way (which is partly just because there're a lot of old libraries and bad advice floating around). Charset handling is a similar area; I've seen lots of PHP code that appears to work fine but goes wrong when given non-ascii characters. It wouldn't surprise me if there were similar issues with timezones, though I haven't dealt with them enough in PHP to be sure.

<comment><USER7> > Interesting; what bothers me the most when using PHP is that it feels easier > to introduce security flaws than other languages. Not that it's hard to code > safely, but sometimes the most obvious way to e.g. access a database is the > unsafe way (which is partly just because there're a lot of old libraries and > bad advice floating around). Charset handling is a similar area; I've seen > lots of PHP code that appears to work fine but goes wrong when given non- > ascii characters. It wouldn't surprise me if there were similar issues with > timezones, though I haven't dealt with them enough in PHP to be sure.

Well in my case we work on mobile apps so the client doesn't do anything unexpected with respect to character sets and time zones. Probably that's harder when working with random web browsers. Security wise I agree with you it's easy to do wrongly, especially with the simple DB API's that can be used naively.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> "Also what about windows users, still a very significant portion of the PHP user base?"

Yes, especially during development. I am toying w/ a PHP implementation on top of luajit, written in PHP so it may be more hackable and bootstrapped.

The real problem is PHP fails to define a specification that implementations can follow (though they probably weren't prepared for the current situation). Sadly the runtime becomes the spec, and with such a large standard library, it's hard to predict what happens in dynamic languages when you send in something undocumented. In order to work w/ the myriad of PHP projects out there, unfortunately you have to mimic the undefined aspects.

We are headed towards a more fragmented PHP than we already have. I've had enough problems changing PHP versions (regressions and undefined standard function changes), now with HHVM, you will have one more fragmentation piece. I'm all for different implementations. The saving grace I've found is all the language phpt files (but doesn't help w/ parsing and many compile-time errors).

<comment><USER9> Do you have a blog, or do you intend to put it on Github?

A PHP parser written in PHP that generates bytecode for LuaJIT or HHVM's JIT- runtime would be cool. I was thinking about this too. And it would be fun to hack around :)

FB's HHVM JIT and its bytecode format "hhir" is explained is the following recent blog post: [http://www.hhvm.com/blog/2027/faster-and-cheaper-the- evoluti...](http://www.hhvm.com/blog/2027/faster-and-cheaper-the-evolution-of- the-hhvm-jit)

LuaJIT2 and DynASM: [http://luajit.org/](http://luajit.org/)

[edit:] I found your repo: [https://github.com/cretz/meh](https://github.com/cretz/meh) ...interesting, I am reading the code atm

</comment></comment><comment><USER10> From my understanding, if the day ever comes where the official PHP engine is switched to HHVM, it would catapult performance past Python and Ruby in pretty much all scenarios.

<comment><USER11> Predicting the future is risky.

HHVM exists. You can benchmark it against Python and Ruby today. What are the results?

In any case, Python has things like cx_freeze that can be used to make apps close to compiled performance. And Python is not a single monolithic implementation. IronPython running on .NET for instance. PyPy has a VM with JIT.

In any case, few people these days are worried about raw performance of apps. There are easier things to fix with page load times, getting rid of resource locking, and so on.

HHVM will extend PHP's useful lifetime but outside of Facebook, Drupal-based sites, and WordPress-based sites, I don't see it growing in any significant way.

<comment><USER12> cx_freeze just package python apps so you can distribute them like native apps, that is without requiring the installation of the python interpreter. It doesn't impact performance.

Performance oriented pythonners go with pypy, numpy, cython, numba, etc. Each of them gives a very significant speed boost.

</comment></comment></comment><comment><USER13> Kinda wish they would drop backwards compatibility once in a while.

I get why they don't but that's why PHP is just the most popular mediocre language.

There should be scheduled non backwards compatible releases for every language (say every 10 years) that's the only way they can improve and not just get replaced when better ones come along.

<comment><USER14> Python did that, and now everyone loves to hate it.

<comment><USER13> I like Python3. They fixed all the inconsistencies in the language.

Sucks that some people are still stuck with 2.7 but it's definitely worth upgrading if you can.

</comment></comment></comment><comment><USER15> Not at all related to the post and/or content, but that domain name is awesome.

</comment><comment><USER16> The latest HHVM update has seen CPU usage reduced by 20% across Facebook. I wonder how many thousands of servers that works out to.

</comment><comment><USER17> In what universe does Python and Ruby's alternative implementations have significant market share?

<comment><USER18> In the real universe we live in, JRuby, at least, has fairly wide adoption, and YARV, which started out as one of the alternative implementations, _became_ the mainline implementation (and, at least for a while, it was widely speculated the same thing would eventually happen with Rubinius.)

</comment></comment><comment> e-tron before bashing php about perfomance(to python ruby users)..

Lets have some data. for python users ([http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=php&lang2=python3&data=u32))

for ruby users {[http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=php&lang2=yarv&data=u32)}

</comment><comment><USER19> google app engine now supports PHP and they completely reimplemented the language. it is extremely fast and seems to already do all the things this story eludes might happen.... they already have.

<comment><USER8> They did not completely reimplement the language, it appears to be the standard implementation. Compare [https://github.com/GoogleCloudPlatform/appengine- php/tree/ma...](https://github.com/GoogleCloudPlatform/appengine- php/tree/master/php-src) to [https://github.com/php/php- src](https://github.com/php/php-src)</comment></comment>


Why does PayPal have so many bugs and security issues? - <AUTHOR>

I don't know a single big player on the web that has similar amounts of bugs and security issues as PayPal -- not even close. Why is that?
* They have issues with their sign-in window opening in a pop-up/dialog instead of a new tab/window. [1]
* When I received money in a foreign currency recently, it didn't appear in my PayPal dashboard. I had to talk to three PayPal employees on the phone support before the fourth told me this was apparently a bug. All my settings were correct but I had to add an additional balance in the foreign currency, temporarily, to receive the money. Actually, I should be asked what to do with the foreign-currency amount (create new balance, convert, etc.).
* I'm using two-factor authentication and it's just annoying: On their main site, I can sign in, that's fine. On other pages, they just ask me for the 2FA token from my token generator (which I don't have) and don't offer the SMS verification which should be there, too. Somestimes I have to disable 2FA completely before I can perform certain actions.
* Until a few days ago, you could capture CSRF tokens that were valid for all accounts, not just your own. [2]
* They have XSS vulnerabilities from time to time. Okay, lots of sites have those. If you don't escape by default, this can happen, although it shouldn't. [3][4]
I know, big legacy code base. But other companies have similar challenges. PayPal wants to work with your money, they should be as least as good as Twitter, Facebook, Github, and hundreds of other sites that work better.
[1] http://homakov.blogspot.de/2014/12/new-paypal-gateway-ui-is-disaster.html [2] http://www.theregister.co.uk/2014/12/04/paypal_csrf_bug_bounty/ [3] https://nakedsecurity.sophos.com/2013/05/29/paypal-refuses-to-pay-bug-finding-teen/ [4] http://www.forbes.com/sites/firewall/2010/10/06/hackable-bug-found-on-paypal-com/ <comment><USER2> * PayPal is the most comprehensive payment integration solution on the Internet. That brings a lot of complexity.

* They also make money on relatively low fees. That requires good cost controls.

* They're no longer a prestigious company to work at. They pay a bit higher than standard because it's harder to recruit talent.

* Once you get to a certain size and complexity, especially in the financial world, changing things becomes terrifying.

</comment><comment><USER3> I've wondered this myself.

My hunch is that an unusually large amount of the their talent/engineering resources are tied up fighting fraud and abuse...leaving a skeleton crew to do all things front-end.

Again, just a hunch though.

</comment><comment><USER4> I remember the days when David Marcus was the CEO, then he left the company, and now they are finally planning a break-up from eBay.

</comment><comment><USER5> Two reasons, to me:

* "Move fast and break things" mentality that made it big is now making it bad

* Peter Thiel isn't as much of a genius as he thinks he is (although he is pretty smart in some respects, sometimes he's completely wrong, akin to some modern-day Aristotle) and the attitude of the founders of a company creates the culture as it grows

<comment><AUTHOR> The first may definitely be true, i.e. their legacy code base may be a heavier burden that some other companies'.

Don't know about Peter Thiel, if there's still influence on today's work. Anyway, it's mostly programming, implementation, craftsmanship which seems to be so bad.</comment></comment>


Submitting Changes to Voter Registrations Online to Disrupt Elections - <AUTHOR> https://techscience.org/a/2017090601/ <comment><AUTHOR> Periodic reminder that attacks on physical voting don't scale.

But attacks on computers and networks do.</comment>


The Man Who Got No Whammies (2015) - <AUTHOR> http://priceonomics.com/the-man-who-got-no-whammies/ <comment><USER2> Discussed at the time: [https://news.ycombinator.com/item?id=10216338](https://news.ycombinator.com/item?id=10216338)

A related thread: [https://news.ycombinator.com/item?id=9570713](https://news.ycombinator.com/item?id=9570713)

Links to the 2003 documentary mentioned in past threads are now dead, but it is here: [https://www.youtube.com/watch?v=o75teVHwkT8](https://www.youtube.com/watch?v=o75teVHwkT8)

</comment><comment><USER3> It's funny how a picture of him has the caption "Michael Larson was never interested in following the rules" when, actually, he was the only one who bothered to figure out the rules.

<comment><USER4> Michael's run on PYL is often called a "scandal" as if he cheated. The only scandal was that CBS tried like hell to figure out a way to deny him his winnings.

<comment><USER5> Where do you fall on the Phil Ivey edge sorting incident?

<comment><USER6> Not OP, but Ivey didn't touch the cards or use any kind of technology to win. That's not cheating. He should be paid.

<comment><USER5> Is there a set of people between "Casino might have a point and certainly it's their right to pursue the issue in court" and "Ivey found a loophole in your system, suck it up you cry babies."?

<comment><USER6> I don't know, but it's likely they also freerolled him. As in, they decided not to pay him if he won, but let him keep winning in case he lost. He could easily have lost a few million, his edge wasn't that big.

I think they're the sleaze.

Anyway the matter is settled, not in Ivey's favor. The fact that Ivey isn't in prison should settle the debate over the legality of what he did.

</comment></comment></comment></comment></comment></comment><comment><USER7> The article keeps making it sound like he met his comeuppance, even as they finally reveal that he ran off with $3M and died of natural causes before he was caught. They never seem to substantiate the pervasive tragic tone. The whole whole thing reminds me of the existentialist treatment of the "Touch of Death" in _Men Who Stare at Goats_... His schemes were often successful, but ultimately meaningless because death comes for us all?

<comment><USER8> Yeah, it doesn't really seem like he had a downfall, besides dying, which isn't exactly an unexpected event for any person..

<comment><USER9> Well, dying at the age of 50 to throat cancer is not exactly on my list of expectations for life.

<comment><USER10> yeah but the throat cancer doesn't seem to have come out of some scam he was pulling. So he didn't really get his comeuppance from the throat cancer in the way people normally use the term.

</comment></comment></comment></comment><comment><USER11> This is such a fun story. It's how I commonly introduce common folk to the importance of true random numbers in cryptography. Glad to see it come up here again.

</comment><comment><USER12> >"He didn't understand the value of good, hard, honest work," his older brother, James, later bemoaned. "He thought those people were fools."

I wouldn't call people like that fools, and pretty certainly the world would fall to pieces without them. That said, I don't think I can really blame anyone too much for not valuing good, hard, honest work in this world where many people are simply born rich and many others become rich by gaming the system and/or screwing people over.

<comment><USER8> What is good, hard, honest work, exactly? I certainly work hard, but is it honest? I'm not sure. I certainly don't intentionally go around breaking all the rules I can, but I do try and use my brain to figure out every possible loophole and advantage I can. I don't think exploiting loopholes is dishonest, but I'm sure some would disagree.

For example, when playing board or card games, I always try and discover some dominant, completely broken strategy that is definitely not in the "spirit" of the game. Some people have gotten very angry at me because of this, but isn't this how games are supposed to be played? The same applies to life, I think.

<comment><USER13> Maybe this is a necessary evil in a day and age when a society is not all on the same page with respect to morals and values. It sure would be nice to have everyone proactively choose to act in a way that matches the "spirit" of the law or rules, and maybe this did used to happen in more homogeneous/authoritarian societies? But without that synchronization it seems to fall to the legislative bodies to codify as much as possible of the various moral behavior which is very hard in practice and easy to exploit.

This is hard to discuss with precision because there is a lot of subjective judgment involved. Cutting lines is not against the law, so should you do it to avoid wasting time waiting? Occasionally a rightmost lane is in practice used mostly for right turns, but marked as both straight and turn. Majority of people seem to understand it's a jerk move to block that lane for the turning traffic, so it's usually empty, but every now and then some greedy SOB takes it to overtake the herd. Personally I find this kind of thing despicable and do what I can to prevent it.

I'm sure there is some evolutionary biology connection to fairness and why we behave/feel this way.

<comment><USER14> > It sure would be nice to have everyone proactively choose to act in a way > that matches the "spirit" of the law or rules, and maybe this did used to > happen in more homogeneous/authoritarian societies? But without that > synchronization it seems to fall to the legislative bodies to codify as much > as possible of the various moral behavior which is very hard in practice and > easy to exploit.

I suggest you read into the history of common law as it pertains to the history of legal practice in the UK and many of its former colonies. It is still strong today in both the US and the UK, though I am not familiar with other commonwealth nations.

In a common law legal system, laws are discovered through trial rather than ordained by legislation. Precedent is built through case law.

This is a system that is all about the "spirit" of the law.

</comment></comment></comment></comment><comment><USER15> A documentary on this story: [https://www.youtube.com/watch?v=o75teVHwkT8](https://www.youtube.com/watch?v=o75teVHwkT8)

</comment><comment><USER16> The attention it brought to the game show may have been worth more than CBS paid out. They quickly changed the game mechanics so it couldn't be so easily exploited a second time which made it a one time cost. Wonder if there was a ratings boost after the episode, even if short lived.

</comment><comment><USER9> The Man Who Got No Whammies*

Technically he did get one Whammy.

</comment><comment><USER17> If you watch the actual show, he did, in fact, get a warranty on the first spin. Didn't affect him though, as he didn't lose any money to it.

<comment><USER18> That's mentioned in the article</comment></comment>


Now It's Just Getting Ridiculous - <AUTHOR> http://daringfireball.net/linked/2011/10/17/samsung-galaxy-player <comment><USER3> I love the Snickers bar ad placement, as if it's trying to cover up the fact that that screenshot is fake.

But seriously, why do companies have to do this? Aren't they proud of the products they create? Why can't Samsung grab a screenshot of Android's own Maps app? Or is this a slash at Apple because of their lawsuit?

</comment><comment><USER4> The stupidest thing about this is that the maps on Android are genuinely better than the maps on iOS.

</comment><comment><USER5> I think Samsung is a great company. However, I think they really need to innovate and compete fairly.

</comment><comment><USER6> South Koreans are known for copying great products and launching them cheap most of the time. I see this here all the time..This includes most of the big time Korean players in all segments...It's not just the chineese but the koreans are good at copying too

</comment><comment><USER7> For those who can't actually open the page on the samsung site (like me - <USER2> get redirected to "Select your country" page) try the google cache version.

<http://goo.gl/cThfH>

</comment><comment><USER8> What does the original look like?

<comment><USER9> <http://www.flickr.com/photos/28263608@N00/3108550313>

Wow. They lifted another bloggers screen shot.</comment></comment>