Best practices for a new Go developer - <AUTHOR> https://medium.com/@IndianGuru/best-practices-for-a-new-go-developer-8660384302fc <comment><USER2>
        > You will realize eventually that what you first thought
        > was worth criticizing was actually a deep work of
        > genius.

Funny, I found the more I used it the less I liked it.

        > I've seen a lot of criticism of Go's "shortcomings"
        > from people who are true experts in many languages
        > other than Go.

Cool, normally I just call those people "experts".

        > I can't recall similar criticism from someone who's
        > worked with Go at a very deep level for a year or two.

You would do well to understand the meaning of the term "survivorship bias".

<comment><USER3> The thing about Go is that some parts, like channels and goroutines (also some of the library designs and tooling), are so addictive that pretty soon it gets hard to imagine ever having to live without them.

But I don't think everyone using Go really believes or supports this "but in practice it's not a problem and if it's a problem then the problem is YOU!" kind of response to every criticism.

We live in a world of trade-offs. It's disingenuous to act like that wasn't the case.

<comment><USER4> _The thing about Go is that some parts, like channels and goroutines_

I have written a fair share of Go now and have only rarely used channels or goroutines. In practice, channels are only a good model for a subset of concurrency scenarios and they come with problems.

Also, those criticizing Go are right (of course). No amount of Go usage will alleviate its shortcomings. The lack of parametric polymorphism is incredibly annoying, error handling is mediocre (Rust handles this much better), and the lack of support for even simple abstractions (algebraic data types) is jarring.

Nonetheless, I continue to use Go, because they also got a lot of things right: compile times, tooling, a very-well documented standard library, good compatibility between 1.x releases, a UNIX feel, low-barrier entry for other contributors to Go projects, and a thriving ecosystem for a relatively young language. (Of course, the JVM and Java do as well on these points, except for UNIX-feel.)

<comment><USER3> Where goroutines have helped me a lot is with networking code. The part of the system I'm writing in Go controls several instances of three different kinds of networked services, plus one command line tool.

There are hundereds of tasks that request access to these services. The job of my Go code is to schedule, rate limit and coordinate access by these tasks to the network services.

I did parts of it in C++ initially (because other parts of the system are written in C++) using queues and timers (could have done the same in Java) and then I rewrote it in node.js but wasn't happy with the asychronous design or with my productivity.

So I think the reason why goroutines and channels have helped me so much is specific to this kind of project. Go's other language features (or lack thereof) wouldn't have enticed me into taking a closer look. But now that I have taken a closer look, I do like the library and tools a lot as well.

To sum it up, if a program is basically a ton of loops doing blocking reads and writes that depend on each other, then goroutines and channels make the code look very similar to the idea. Mental load drops. Life is easier.

</comment></comment></comment></comment><comment><USER5> > Because Go gives us interfaces and closures we can write much more elegant, > generic APIs with a flavor similar to Ruby or Lisp and this is the direction > the language naturally wants us to take. Personally I like to use the empty > interface for plumbing and only pin things down to specific interfaces or > concrete types where I need to for performance or correctness.

That's a lot like using opaque pointers in C. What is it about Go that makes people assume it's shortcomings are beautiful designs?

I learned yesterday that `x == nil` can return false _even if x is nil_ so long as x is an interface type. But it depends on whether x is _actually_ nil or a nil value with a specific type.

(╯°□°)╯︵ ┻━┻

My other pet peeve is that a method with a non-pointer receiver that tries to modify the receiver object will silently drop those modifications on the ground, because the object is copied. Which makes some sense, except that Go likes to convert to pointer receivers automatically, so the caller can't tell that anything is wrong. The only difference is one character in the method definition. Everyone I know hits this bug at some point and loses half an hour before they learn to look for it. You could almost say "all method receivers must be pointers" except that you need to refer to interface types without the pointer.

(╯°□°)╯︵ ┻━┻

<comment><USER6> Go's simplicity is merely syntactical. The semantics can be subtle and not entirely aligned with intuition honed after x years of working with C-like language X.

This is an observation and not a critique.

> I learned yesterday that `x == nil` can return false even if x is nil so > long as ...

In other words:

[http://play.golang.org/p/YV5ylbQN4j](http://play.golang.org/p/YV5ylbQN4j)

Thanks for the heads-up! That was news to me.

<comment><USER7> Actually, the issue mentioned by the OP is covered here:

[http://golang.org/doc/faq#nil_error](http://golang.org/doc/faq#nil_error)

Basically, if you pass 'nil' of one type into an argument which accepts an interface of another type, the nil is no longer nil, but an interface wrapper around a nil (which is not nil).

So:

        var buf *bufio.Reader // a nil value

if this is passed into a function with a signature of

        func foo(buf io.Reader)

then when in function foo:

        foo(buf) // valid, and buf is nil here

        //inside foo:

        if buf != nil { // but buf is not nil here, so this is true
            buf.Read() // Panics because nil has no function Read.

<comment><USER8> The post you were replying to was talking about whether the behavior is _intuitive_ , not whether it is documented.

</comment></comment></comment></comment><comment><USER9> I'm not interested in C++, not using it, do not care about it. So, I am neither visiting HN links that are about C++ nor taking part in discussions related to C++.

And I'm really curious what drives people in this thread that are coming to say they do not want to use Go, do not like it, and stuff like that?

<comment><USER10> Go's surge in popularity — and with it, the surge of evangelism — compels people to take a stand, for better or worse. (If Go weren't popular, nobody would bother.)

I suspect it's also partly due to Go's curious mix of maturity and immaturity, in an overall promising package with lots of momentum. Here's a young language that on the one hand is productive to work with and simple to understand, yet so obstinately awkward and inelegant in several other respects, and represented by a team of designers who aren't always saying what many want to hear.

It's clear that Go was, first and foremost, designed for Google and their need for a natively-compiled, concurrent language that steers the user to a very specific path, largely defined by _limitations_. Its approach prevents language-theoretic cleverness that can complicate a codebase (think Boost or the STL), and it prevents a lot of foot-shooting and optimistic overdesign that newbies are prone to.

But while that's wonderful for Google, that's also a frustrating to developers who don't need this invisible hand hobbling them, and sees Go's potential subverted by the stringent design principles. I admit I'm one of those frustrated by Go's type system, for example, or its heavy-handed approach to error handling.

Part of the frustration is the lack of a clear alternative: Nimrod doesn't have the mindshare, Rust is overly complex and slow to compile, Elixir doesn't have the performance, C++ is, well, C++. Go, for better or worse, fills a kind of sweet spot that, unfortunately, also has a dash of sour. And that kind of frustration easily leads to debate whenever Go comes up.

<comment><USER11> Lack of alternative++. Python is too dynamic and slow, gradual typing will help but it's still slooooow. For web work, PHP and Hack are popular but often very amateur, node.js works best with microservices and can quickly become difficult to manage. Clojure, Scala, and Java suffer from idiosyncrasies around the JVM. Clojure's lispy syntax can be a drag, Scala gets very complex very quickly, and Java is oh-so-verbose.

C# is about as close as it gets to the sweet spot in the middle, IMO. But .net not being a first class citizen on all platforms kills that option. Yikes.

<comment><USER10> Agreed on all points. C# does indeed look like it hits the sweet spot, at least in terms of feature set, but I wish it were wholly independent of .NET. Also, certain ugly Windowsisms have snuck into the language, such as CapitalizedMethodNames (but snakeCaseVariableNames, for some reason).

A whittled-down, cleaned up Scala without the JVM might also have hit that sweet spot.

I'm hoping Swift will be a contender once it's open-sourced and becomes multiplatform.

</comment></comment></comment></comment><comment><USER4> _Learn about stack versus heap, and recognize that Go treats the stack differently from other languages._

Note that the Go language spec does not even contain the terms 'stack' and 'heap. Whether something is stack or heap-allocated isn't always clear. E.g. consider:

        foo := &Foo{} // or: new(Foo)

This could be stack or heap-allocated (in the most popular Go implementation) depending on whether the compiler thinks it escapes or not.

<comment><USER8> > Learn about stack versus heap, and recognize that Go treats the stack > differently from other languages.

Yeah, this comment strikes me as deeply confused. Go does not give you precise control over what goes on the stack versus the heap: it's even in the FAQ.

There's a common misconception that stack vs. heap and value types vs. reference types represent the same distinction; they do not. For example, note that it is possible in unmanaged languages to have dangling references into the stack.

<comment><USER12> Unless I'm mistaken it is technically true though, AFAIK other languages fall in two broad groups

* heap-based languages (vast majority of the high-level ones), everything is treated as heap-allocated, may be stack-allocated as an optimisation (while ensuring/conserving heap semantics)[0]

* stack/heap languages, strict semantic separation between heap allocation and stack allocation, the developer decides whether values get heap-allocated or stack-allocated

Go has the semantics separation of the latter (whether something is heap- allocated or stack-allocated had strong semantic significance and is not dependent on the thing's type) but the control of the former (the runtime decides and doesn't tell you)

[0] a subset of these languages may have "value types" which have stack allocation semantics, that's linked to the type itself and the semantics are stable

<comment><USER8> To use your set of categories, Go is a fully heap-based language. Everything is semantically on the heap. Stack allocation semantics have to do with when the object is _destroyed_ , which Go does not have any way to control in the language. Value vs. reference types are totally orthogonal. To see how this is true, try creating a value type (such as a struct or an array) in Go and capture a reference to it in an (escaping) closure to defeat the escape analysis optimization. The object will definitely be allocated on the heap.

<comment><USER12> The issue I was referring to is is if you don't

> capture a reference to it in an (escaping) closure to defeat the escape > analysis optimization.

the object absolutely doesn't behave as a heap-allocated value. So everything is _not_ semantically on the heap.

<comment><USER8> Three points:

1\. There are many other things that can cause escape analysis to fail. You can also capture references to a value in an opaque function, send it over a channel, etc. etc.

2\. There is no _semantic_ difference between stack and heap (modulo when finalizers run). The only thing the language says is that object is guaranteed to be destroyed when it is no longer referenced. The compiler can fulfill this obligation sometimes through stack obligations, but that's done through a set of heuristics. The _language_ says nothing about this (and the FAQ states this quite explicitly).

3\. Java does the same thing. The HotSpot JVM will use escape analysis to perform SROA (which is an important optimization). Note that escape analysis is _independent_ of value vs. reference types; Java has much fewer value types, but it can _still_ do escape analysis. This is because value/reference and stack/heap are orthogonal.

</comment></comment></comment></comment></comment></comment><comment><USER13> I was hoping this article would have more substantive advice for new Go developers. It seemed to mostly have very general advice that applies to most other languages like: "Don't try and write language X in language Y. Keep complexity down by not over using complex language features."

I'm writing my current hobby project, a podcast fetcher, as my first project in Go.

The project has been going generally well but there have been a few annoyances so far:

* Why are you not able to easily version git dependencies? Go's solution to this problem is to tell you to create an entirely new git repository for each major version. Really? If they didn't want to go full blown dependency versioning with something like CocoaPods, they could at least let you specify a git branch or tag.

* The db.Sql abstraction does not support multiple result sets. Therefore database drivers, like the popular mysql driver, don't support multiple result sets. This really limits the kinds of stored procedures you can call.

* The debugger support is bad. I have to fall back to using print statements for most of my debugging.

<comment><USER14> > Why are you not able to easily version git dependencies? Go's solution to > this problem is to tell you to create an entirely new git repository for > each major version. Really? If they didn't want to go full blown dependency > versioning with something like CocoaPods, they could at least let you > specify a git branch or tag.

Take a look at gopkg.in[1]. This is a service that makes branches in other repositories go-gettable. Eg. go getting gopkg.in/foo/bar/v5 will download branch v5 from github.com/foo/bar. This seems to me to be a way of dealing reasonaly well with the issue -- the go get tool itself doesn't need to understand anything at all here.

[1] [http://labix.org/gopkg.in](http://labix.org/gopkg.in)

<comment><USER15> A nasty workaround for a problem which should not exist in the first place. Ditto dependencies on private repositories.

<comment><USER16> I personally don't see having the version in the package address particularly more nasty than specifying it in the project file, as in Maven, which I have been dealing with lately. One problem I imagine is that when migrating to a new version of a library, the address has to be updated in each file the library is used in, with potentially catastrophic consequences if any one file is forgotten. A grep seems wise in that case.

Would you argue that there are more robust solutions in the Haskell ecosystem? What scheme do you prefer?

<comment><USER13> I don't think the issue was with specifying the version in the package address. It is that you need to use a 3rd party, remote service, to redirect your requests to the appropriate git repo and branch.

This is because Go doesn't support specifying branches/tags itself when specifying a git dependency.

This workaround is contingent on gopkg.in people keeping their service maintained and running. If they went down, all your dependencies would break.

</comment></comment></comment></comment></comment><comment><USER17> I was expecting an empty page with a huge "don't" in it. But instead there was interview excerpts from Go developers and a ambiguous list of "best practices".It would be more meaningful if this was backed with some actual practices with some code examples.

I just don't see what people think others would understand by teleologic statements like: "write Go the way it wants to be written"

<comment><USER18> > I just don't see what people think others would understand by teleologic > statements like: "write Go the way it wants to be written"

To me it means "Read what the creators thought about when creating Go and how they view it, and do the same". But really that applies to any craft that exists: instead of trying to apply and adapt what you already know, clean your mind and start from scratch.

<comment> lhc- Wait, the advice is "ignore your past knowledge and experience and start from nothing" ? That strikes me as terrible advice.

<comment><USER18> More like "Don't try to _shoehorn_ your existing knowledge into that thing you are trying to learn and use; it may or may not fit but isn't supposed to". That absolutely doesn't prevent you to _use_ your knowledge as stepping stones to understand the new thing.

</comment></comment></comment></comment><comment><USER19> > I resisted the recommended workspace configuration, as described in How to > Write Go Code. Don't bother, especially in the beginning

I've had the same dev folder structure across platforms, languages, jobs and decades. I basically had to abandon that structure when starting Go. I fought & fought and at the end of the day it is just easier to use their expected workflow. It was (is?) galling but it was the only way to stop fighting the tools and get work done.

<comment><USER20> The intellij go plugin is your friend. Per project go-paths. It's also a good use of make.

</comment></comment><comment><USER21> So, if Go is as bad as the comments so far make it out to be, what are some alternative languages? Specifically, a compiled language that can be deployed without worrying about dependencies. That's the feature that has had me looking into learning Go. I want to be able to just copy one file to my server and run it, no need to install anything extra on the server to make my program work.

Actually, can Go even do that? I think it can...

<comment><USER22> "So, if Go is as bad as the comments so far make it out to be, what are some alternative languages?"

While a good question anyhow, it's not as bad as the comments make it out to be. Anything can be made to look bad by only looking at the negatives, anything can be made to look good by only looking at the positives. And the balance shifts depending on what sort of application you're writing. There's a reason that Go has seen a lot of success writing network servers. There's a reason why Go has no penetration into the scientific computing community, and I tend to warn away anybody even thinking about it.

In particular, a lot of the people screaming about Go do not consider some of the positives. For instance, thanks to the implicit satisfaction of interfaces, I find it one of the easiest mainstream imperative languages to still create a separation between IO and pure code, by wrapping all IO behind an interfaced object, one that I may not even have to create (i.e., Files already implement io.Reader and io.Writer, io.Reader & io.Writer also already have several test implementations available in the stdlib and it's easy to adapt them to a few more), which then allows me to write some _really_ good testing code, almost as good as Haskell. (In fact, swapping in alternate implementations is probably easier than in Haskell.) This _can_ be done in other languages, but it often involves jumping through hoops to create your own objects that mirror other object's methods so they can implement an interface or something; in Go it's trivially easy. Between that and the way errors are handled, I find it relatively easy to write very bullet-proof code.

And while I also consider it annoying that Go lacks half of generics (interfaces are actually half of generics, but it's missing generic types), there are also often ways of spelling your APIs so it matters less. My code actually doesn't end up with very many interface{}s in it, and many of the ones that do are "real", in that the code in question really _doesn 't_ care what's there.

If you don't put those positives onto the balance, you don't get a proper view.

It doesn't help that, frankly, this was not a very good article and I strongly agree it has tone issues. This brought out a lot of people who might otherwise have just clicked over without commenting.

<comment><USER8> > For instance, thanks to the implicit satisfaction of interfaces, I find it > one of the easiest mainstream imperative languages to still create a > separation between IO and pure code, by wrapping all IO behind an interfaced > object, one that I may not even have to create (i.e., Files already > implement io.Reader and io.Writer, io.Reader & io.Writer also already have > several test implementations available in the stdlib and it's easy to adapt > them to a few more), which then allows me to write some really good testing > code, almost as good as Haskell. (In fact, swapping in alternate > implementations is probably easier than in Haskell.)

I'm confused. How does not having to write "implements Reader, Writer" (25 characters to type) have anything to do with purity and IO effects?

> interfaces are actually half of generics

Interfaces aren't generics at all. Java had interfaces and Object as a supertype before it had generics, and it still had zero support for generics.

I do agree with you that Go has maybe 50% of the use cases for generics covered, but not because it has interfaces. Those don't count. It's because it has maps and growable arrays built in.

<comment><USER22> "Interfaces aren't generics at all."

It's a definition game. One component of "generic" is "generic algorithm". Go has that covered; the Sort package provides a "generic" algorithm via an interface specification. A lot of C++ template code is built around implementing generic algorithms at compile time rather than Go's run time, for instance.

If you choose to call that "not generics", that's a valid choice of definition, and certainly makes sense in a Rust context, but it's not universally valid.

For context, I'm not trying to bend a definition to "defend Go"... I generally have a low opinion of software engineer's ability to create universal definitions of terms that apply across all languages, and I _observe_ that pretty much any term you can imagine varies across language communities. I'm not the one creating terminology vagueness. And I have observed that every time someone contradicts me and insists some term really is rigorously defined and agreed to by all major language communities, you can _count_ on two or three disagreements from not-me in the replies...

</comment></comment></comment></comment><comment><USER23> its not all go specific, despite the comment about 'C style' heap allocation and pointer usage, you will find your C code will get better if you do not do this as well. the heap is a last resort, not the first.

<comment><USER24> I found that comment strange as well - I consider "put everything on the heap" to be more of the default attitude in dynamic languages (Python, Ruby) and in the statically typed managed languages (Java, C#). In C and C++, I default to the stack, and I don't think I'm alone.

</comment></comment><comment><USER25> I take it these are the idiomatic best practices.</comment>


Developers, talk to a VC before a recruitment agency - <AUTHOR> http://blog.hirelite.com/developers-talk-to-a-vc-before-a-recruitment

<comment><USER3> Couldn't agree more. I work at Thomvest Ventures and almost every portfolio company we have is hiring (a few additional aren't listed because they are in stealth but are about to go into ramp mode). Have quite a few friends working on funded startups who are looking to hire as well.

If you know the type of work you want to do, have a list of some of the stuff you have coded/what languages you know, and/or are interested in a specific company we have feel free to shoot me an email and I will try to help out (info is on Nathan's blog).

</comment><comment><USER4> This is a really good point. Also - as a startup, we typically got better candidates who came through our investors. Certain type of candidate was the one that knew where to look.

If you're in Los Angeles / SoCal - talk to Mark Suster at GRP Ventures. He's communicated that just about everyone in his portfolio is hiring.

<comment><USER5> Just make sure you've never left a job in under 10 years, even if you got an enormous raise or your boss was an ass or you got a much better situation out of it. In fact, you should be willing to tolerate a shit situation and lower pay for _years_ just to prove your loyalty.

[http://www.bothsidesofthetable.com/2010/04/22/never-hire- job...](http://www.bothsidesofthetable.com/2010/04/22/never-hire-job-hoppers- never-they-make-terrible-employees/)

ps -- make sure never to look out for #1 -- that's for companies, not you, silly employee

</comment></comment><comment><USER6> Great article. We're currently looking for developers in the Ottawa/Montreal area in python if anyone wants to drop me a line!

</comment><comment><USER7> The other hidden benefit to this is that VCs are usually the only way for stealth mode companies to be hiring.

</comment><comment><USER8> Some Israeli VCs I know, actually have in-house recruitment agency.

<comment><USER4> Google Ventures has this too.

<comment><USER9> Having looked at their portfolio, I'd be interested in talking to their in in- house recruitment agency. Do you know how someone could go about contacting them?

<comment><USER4> This is all public but I don't really have any close personal connections that lead to her.

<http://twitter.com/#!/lgrenawalt> <http://www.linkedin.com/in/lindsaygrenawalt>

</comment></comment></comment></comment><comment><USER10> This makes something like Mixtent.com more valuable...since you now have people vouching for developers/companies, you could probably do the same thing for places to work.

</comment><comment><USER11> if i were acquainted with a VC ... :)

<comment><USER3> hi Vlad!

<comment><USER11> hi! to you too

that way i know a bunch of VC :) Even my VC-handshaking friends after founding/CTOing several startups, still so far ended up like me - <USER2> or principal level engineers in established companies.

<comment><USER3> :)

Well I guess that is more job security depending on what you want. You can always go back to doing startups, plus you will know a bunch of other engineers who may hop on board with you.</comment></comment></comment></comment>


Ask HN: Any simple alternative of Google Calendar Tasks? - <AUTHOR>

It's been a year since this post on Google support forums. Still waiting for repeated tasks & it's reminders without luck.
http://www.google.com/support/forum/p/Calendar/thread?tid=4597c9e968e0286f&hl=en
I'm considering some alternatives like RememberThe Milk, but want something lightweight that integrates well with Google Calendar.
Could you suggest an app for that, please? <comment><USER2> Remember The Milk has great google calendar integration. There is a gadget that can be displayed in google calendar in addition to feeds that google calendar can import (including an events feed). It has nearly every feature for tasks.</comment>


What are the 10 most harmful jobs? - <AUTHOR> https://80000hours.org/2015/08/what-are-the-10-most-harmful-jobs/ <comment><USER2> This wasn't a bad list. However, one factor I'd consider is the individual role's role and options.

For instance, I've read (I think it was in "Fast food nation") that factory farms in the US are often staffed by people who are not legally permitted to work or reside in the US and who are at constant risk. They generally don't have much education or options, and have no recourse if they are mistreated on the job or denied pay. I'd also be disinclined to hold a burger flipper at macky d's responsible for, well, macky d's.

A patent troll, on the other hand, is a well educated person, almost certainly a US citizen or someone with legal rights and options, who had every opportunity to choose a different path in life, and indeed still does.

By the way, there's this job where you collect vast amounts of personal information about people, who may be unaware or only semi-aware of what is being collected, and then using sophisticated machine learning to get them to click on ads... where does that fall in the spectrum of harmful jobs?

<comment><AUTHOR> Do you think you suffer when you click on an ad you think is relevant to you? I don't think internet ads do me much harm, especially well targeted ones I want to click on.

<comment><USER3> > I don't think internet ads do me much harm

If you don't consider the absence of your own (or your loved ones') privacy as "harm", then perhaps the job of inducing such an absence of privacy wouldn't be considered "harmful" by your standards. By my standards, however, that _is_ considered "harmful" \- maybe not physically, but certainly psychologically.

Do you not consider the eating of a Big Mac harmful for the eater just because the eater felt said Big Mac to be relevant to him/her?

</comment></comment></comment><comment><USER4> Christ. Has it ever occurred to these hipsters that factory farming feeds people? It's simple science that conventional farming is the only way to feed 7+ billion (soon to be 9+ billion) people. And referring to slaughtered chickens as "contributed deaths"... This makes me sad because I once had a little faith in this project.

<comment><AUTHOR> A vegetarian diet is i) requires less land and energy, ii) as a result is cheaper and iii) per $ is as nutritious as factory farmed meat. People in poverty eat very little meat. In fact, all meat production and consumption, in addition to factory farming, can be objected to on the further ground that it raises food prices for the poor: [http://www.nytimes.com/2008/01/27/business/worldbusiness/27i...](http://www.nytimes.com/2008/01/27/business/worldbusiness/27iht- meat.1.9525251.html?pagewanted=all). This is inevitable as meat production is 3-10x less energy and land efficient as eating plant products.

Finally, do you think that the chickens do not die?

<comment><USER4> Do plants not die? Saying that people are causing death without clearly qualifying that its farm animals is childish.

The environmental issue is legitimate, but they treated it as an afterthought. It also brings up issues of personal liberty and how much we know about vegetarianism's health effects.

And yes, people in the third world eat very little meat. But, you know what? I bet a lot of them want to eat meat. Remember that that argument can be made about anything even remotely nonessential.

<comment><USER5> The plants dying point is somewhat irrelevant in this context as 80,000 Hours's philosophy stems from Peter Singer's brand of utilitarian ethics that interpret suffering as it relates to experience, or consciousness.

<comment><USER4> What a wonderful sentence. You can keep concocting winding philosophical sentences like that to defend the dignity of chickens, and the rest of us will keep trying feed people.

<comment><USER5> I only made a clarification, not a stance on the matter.

</comment></comment></comment></comment></comment></comment><comment><USER6> Obviously any such list will be colored by the ethical system of the author.

Many people see zero harm in slaughtering animals for food. A large fraction of those also see a net positive in causing pain to those animals if it reduces costs.

Some libertarians would see little to no harm done by those marketing harmful products, and instead ascribe the moral weight of the harm to the consumers.

I'd be interested in seeing any empirical data on the weapons research angle. My understanding is that wars have been approximately equally deadly to the participants for much of recorded history. With the exception of weapons that are a risk for near-extinction level events, my intuition is that opposing sides in a war kill each other, regardless of how they are armed.

</comment><comment><USER3> I was really hoping this would be something about jobs that are occupationally-hazardous, rather than an opinion piece judging various careers based on subjective notions of "good" and "bad" without any real qualification. Not that the points are _wrong_ , but the authors could have delved further into _why_ those careers are immoral ones to have.

Also.

> [raising animals for food] involves killing, which is both painful and > perhaps immoral in itself.

Not if done properly. There are numerous ways to kill an animal painlessly and quickly; the most high-tech I've personally seen is the use of a high-voltage electric current through the cranium of an animal (usually when working with cows), which pretty much immediately shuts down the brain and any consciousness the animal might have. Sedation/anaesthesia also helps significantly. Smaller livestock can be decapitated (which, while likely not painless per se, is quick if done properly) or a probe can be jammed into the cranium to "stir" the brain and quickly shut it down (this is something you may have very well experienced firsthand in your run-of-the-mill frog dissection from grade school).

I personally disagree with the immorality (humans are naturally predators; I don't judge my dog for eating meat, nor do I judge some guy walking down the street with a bucket of fried chicken), but I realize that not everyone feels the same, and I do agree with the immorality of _factory_ farming.

</comment><comment><USER7> This comments section reads like a bad joke. How many times do Rob and Ben have to cite the overwhelming empirical evidence that 1) factory farming really does harm animals (how does _anyone_ doubt this?), and 2) factory farming is not preventing anyone from starving to death, before someone admits they were wrong?

</comment><comment><USER8> Factory farming considered worse than weapons research? Unless it refers to a specific kind of farming of which I'm not aware, I think the author led their own views cloud their judgement.

<comment><USER9> Good point. It is possible that weapons research has positive externalities and a deterrence factor. The lack of any armed forces on this list is somewhat surprising - although definitely not all armed forces roles would belong.

Agriculture and the systems built around it in much of the world has serious problems for the world and it's future.

<comment><AUTHOR> They were considered, see:

"Military decision-makers"

and

"Working in the army"

They didn't make the top ten in part for the reason you gave.

</comment></comment></comment><comment><USER10> Liberal bias? Ridiculous article. Show me the republican version then we can reconcile.

<comment><AUTHOR> What do you think conservatives would regard as the most harmful careers?

<comment><USER11> Professors, scientists, and school teachers are regularly demonized by the republican party.

<comment><AUTHOR> Much as I would love to be a contrarian it's pretty implausible that they are the most harmful careers.

<comment><USER12> It's pretty implausible that farming is a harmful career as well. But, oh look, there they are at number 2.

<comment><AUTHOR> Only factory farming of animals is on there, and given the suffering of the animals involved I think it's a complete no-brainer that it overall does harm.

<comment><USER12> No it fucking doesn't. It feeds the human race.

<comment><USER10> Exactly! If you don't see the political agenda behind this one, you are blind. But I was doomed to be down voted when I made the comment above anyways given the demographics on hackernews.

<comment><USER13> You should probably have quoted the previous comment which would have given more context.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Simple chrome extension to display random quotes on new tabs - <AUTHOR> https://github.com/abhiomkar/good-quotes <comment><USER2> Check Github for "quote suspended". U get the idea there..</comment>


Ask HN: How do you read Hacker News on mobile in 2016? - <AUTHOR> <comment><USER2> If you're on iOS, I really like Minihack

[https://itunes.apple.com/au/app/minihack-hacker-news- client/...](https://itunes.apple.com/au/app/minihack-hacker-news- client/id631108846?mt=8)

<comment><AUTHOR> Thanks for suggestion! I will try this later.

</comment></comment><comment><USER3> Using my phone's web browser (in my case, Safari). The only thing bothering me is I can't collapse comment sections. Otherwise, it's fine.

</comment><comment><USER4> I prefer Chrome to the Android app.

</comment><comment><USER5> I think a poll is better suited for this question.</comment>


Show HN: C++ face detection ported to Rust - <AUTHOR> https://github.com/atomashpolskiy/rustface <comment><AUTHOR> Would be nice, if someone took the time to do the same thing for face recognition part of Seeta engine.</comment>


Congratulations on making through your first month of teaching...now what? - <AUTHOR> http://educationismylife.com/you-made-it-through-your-first-month-of-teaching-now-what/

<comment><USER2> I didn't really take a lot out of this, but the 'teacher as coach' analogy struck me as something novel. In this day of technology and information, the teacher is more of a tour guide than a professor, but the idea of coaching students through the curriculum is enticing.</comment>


Transform a Browser into a Basic HTML Editor - <AUTHOR> https://www.shieldui.com/blogs/html-editor-in-your-browser <comment><USER2> I put this in a bookmark in chrome and use it whenever i need a "specially crafted" printscreen. javascript:(function(){ document.designMode = "on"; })();</comment>


CSS Animated Fish Tank - <AUTHOR> http://liveweave.com/GSquYM

<comment><USER2> This is incredible what you can do with CSS now a days. Thank you for sharing. Will use this on living room HDTV ^_^ Also, never knew of LiveWave website _bookmarked_.</comment>


Reviewmeta.com – Amazon Review Checker - <AUTHOR> https://reviewmeta.com/ <comment><USER2> See also [https://www.fakespot.com/](https://www.fakespot.com/)

Although the easiest solution is to not shop on Amazon and avoid the flea market of random unknown brands and cheap or dangerous counterfeits.

</comment><comment><USER3> There was a pretty entertaining Planet Money story about the origin of reviewmeta.com. [https://www.npr.org/transcripts/623988370](https://www.npr.org/transcripts/623988370)

</comment><comment><USER4> This is actually pretty neat. I'll probably try it "in production" next time I'm looking at an off-brand gadget. It took me a minute to figure out where it was, but the Report Card area does a neat job showing you what reasons they dropped some reviews. Not all of them suggest malicious intent, but there's some good criteria there.

For instance, it trusts "easy graders" less, as well as "brand loyalists" who review a lot of products from the same company. Both scenarios aren't exactly harmful, but can reflect higher-than-fair review scores.

<comment><AUTHOR> I find it amazing that it goes through reviewers e.g. it told me that this reviewer has used a particular line ("comes with a brush") 6 times in reviews.

<comment><USER4> Yeah, it's a little hard to find your own review profile (I had to find an item I reviewed that wasn't heavily reviewed, than search the list for myself), but when I found my own review profile, I could see that ReviewMeta decided I was 79% trustworthy. ...I haven't reviewed a lot of things over the years, but it's a long-lived account and I think their judgment is probably pretty fair there?</comment></comment></comment>


Wal-Mart Sues Puerto Rico Over 'Astonishing' Tax Increases - <AUTHOR> http://www.bloomberg.com/news/articles/2015-12-05/wal-mart-sues-puerto-rico-over-astonishing-tax-increases <comment><USER2> So, is this the sort of thing the TPP and other trade agreements will let companies overrule.</comment>


Is the Exercise Cool-Down Really Necessary?  - <AUTHOR> http://www.nytimes.com/2009/10/15/health/nutrition/15best.html?_r=1&hpw

<comment><USER2> I swam for a D-III school and our coach insisted on a long cool down after every swim meet. It was just ingrained in me that if I didn't do a cool down that I would have built up lactic acid or something that would make me stiff and unable to practice well the next day.

Then one year we went to watch a meet between Texas and Michigan, two top D-I teams that have Olympic champions. At the end of the meet, both teams just packed up and went home, and not a single person did a cool down. I was shocked! It made me realize that a cool down probably wasn't necessary, but I was still required to do it anyways. Our coach didn't really reply to me when I asked him about it.

One thing that those teams did was stretch A LOT before the meet. I think they did something like a full 40 minutes of stretching before they even got in the pool.

<comment><USER3> I've never seen the point of stretching cold muscles. I don't even warm up before a Marathon. The first mile will be easy anyway as the pack thins out, why waste energy warming up?

As for cool down, the key is this: after a long run, your muscles will be weak. If you cross the finish line and just flop down, that's when you're likely to get hurt, there is not enough tension to protect your joints. A warm down forces you to retain your posture while you recover a bit. That is the mechanism for injury prevention, not flushing lactic acid or whatever.

<comment><USER4> A lot of young people don't bother stretching at all. However, almost anyone who is middle-aged and is capable of doing the same workouts they did when they were young attribute their ability to work to a committed stretch program. Flexibility is one thing I've really been working on as I near the ripe age of 30.

<comment><USER5> > is capable of doing the same workouts they did when they were young > attribute their ability to work to a committed stretch program.

Said folks may be correct, but that just tells us that stretching is valuable. It doesn't imply that warm up and/or cool down is useful, even if many of those folks do their stretching as part of warm up/cool down.

</comment></comment></comment></comment><comment><USER6> If you aren't doing anything extremely strenuous, then no it probably isn't necessary. But I've done a 100m and 200m sprint and me slamming the breaks at the end generally results in either me feeling faint or simply passing out.

I've never really paid attention to why a cool down was necesary, nor did any of my coaches require it. I just did it because after a good run your sweat glands are wide open and it feels uncomfortable to stand still in the humid, Florida sun.

<comment><USER7> Accoding to [http://www.nytimes.com/2009/06/02/health/02well.html?_r=2...](http://www.nytimes.com/2009/06/02/health/02well.html?_r=2&ref=health) , cooling(as in taking it slow) in marathons helps with the fainting/passing out.

Wasn't there this story of a 40+ european guy winning grueling competitions based on sheer stamina than performance.It was a story on Nytimes, couldn't find it.

<comment><USER8> is this it?

[http://www.nytimes.com/2006/02/05/sports/playmagazine/05robi...](http://www.nytimes.com/2006/02/05/sports/playmagazine/05robicpm.html?pagewanted=all)

</comment></comment></comment><comment><USER9> I loved this sentence:

 _"Everyone thinks it's an established fact," he added, "so they don't study it."_

I wonder how many other places we encounter that this would apply to.

<comment><AUTHOR> It's well-established that this wouldn't apply to those places.

</comment></comment><comment><USER10> And the answer (from the article and what I've read elsewhere): no, not as far as any study has ever been able to determine.

<comment><USER11> _there is only one agreed-on fact about the possible risk of suddenly stopping intense exercise. When you exercise hard, the blood vessels in your legs are expanded to send more blood to your legs and feet. And your heart is pumping fast. If you suddenly stop, your heart slows down, your blood is pooled in your legs and feet, and you can feel dizzy, even pass out._

<comment><USER12> Which is why you sit down or bend over, no?

Marathon runners do a pretty intense workout .. I've never seen one of them do a warm-down at the end.

Similarly a study a couple of years ago by the Australian military (someone Google that for me!) said that warm-ups didn't alter the rates of injury during physical activity.

<comment><USER11> Marathon runners don't do an intense workout. It's an endurance sport and peak output is nowhere near what a sprinter does.

<comment><USER13> > _Marathon runners don't do an intense workout. It's an endurance sport and > peak output is nowhere near what a sprinter does._

It's easy to say that from the couch.

Odds are overwhelming that both you, and 99% of the people commenting on this site are incapable of running a mile in under 5 minutes or even a single lap around a 400m track in 75 seconds. Top marathon runners _average_ a higher speed than that for over 2 hours. Winners occasionally have a sub 4 minute mile _within_ the race.

<comment><USER11> A mile is still an endurance sport. There is a reason the world record for 200m is slower than twice 100m even though they both start from a dead stop and it takes several seconds to hit top speed.

Edit: I dealt with limited lung capacity for a while, it can be vary obvious once you start needing a lot of oxygen really quickly. You can run fast from a dead stop, but distance and recovery time can become insane.

<comment><USER13> Actually the 100m and 200m records are about the same speed. It's 9.58 for the 100m and 19.19 for the 200m. And before this August when Bolt shattered his previous 100m record, the 200m record was significantly faster than the 100m.

But in any case, both miles and marathons are incredibly intense workouts. In fact, from a physiological standpoint, middle distances are more intense than sprints. Less than 400m isn't even enough to push someone to their lactate threshold. Short sprints are run on the fuel already in the muscles. Obviously, it still takes intense training (and the right genes) to sprint well, though.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> <http://www.halhigdon.com/15Ktraining/Stretch.htm> <http://www.indoorclimbing.com/stretching.html>

stretch beforehand to prevent injury and after to remove lactic acid and soreness. it's been stressed to me on several occasions that stretching post- exercise is critical, and at our gym we do 10min of yoga after a 1-1.5hr cardio session. i'm still getting used to some of the exercises and my calves need constant stretching or they get tight and painful.

<comment><USER3> But if lactic acid isn't responsible for soreness...?</comment></comment>


Modern Web Application Architecture - <AUTHOR> http://leftnode.com/entry/modern-web-application-architecture

<comment><USER2> Your client side shouldn't have any PHP in it and it should be the Javascript making requests to the REST API. Is there a reason why you are not doing this?

What you have done here is just add another tier on your backend, when you don't really have to and don't really need it. This is something you do when you have hundreds of thousands (or millions) of visitors, not something I would worry about before you even launch an app.

I was surprised when I came to the point of the post where you describe the client - I thought the point of your API (and the post) would be to describe a single page app with only an API on the server side.

Edit: what aedan said, as well :) you should really take the time to just do the 'client' in javascript + html + css - it is _totally_ awesome. Your client is then static and you can CDN and the hell out of it. Twitter is the best popular example of this architecture where the same API is used for their own apps, including the website, and for third-party developers.

<comment><USER3> While I agree on the 100% js. To optimize the experience and app load time its best to provide the data on load inside the document. reducing http calls. backbone supports the idea here:

<http://documentcloud.github.com/backbone/#Collection-reset>

<comment><USER2> I put templates in my loads, but data I get with a background process that takes advantage of the local cache. So the first get will take 500ms or so to prime the user cache, but from then on it is all diffs back to the server. The agent is something that I have been meaning to open source.

It is about weighing pro's and con's. I would prefer to take advantage of having all the assets being static, cachable, CDN-able etc. Weighing those options in other apps might not make as much sense, but this particular app for me had small amounts of very user-specific data.

Btw there is still a lot of this 'stack' to be built, I am finding myself having written and having to write a lot of Javascript to support the model I am using

</comment></comment></comment><comment><USER4> I think you should take the frontend one step further and have it live completely on the client side. It is fully within the realm of possibility to build a JavaScript/HTML application for the front end that only interacts with your API.

Is there a reason you didn't do this?

<comment><USER5> He talks about wanting to charge for the API. If the javascript on your public website directly calls your (otherwise paid) API, how can you avoid exposing the credentials it uses which are unmetered?

<comment><USER6> You could make sure that the requesting page is on your domain.

<comment><USER7> It's trivial to use a proxy to modify the referral headers.

</comment></comment></comment></comment><comment><USER8> Whenever I heard about Amazon using SOA heavily, I thought this is how they implemented it (making HTTP requests to their own API). Is it true? If there is a performance penalty to this approach, what are the alternatives to call the internal services/APIs? People talk about services all the time, but no one talks about the actual implementation. Thanks to the blog author for documenting this. It would be great if someone could point out similar articles.

<comment><USER9> My understanding of Amazon's internal SOA usage is that it is geared toward timeout-enforced service response guarantees to mitigate concerns about performance penalty. Specifically, a page render event triggers initiation of asynchronous calls to N service endpoints( I have read as many as 300 per page render event ). The page renderer will wait for a specified time to receive responses from each service, but timeout on those services that do not meet their latency SLA. Page components with dependencies on either error result or timed-out service responses will simply be not rendered or replaced with dummy content.

Employees of Amazon, feel free to correct any holes or errors in my understanding of the web application architecture there.

</comment></comment><comment><USER10> I wrote about this some time ago. It's a great way to build web applications after you sort out the little kinks and intricacies. Some tips can be found in this post: [http://www.w2lessons.com/2011/05/why-and-how-you-should- writ...](http://www.w2lessons.com/2011/05/why-and-how-you-should-write- rest.html)

</comment><comment><USER11> > It is stateless and uses no sessions or cookies.

Could someone please enlighten me how this should be done best?

There are a lot of cases where API must authenticate and authorize the user before allowing them to access the resource. To do this one has to use either self-invented scheme or HTTP authentication. Here're my thoughts:

\- HTTPS X.509 certificate auth is nice, but unfortunately requires excessive user awareness, does not work in many browsers (at least, Chromium@GNU/Linux and Android), and, I believe, cannot be easily controlled from JavaScript.

\- HTTP Basic auth is silly, as it requires browser to hold the password in memory for prolonged time period, and there are no sane methods to make the browser forget the credentials. As there's no notion of session, remotely revoking previously-open sessions is impossible, so the situation "Oops, I forgot to log out at that Internet café" has the only one possible solution - changing your password.

\- HTTP Digest auth requires plaintext password knowledge on the server side, so it has limited use cases. HTTP Basic problems apply here, too.

\- HTTP OAuth1 seem to be the best available solution out there, but has a downside that it requires signature generation and verification on each request, and isn't natively supported by any browser I know of.

\- HTTP OAuth2 is HTTP cookies reinvented. Except that, once again, no browsers supports it natively.

</comment><comment><USER12> For the last couple of years I've been developing projects as an api layer coupled with a dumb 100% javascript front end. The api layer always returns json data, and the front end requests and consumes it. 3 projects down the line and this is so far been great success. The back end server is now free to do what it really needs to be doing - get data to the front end. You can write different front ends (mobile, voice etc.). They all request and consume the same data. And, you earn an api you can open to the public

<comment><USER13> Harel, I'd be very interested in seeing some of the projects you've done using this technique. Are there any that are publicly accessible?

</comment></comment><comment><USER14> Perhaps the front-end can always be open sourced since the business-critical parts all sit on the back-end.

Advantages of doing this:

* Clients can run their own copy of the software

* Other developers (or even clients) can submit pull requests directly instead of issue ticket

* The monetization potential can be maximized

</comment><comment><USER15> On "it's slow" ...

Making direct calls to the DB probably won't make it ten times faster. Reporting data should come from a pre-aggregated table (think data warehouse) so that you're not doing anything than an indexed SELECT.

So anything displayed to the user should become instant. You're never displaying a million records at once, max 20.

For reporting, build those on the server side using a different data interface to the DB - RESTful is not the right answer here.

<comment><USER3> I posted a question on stackoverflow trying to gather pros and cons of the methods outlined in this HN post.

[http://stackoverflow.com/questions/8022715/standalone- rails-...](http://stackoverflow.com/questions/8022715/standalone-rails- application-per-model-service)

</comment></comment><comment><USER16> One thing I've been thinking about for an architecture like this is to use an event machine on the frontend and make the API calls asynchronous to negate the latency issues.

<comment><USER17> Yep, thats a big reason. Always load the possible next actions upfront, and when the user clicks, its immediate.

</comment></comment><comment><USER18> Another advantage to this is that you can have other types of clients in parallel. For example a native iOS app could call the API directly.

This native app could be made with client side web tech and packaged with PhoneGap.

Would also be interesting to try to implement the client in such a way that it both can run on the server (in node js, outputting static pages to browsers) and also as a pure client side web app, packaged with PhoneGap.

</comment><comment><USER19> I see a lot of great things coming from this, such as creating an infrastructure where the web team understands and has incentive to develop an API that will be just as useful for the mobile team.

I wonder about security though. How would you lock this down so that the data can be encrypted?

<comment><USER20> Use HTTPS? Or do you mean security against other kinds of attacks besides sniffing and MITMing?

</comment></comment><comment><USER21> "Generally a single URL returns a specific resource"

I've seen this misconception. There is absolutely nothing wrong with GETting multiple records with a querystring.

There are frameworks like CodeIgniter that inexplicably do not support this in a first class way.

<comment><USER22> A resource is not a record.

</comment></comment><comment><USER23> Forcing every feature you write to be service-backed is actually quite annoying. I'd avoid using web services for the main app until it was absolutely necessary.

</comment><comment><USER24> I am using this architecture on a new project, I would love to hear any possible drawbacks on it.

<comment><USER25> We can't tell you if this is a good idea without knowing what your project is.

In the absence of that, here's some "possible" criticisms, some of which come directly from the blog post itself:

You're incurring extra latency by doing two HTTP connections where one might do.

If you choose to serve your REST API from a different layer of servers than your front end, that's a whole new layer of servers that can go down. So you have a whole new layer of redundancy and failover to engineer.

Your back end is issuing SQL queries, encoding the results as JSON or (god help us) XML, passing it to your front end which is very likely parsing it, filling out templates with the resulting data structure, and emitting HTML. That extra encode-and-parse step costs time and resources. (Of course, if your front end is generally Javascript running on the customer's machine, this isn't a big problem.)

Finding bugs can be a pain. You now need multiple layers of logging, and tracing a buggy request through the system requires you to piece together a chain of internal requests.

You've designed twice the surface area of API. You must now document and test an internal API as well as your front end, and the two may have significantly different semantics. Now, it's true: Just because you don't formally define your internal API doesn't mean it isn't there, because every app has _some_ sort of internal API (often built around an ORM, these days). But once you decide to formalize it that API is harder to tinker with.

The overarching criticism, as always, is: YAGNI. You are almost certainly not building Facebook. For a very large percentage of the sites on the web, this design is total overkill. If you're delivering text embedded in HTML, like most blogs or magazines or brochureware sites, you should spend your energy figuring out the Varnish and CDN layers instead of fiddling around with a custom REST API that nobody is ever going to use. Just install an off-the- shelf RSS module and call it a day.

Even if your site might potentially benefit from an internal API, should it really be part of your initial deliverables? Does the customer want to pay for it? Does the minimum viable product require it? If there is anything more painful than designing one interface for the wrong product, it's designing _two_ interfaces for the wrong product.

Having said all of that: This architecture is indeed really useful when you have the right problem, we use something like it at my own company, and (as many other commenters have pointed out) in the world of rich Javascript clients and native mobile apps this strategy is gaining in popularity for good reason.

<comment><USER9> Excellent.

We run an architecture somewhat similar to that described in the article, and a lot of the issues you raised we either dealt with up-front, or realized we needed to deal with them very soon after rolling it out.

Regarding extra latency and sql select result marshaling, we cache extensively and invalidate through message queues. The few exceptions include data that are involved in transactional contexts, like actual order placement and fulfillment.

We have effectively solved debugging/logging by generating and chaining request identifiers, which turns out to not be as computationally expensive as one would think.

YAGNI is, of course, the elephant in the room. Some aspects of the architecture have turned out to be quite beneficial, but the traffic scalability afforded by shared-nothing, API-driven architectures is not something we have had the luxury of really exercising as much as we'd like :)

<comment><USER25> Yes, the caching at the API layer has proven critical for us, too. Although, of course, this introduces a cache coherency problem, and we all know what fun those can be.

You bring up a very good point that I left out:

 _The few exceptions include data that are involved in transactional contexts..._

It's sad how few people even understand how to write transactional code when you hand them a direct interface to SQL. (I like to think I do, but I may be fooling myself.) And trying to implement, document, test, and maintain a stateless RESTful HTTP protocol that properly supports transactions on the underlying data store is even harder.

</comment></comment></comment></comment><comment><USER26> What's that additional layer of PHP code good for? Call your API from Javascript.

</comment><comment><USER27> Why not let the front end sit entirely on the client?

EDIT: What aeden said.</comment>


Ask HN: Encouragement as a Service? - <AUTHOR> Does "Encouragement as a Service" exist?
It would be a number that you can call as an entrepreneur, when you feel a little down or discouraged.
It would not offer advice per se, but "quality listening" (relevant questions) and comforting/encouraging words.
You would subscribe to it with a monthly payment.
It would work via phone and email, with maybe different price tiers.
Does this exist already? Does anyone want to try and build it? <comment><USER2> In a way it does exist. A lot of people get this kind of encouragement and "quality listening" from psychological counselors. This means that there is an opportunity here, because psychological counselors are usually overqualified for the simple encouragement an entrepreneur may need, and thus tend to be more expensive than what I expect your price point would be.

In short, I think that re-framing the service as an "entrepreneur's counseling service", including such things as a guaranty of confidentiality, has potential. The thing to remember is that counseling requires a human touch, so any technological contribution is going to be of the nature of putting entrepreneurs in need of encouragement in touch with counselors. Having a ready source of inexpensive, entrepreneur-specialized counselors is definitely a service. How much demand there is for it, I don't know.

If you get it together, tell me your rates. Cheap enough and I might use it myself.

</comment><comment><USER3> One HN'er has done something like this, look for Zachary Burt and 'awesomenessreminders.com'.

[https://www.google.com/search?q=site%3Anews.ycombinator.com+...](https://www.google.com/search?q=site%3Anews.ycombinator.com+awesomenessreminders.com)

<comment><AUTHOR> It's not the same thing but it's close, thanks for the info.

</comment></comment><comment><USER4> Does an insincere "you can do it" really help? They know nothing of your situation.</comment>


General Commission – Full-Time, Full-Stack Developer – Denver, CO - <AUTHOR> We are a newly formed bespoke data research firm set out to pioneer a new kind of data-backed research product. We provide unique insights to customers across the fintech, medical device, and artificial intelligence spaces, and are seeking to expand our customer offerings and technology platform capabilities.
General Commission (GC) is seeking a Full-Stack Developer for a Denver, CO / Remote-based role, where you will serve as the lead engineer in driving the future direction of our product offerings and tech platform. We are looking for candidates who are entrepreneurial technologists at their core, self-motivated, and passionate about building new products from the ground up. In this role, you'll see immediately connection with the direct impact of your work.
Seeking candidates with the following experience:
Experience with: o React (or equivalent Javascript framework) and Flask (or equivalent back-end framework) o Web applications, APIs, and services (incl. REST) o Database support and administration, including relational (MySQL, Postgres) and NoSQL (Elasticsearch, Mongo) databases o Dev tools, such as package managers, bundlers, task runners, linters o Git, BitBucket, and version control flows o Agile development methodology o All stages of Software Development Life Cycle
Working knowledge / understanding of: o Graph theory and open source graph databases, such as Neo4j and/or GraphDB o Agile processes and workflows o Scripting languages (Python, shell scripting) o Front-end development practices (HTML, React, SCSS) o Test suits/frameworks, unit, and integration testing o Object-Oriented Design and data structures Sound engineering practices: coding standards, best practices, and principles
We offer competitive salary, transaction bonus eligibility full benefits, unlimited vacation, flexible work schedule
Please email me at firstname.lastname@example.com for more information. <comment><USER2> HN is not a job board, please see the FAQ for relevant sections.</comment>


The Afghanistan war has lasted longer than 84% of all wars in human history - <AUTHOR> http://www.ifweassume.com/2014/02/we-have-always-been-at-war.html

<comment><USER2> The Afghan war lasts way longer than since 2001, It started in the late 70's and had several different faces and players.

</comment><comment><USER3> Graph the income of the Carlyle group against the last 30 years and compare that to it pike since 9/11</comment>


French police investigate wave of horse killings as satanic rituals suspected - <AUTHOR> https://news.yahoo.com/french-police-investigate-wave-horse-184931026.html <comment><USER2> The story and mutilations look very similar to the epidemic of chupacabras attacks that we had in Argentina in 2002. It was covered for a month by all the major newspaper and TV stations. [spoiler alert: it was just the misclassifications of the result of mice and foxes and other animals eating the corpse]

Autotranslations:

[https://translate.google.com/translate?sl=auto&tl=en&u=https...](https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Fes.wikipedia.org%2Fwiki%2FChupacabras%232000-2010)

[https://translate.google.com/translate?sl=auto&tl=en&u=https...](https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Fwww.clarin.com%2Fsociedad%2Fenigma- vacas-mutiladas-reportado-investigadoras-internet_0_rysldiNeAYe.html)

[https://translate.google.com/translate?sl=auto&tl=en&u=https...](https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Fwww.clarin.com%2Fsociedad%2Fvacas- muertas-mutiladas-ratones-campo-zorros_0_H1EGBcNgAtx.html)</comment>


Mysterious 'Nazca Lines' ruins discovered in Saudi desert - <AUTHOR> http://www.smartplanet.com/blog/thinking-tech/mysterious-8216nazca-lines-ruins-discovered-in-saudi-desert/8581

<comment><USER2> More information in the original article: [http://www.cbsnews.com/stories/2011/09/15/scitech/main201066...](http://www.cbsnews.com/stories/2011/09/15/scitech/main20106680.shtml?tag=content;siu- container)</comment>


Ask HN: How to find business partner in US? - <AUTHOR> In order to increase odds of building scaleable tech business I want to partner up with someone who is based in US.
I'm nodejs developer (and other skills) and have been building online product for over a decade. I'm base in Eastern Europe, but would love to move to US. However, at the moment thats not possible. Currently I have not particular idea in mind, but with like-minded people brainstorming comes natural. <comment><USER2> Do you need a business partner for managing office and teams. Or is it ok if you just business presence in the US and people working remote or freelance ??

<comment><AUTHOR> I prefer remote work. I need someone who lives in US, so has a good understanding of local market, mindset and ability to meet other people.

</comment></comment><comment><USER3> Post a portfolio, project, or specific concept to build, and an email for people to contact you.

<comment><AUTHOR> My skills are NodeJS, React, react native, ML etc. And together with US partner we will be able to come up with good idea and good understanding of US (primary) market.

To know more drop me an email: firstname.lastname@example.com

</comment></comment><comment><USER4> Everyone wants to live in the US buddy. Get in line, work hard. You'll be able to move eventually. There's no shortcuts.

<comment><AUTHOR> I don't believe in lines. I believe in shortcuts. Not easy ones, but shortcuts that are risky and takes time.</comment></comment>


YC to investors: There will be no funny business toward our female founders - <AUTHOR> http://venturebeat.com/2014/08/12/yc-to-investors-there-will-be-no-funny-business-toward-our-female-founders/?utm_medium=referral&utm_source=pulsenews

<comment><USER2> Forbes article: [http://www.forbes.com/sites/jeffbercovici/2014/08/07/what- it...](http://www.forbes.com/sites/jeffbercovici/2014/08/07/what-its-like- raising-money-as-a-woman-in-tech/)</comment>


Show HN: JPL Space Calendar iCalendar Support - <AUTHOR> https://github.com/joshuamcginnis/jpl-space-calendar <comment><AUTHOR> Author here. This was a fun little side project. It's a ruby Sinatra app that parses events from the unstructured JPL Space Calendar page and publishes the calendar in JSON and iCalendar formats.

[https://www2.jpl.nasa.gov/calendar/](https://www2.jpl.nasa.gov/calendar/)

[https://jpl.mcginnis.io/space_calendar.json](https://jpl.mcginnis.io/space_calendar.json)

[https://jpl.mcginnis.io/space_calendar.ics](https://jpl.mcginnis.io/space_calendar.ics)

This was my first time using Digital Ocean to host a little dockerized side- project. So far, my experience has been great.

<comment> 52-6F-62 This is cool. I already added the iCalendar. Got two comet notifications just this morning. If only I wasn't trapped in a big city I might be able to make more of it.

I often miss out on events for want of being out of the loop, so this is a start.

I'm also a fan of modern Digital Ocean, and my experience has been the same— I think it depends on the type of project but it's definitely been useful and well-priced.

</comment></comment><comment><USER2> Props to Ron Baalke for compiling the items in the calendar. [https://twitter.com/RonBaalke](https://twitter.com/RonBaalke)

</comment><comment><USER3> Immediately my eyes read "APL Space Cadet..."

Reference: [http://world.std.com/~jdostale/kbd/SpaceCadet.html](http://world.std.com/~jdostale/kbd/SpaceCadet.html)</comment>


Ask HN: Anyone else get dizzy when scrolling? - <AUTHOR> I get dizzy for half a second, this happens when I scroll down a page and I unexpectedly reach the end of the page and it won't scroll down anymore.
It feels like the brain considers the mouse as an extension of the limbs, in a way it prepares the vision for the scroll. And when it doesnt scroll it becomes confused.
Anyone else experiencing this? <comment><USER2> I am not a doctor, but if I saw you starting to get dizzy and you were sitting next to me at work or in a coffee shop I would be very concerned for you and ask if you need medical assistance. I would recommend talking to your doctor about that, it is not normal to get dizzy when scrolling. There could be an underlying problem that you have not had diagnosed yet, but it is best for the doctor to test you out.

</comment><comment><USER3> I met someone who gets dizzy playing 3D games. I'd be concerned, but apparently it's not unheard of.</comment>


Reflections on leaving Haskell - <AUTHOR> http://www.alsonkemp.com/haskell/reflections-on-leaving-haskell/ <comment><USER2> I'm not arguing that Haskell can't improve in a lot of ways, but his complaints all seem to stem from attempting to program in Haskell using idioms that don't work well there. If you want to incrementally add to a data structure, use currying, or multiple constructors if that fits better. Don't use Maybes, and definitely don't subclass datatypes. He doesn't really seem to understand monads at all. If you want to log something, use a monad like Writer, not IO.

<comment><USER3> Agreed that, in some senses, I was trying to force a square peg into a round hole, but the comments on my blog suggest that others share my experience and they're mostly from planet.haskell.org. So I think something is missed if my experience is entirely chalked up to ignorance.

My post was written fairly quickly and got more attention than I expected. Looking at it again and looking at Turbinado's code, I can see how you could suggest that I don't understand monads. And I probably don't understand them to your level, but the code reflects the result of trying to compose together a number of libraries into a sensible system. Wrapping those libraries in composed monad transformers was vastly more complicated than just dropping down to the IO monad, so I stripped down...

w.r.t monads: they're lovely for constraining code behavior and for building DSLs, so other languages have added monad libraries. They haven't forced the entire language to live within monads...

w.r.t incremental data structures: I mentioned in my post that I wasn't happy with multiple data types. Multiple constructors sound even less productive. Currying is a solid suggestion.

\- Alson

</comment></comment><comment><USER4> The problem with Haskell is that it is way ahead of its time, in kind of the same way that lisp was ahead of its time.

lisp had high order functions and garbage collection, and now 30 years later all mainstream languages have these features.

Haskell has lazy evaluation, compiler enforced function purity and a type checker that doesn't get in your way. I predict that in 30 years all mainstream languages will have these features.

<comment><USER5> Well said, but I don't think it's a problem per se. Lisp was way ahead of its time, but it also hung around until everyone caught up with it.

Programmers tend to think about code at the level of the most powerful language they know. Show someone partial application who has never used it and they say "that's a neat trick I guess", but take partial application away from someone that is used to it, and they suddenly feel like something vital is missing.

So at the moment, Haskell's new ideas seem at best to be "neat tricks" and at worst "confusing" to most programmers, but, as with Lisp, those ideas and features will get added to other more mainstream languages a bit at a time. Haskell's contribution probably won't happen because a bunch of people go out and learn Haskell, but because it's ideas will slowly move the cluster of mainstream languages up the curve.

</comment></comment><comment><USER6> The reasons against Haskell in this article are quite shallow and he would benefit from more knowledge (Why putting functions in the IO Monad to log/write stuff ??).

Real reasons I have against Haskell are it's complexity: compare it to the average readability of Python. Often, to resolve a tough problem, you have to upgrade your "level", which can be considered good (you tend to resolve it in an intellectually satisfying way) or bad (others have to understand it...).

<comment><USER3> plesn,

I don't disagree that the reasons are shallow, but it turns out that solving some problems in Haskell is just plain hard. It's precisely because the issues/reasons are basic that it's hard...

Also, I'm confused by your comment about the IO monad & logging... How would you log outside of the IO monad?

Would also be cool if you'd point me to your Haskell repo. I'd be curious to see how you solve these problems.

\- Alson

<comment><USER7> _How would you log outside of the IO monad?_

By collecting status messages in addition to computation results. The Writer monad is one (convenient) way to do this.

<comment><USER8> Can you clarify? I thought that keeping separate streams of side effects is not possible when one stream influences the other. The logging process depends on what actions happen in the IO sequence though not the other way around. Are you talking about keeping the normal IO actions in one monad, logging actions in another & then composing the two into an outer IO monad?

<comment><USER9> It depends on what you're logging. Pure code can keep its own log in Writer and then depose the whole thing to the IO logger later. Since there's no guarantee of the timing or synchronicity on non-IO code, this works well.

</comment></comment></comment></comment></comment><comment><USER10> _"And without Haskell I would be trapped in Scala-land, writing syntax- sugared-Java, confused about why functional programming was so great…"_

<comment><USER11> I'm starting to take this particular criticism as a major compliment to Scala. Scala makes it really easy to get stuff done and you're not forced to write functional solutions to imperative problems.

Also, I learned more from functional programming in Scala than I did when learning about Lisp. For one, Scala's default data structures are persistent and immutable, whereas the Lisp ones are mutable. Scala's library also operates better on abstract data types, whereas most functions in traditional Lisps operate on concrete data types, making Scala again more functional.

The above two points, by the way, highlight two major problems Rich Hickey had with traditional Lisps and therefore why he decided to write Clojure. See [http://www.simple-talk.com/opinion/geek-of-the-week/rich- hic...](http://www.simple-talk.com/opinion/geek-of-the-week/rich-hickey-geek- of-the-week/).

"Even Lisps are built on some primitive things, and those primitive data structures in traditional Lisps are mutable. I wanted the core data structures of Clojure to be immutable. In addition, I wanted the core algorithms to be based upon abstractions rather than concrete data structures as in traditional Lisps. These are things that can't be retrofitted in a compatible way."</comment></comment>


Ask HN: When is it ok to copy/steal an idea? - <AUTHOR>

More accurately: What's the difference between "stealing" an idea, and seizing an opportunity to "do it better"?
I find myself often shooting down ideas for websites/projects that I'd like to pursue, because "someone already did that" or I feel I would be stealing/copying the idea in some unethical fashion.
Is it unethical to see a poorly implemented but good idea and run with it?  Where's the line between "wow they did this better" and "wow these hacks totally stole that"? <comment><USER2> Don't steal code, replicate functionality. Don't steal graphics, but be inspired by a website's theme. Dont's steal trademarked or copyrighted material.

<comment><AUTHOR> Good concise advice, and that's certainly a baseline. In my case I am speaking (asking) more about replicating functionality or an idea, which is a lot more difficult to know where to draw a line on.

<comment><USER2> In the U.S. software is copyrighted, not patented. Business Processes (and other processes) are patented. Those processes may be entirely manifest by a particular software implementation, so we think of the patent as being for a software product. Business process patents are murky law right now, google "Bilski".

So one line would be: if the idea isn't patented, or it is, but you don't think the patent is valid, and have the money to back up your claim, or just feel ornery, then go for it.

People replicate functionality all the time. Why should that be unethical? I wouldn't just replicate it for no good reason. A good reason, and one that the spirit of the law is supposed to support, is, does it provide new value to the customer? Coincidentally, that is the same question you should be asking yourself if you plan to take your work to market.

</comment></comment></comment><comment><USER3> The difference is "YOU stole MY idea" vs "I built a better implementation of YOUR idea." In other words, just perception. remember how many different kinds of cereal are in the store.

If you wanted to start a car company, would you be concerned about "stealing ideas" because there were already other makes of cars on the market?

<comment><AUTHOR> I think your response hits at the intent of my question. It is widely held that "execution matters more than idea", but I personally get tripped up by feeling like something _has_ to come from my own light-bulb epiphany to be authentic or ethical. Clearly this is wrong.

Is this model of scenarios more or less correct?:

1 copy a mousetrap design: _bad_ \</comment></comment><comment>- ethical/unethical line </comment><comment>- 2 build your own mousetrap (even if there's really nothing "new" about it), but market it better or present it differently: _pretty good_ 3 build a better mousetrap: _really good_ 4 invent a whole new way to trap mice: _awesome, not likely_

2 and 3 are probably where the majority of successful business ventures fall. Most 4's probably started as 2 or 3.

<comment><USER3> Most 4's probably went out of business a long time ago. It's _hard_ to sell something new in markets that don't trust new things.

You place the ethical/unethical line where you feel it should go; personally I don't see anything wrong with copying designs. I have a few wealthy neighbors. Know how they made their money? Everyday, boring easily copied stuff like car washes, rental real estate or owning a couple of fast food joints. Even the people I know who got rich from technology businesses were doing fairly pedestrian stuff like industrial instrumentation that's been around since the 50's.

<comment><AUTHOR> What would you say if I saw <http://www.whosofftoday.com/> and built essentially a clone at <http://www.timeoffscheduler.com/> ?

I'm sure I'd end up doing many little things differently than you, and maybe even a few bigger things, but I'd love to hear your thoughts on this example.

<comment><USER3> Honestly? I don't know if I'd care much. If it turned out to be a perfect clone, I'd probably be a bit irritated, but in the end, imitation is the sincerest form of flattery.

I've been involved in a few tiny ventures (only me, or at most one other person) and one thing they've all had in common is that none of them were unique except in the personal approach I took to them.

So, as an example, you could start a business producing readers for diesel fuel flowmeters as I did, but would you have the same approach to customer service as me? Would you go out of your way to make using the unit as easy for your customer to use as you could?

The employee scheduler is the first software-only project I've ever done (and it was started primarily to learn web development), so maybe my reaction to being cloned would be different. But in the past I've built and sold hardware devices that had plenty of cheap marketplace competition so I'm used to that. My approach was to not care how many people were building the same thing or how much less they charged, but to focus instead on how happy I could make my customers.

I think of the product as a means to an end. The desired end result is profit and happy customers. The product or service is just the route you take to get there and really not that important in itself.

<comment><AUTHOR> Awesome reply, thank you - honestly, I was looking for validation of my own similar thoughts on the subject. I have previously written about this subject here (very similar to your response): <http://www.komlenic.com/242>

</comment></comment></comment></comment></comment><comment><USER4> Always. Ideas are exactly that. If you even suspect that you can execute an idea better than a version that is currently available or one that is being set in motion, then there is no reason why you shouldn't attempt to execute it.

If ideas were even half as regulated as the patent system, then the world would be a miserable and stagnant place.

</comment><comment><USER5> The line is innovation. If you actually bring something new to the table people close to the original idea will still say cheap knockoff, but most won't. Just look at the phone to blackberry to iphone progression no one considers any of them to be knockoffs or stolen ideas even though they largely innovated directly on what had come before.

<comment><USER6> Totally, that is one sad thing about a lot of European startups. They take one idea but don't innovate it.

</comment></comment><comment><USER7> If there is a company doing business in the marketplace and you see an opportunity to enter and compete in that market, that is entirely ethical provided you do not infringe on their intellectual property. For example, Noyce and Moore left Shockley to form Fairchild in order to pursue the semiconductor market.

</comment><comment><USER8> Instead of replicating/copying/stealing/whatever you could also try working together.

Side note: if you come up with an idea and only -then- see it has already been done, I wouldn't even consider it copying.</comment>


I'm Returning My Apple Watch 3 Cellular - <AUTHOR> https://medium.com/@0x0ece/im-returning-my-apple-watch-3-cellular-602d24899bfd <comment><USER2> _The reason I could (sic: should be_ couldn't _) stream music yesterday is pretty simple:_

"...because I can't read." It even says right on Apple's Watch page, under Apple Music: "coming soon". Okay, so maybe the author is not one of those geeky types that keeps track of the goings on in Apple's world.

 _Luckily I'm enrolled in the developer program_

Oops, guess not. I really don't understand the complaint here. "I'm returning my Apple Watch because it won't stream music." Umm, no one said that an Apple Watch that you buy today (or " _yesterday_ ") would stream music without an iPhone. It will standalone stream music "soon", but not right now.

<comment><USER3> I don't blame him for not paying close attention to "coming soon." If you watched the Apple Watch Keynote, the emphasis was on the experience of a tetherless Watch with streaming/phone/text services. If you're paying for that experience, I can understand why you would be frustrated. On the other hand, when you're on the bleeding bloody edge, maybe that experience is rough around the edges. A little patience would go a long way for this reviewer.

<comment><USER4> For years Apple has released products that are dependent on a feature not yet available. (Apple Pencil, AirPods, etc on the hardware front, and OS features touted for new hardware not available at launch, like Portrait Mode) For those that are heavy consumers of Apple products, years of keynote announcements should have conditioned this expectation.

<comment><AUTHOR> Agreed - and in fact my decision wasn't taken so lightly.

I guess another way of seeing what happened is this. I imagined a watch that could work disconnected from the iphone, which is a drastically new product. Beside making calls and paying, and beside the "watch-specific" uses such as activity tracking, I was under the impression that music streaming could be there. And I was wrong (and, as pointed out elsewhere, I could have read more).

<comment><USER4> Makes sense. I'm sure in the coming months support will expand.

</comment></comment></comment></comment></comment><comment><USER5> In the "dark ages" before the Apple Watch Series 3, people would use products like the "iPod Shuffle" to solve first world problems like these.

It's unfortunate that simple products like the Shuffle just aren't good enough. Instead we're always looking for something new and much more complicated and fragile.

<comment><AUTHOR> To be fair, the non-lte watch can work as a shuffle, you can store music on it -- and this is in fact where I'm thinking to land. The point was streaming using lte.

</comment></comment><comment><USER6> > On the bright side, earlier today I went grocery shopping, turned my iPhone > in airplane mode, and paid with just the watch.

The author seems to be unaware that you can use Apple Pay on the watch without any cellular on either the watch or the phone - I have done it many times on my Watch 2 while my phone is at home.

<comment><AUTHOR> I was definitely unaware, thanks for pointing it out. Just to confirm, the watch needs connectivity, right? So, I assume, it's over wifi. Correct?

<comment><USER6> It's NFC, which is a radio signal, so no connectivity is required aside from the electricity needed to send the signal from the watch. It's pretty analogous to swiping a physical card in that regard

<comment><AUTHOR> Oh I didn't know it was just NFC, I don't know why I was convinced it was a 3-party protocol requiring device connectivity. Good to know.

</comment></comment></comment></comment><comment><USER7> > now I only need a speedo with a key pocket

Would be nice to have car and/or house unlock via the Watch too! Can't see any technical reason why this wouldn't be possible. :)

<comment><AUTHOR> On the house, it's just because I'm renting... but maybe I can ask my landlord :)

<comment><USER7> Yeah, I rent too. I got a Sesame lock off the Kickstarter but I've been too lazy to install it...</comment></comment></comment>