Program your next server in Go - <AUTHOR> https://talks.golang.org/2016/applicative.slide#1 <comment><USER7> All of the server backends at my company are written in Go. This was a result of me writing a couple servers in Python a few years back, ending up with lots of problems related to hanging connections, timeouts, etc. I tried a couple different server libraries on Python but they all seemed to struggle with even tiny loads. Not sure what was up with that, but ultimately I gave Go a swing, having heard that it was good for server applications, and I haven't looked back. It has been bullet proof from day one and I am overall happy with the development experience.

That was the good. The bad? Garbage collection, dependency management, and lack of first-tier support in various libraries. Garbage collection makes the otherwise lightweight and speedy language a memory hog under heavy loads. Not too bad, but I have to kick the memory up on my servers. Dependency management is a nightmare; honestly the worst part about it. The lack of first-tier support in various libraries is a close second. AWS's API libraries had relentless, undocumented breaking changes when we were using them, all on the master branch of their one repo (breaking Golang's guidelines for dependencies). Google itself doesn't actually have any real API libraries for their cloud services. They autogenerate all API libraries for golang, which means they're not idiomatic, are convoluted to use, and the documentation is a jungle.

We continue to use Go because of its strengths, but it just really surprises me how little Google seems to care about the language and ecosystem.

<comment><USER8> > We continue to use Go because of its strengths, but it just really surprises > me how little Google seems to care about the language and ecosystem.

Go is certainly a language that is used at Google, but AFAIK a lot of "Googlers" don't really like it and don't use it. It certainly not the "official language at Google", given the weight of C++ and Java there. But that's the consequence of being opinionated. Using Go means having Rob Pike over your shoulder telling you how to write code. And he made sure you can't escape that fact since there is no place for "ninja coding" with Go.

<comment><USER9> >> given the weight of C++ and Java there.

Python as well.

>> how little Google seems to care about the language and ecosystem

Let's compare with Microsoft. The top four out of five users at StackOverFlow have top tags in C#, I guess Google have a long way to Go.

<comment><USER10> And yet the os group at ms is famous for their naked derision of the .net Framework.

<comment><USER9> Hum .Net is their own dog food .. did you mean Android/iOS? :-D

<comment><USER9> What I mean was that M$ have competing offer to Android/iOS but it is not getting the upper hand even within their own organization.

</comment></comment></comment></comment></comment></comment><comment><USER11> Go has been great for me at providing things like simple microservices, network plumbing, CLI tools and that kind of thing. The C integration is also super simple and makes it easy to wrap up third-party libraries.

It's also a bit tedious to write in practice. It's dogmatic, and that's obviously a benefit in some ways but comes with the cost that quite a lot of time in my experience is wasted fiddling around with program structure to beat it into the way Go wants it to work. Dependency management is better with Glide but still not perfect. The type system is quite annoying, and although it's a cliche the lack of generics is quite annoying. Lots of silly casting to and from interface{} or copy-and-pasting code gets old quickly.

Still, it's a great tool for its niches and I really think everyone should pick it up and use it - the idea of simplicity it promotes is actually kind of interesting, in contrast to the "showy" features one might expect of a modern language.

<comment><USER12> Last night I was beating my head against the desk on some highly concurrent code that involved each co-routine satisfying a simple rate limit, among other things. Two hours later I had it working and the final implementation ending up half the size of the original (~1k LOC -> 500 LOC).

I would upgrade your phrasing to: "frustratingly dogmatic in an ok way".

</comment></comment><comment><USER13> > When writing code, it should be clear how to make the program do what you > want. Sometimes this means writing out a loop instead of invoking an obscure > function.

For example instead of the obscure function

        a.reverse()

you can use the clear for loop

        for i := len(a)/2-1; i >= 0; i-- {
            opp := len(a)-1-i
            a[i], a[opp] = a[opp], a[i]
        }

:(

<comment><USER14> Yes there are clearly examples where the loop is less clear than the function. But I think they wanted to avoid complex 'functional' code like this:

        Averager averageCollect = roster.stream()
            .filter(p -> p.getGender() == Person.Sex.MALE)
            .map(Person::getAge)
            .collect(Averager::new, Averager::accept, Averager::combine);

        System.out.println("Average age of male members: " +   averageCollect.average());

From here: [https://docs.oracle.com/javase/tutorial/collections/streams/...](https://docs.oracle.com/javase/tutorial/collections/streams/reduction.html)

A lot of the time it is clearer as an explicit loop, _especially for other people to read_. But it is annoying a lot of the time. I still think they should add generics.

<comment><USER15> I can fully understand that example, only someone without FP knowledge would not get it.

<comment><USER14> Exactly the point. And that was a fairly simple example. I've seen much worse in real code.

</comment></comment></comment></comment><comment><USER16> I love Go.

It has become the default Go-To (pun intended) language for me for almost anything that needs to be small and portable.

However, I don't see myself writing a full server with it, I would still prefer a dynamic language like Ruby/Python for that and use Go for micro- services CLIs and the rest.

For example:

Our main application is Rails, it communicates with SOLR as the search index, in between the application and SOLR there's a proxy server that backups the documents onto S3 and also does Round-Robin between slaves.

One other thing is that we use Go to communicate with all external APIs of 3rd parties, the application code is rails and it communicates transparently with a Go server that fetches the data from 3rd parties and responds to the main application.

<comment><USER8> Go type rigidity makes Go code tedious to write. Instead of thinking "How can we solve that problem" developers writing Go end up thinking "How can we make the problem fit Go type system". I'm not even talking about concurrency here, I'm talking about Types. Saying otherwise would be dishonest, unless one has never used anything but C... Anybody who doesn't believe me just has to look the reflect package. Reflection packages are usually a good indication of language capabilities when it comes to statically typed ones.

It doesn't make Go a bad language,it has a some good percs, it's just frustrating that its authors conflated simplicity with rigidity. Also I hate when languages have hidden APIs, i.e. things the language can do that the programmer can't. Go is full of these (for instance append which is a parametric function since it knows the proper return type no matter what type of slice you pass it, but you can't write your own? ).

It's good think that it requires very little investment to get started, but it becomes highly frustrating when one stumbles on its limitations.

<comment><USER17> I've been writing Go daily for almost two years now and outside of wishing for generics a few times I've never struggled to fit a solution into the type system. I've certainly never considered going back to a duck typed language like Python or Ruby. Not once. Not ever. We have slowly replaced even our glue scripts that are written in Python with Go versions because maintenance and understandability trump any perceived speed advantage of writing something in Python.

<comment><USER18> As soon as a system reaches a given size, not having static types becomes unwieldy. Go's type system is great. Though my code still uses the var type declarations.

<comment><USER17> The further I get away from Python the smaller that given size limit becomes. After two years? It's at about 100 lines...

To me, the power of Go's simplicity is almost always underestimated by the language's detractors. I can look at code my team wrote two years ago and with a few <leader>gd's in Vim I know what's going on. Obviously Python fails this test, but even a high-level static typed language like C# can suffer greatly from all the magic one can invoke (Linq being a great example).

What it comes down to is that Go doesn't give you many ways to be clever. Younger me who loved template metaprogramming in C++ would scoff at this statement, but if you go back and have to reverse engineer your own cleverness enough times you really, really start to dislike the practice.

<comment><USER19> Yeah, I find that Go has influenced my code structure for the better in other languages. I'm much more likely to think carefully about a problem and consider alternative approaches for simplicity before just dropping a `template` keyword in C++, for instance. In Ruby, I am far less inclined to reopen classes. Etc.

</comment></comment></comment></comment></comment></comment><comment><USER20> What about debugging? This is the major pain point for me. I've tried using GDB, but...

> GDB does not understand Go programs well. The stack management, threading, > and runtime contain aspects that differ enough from the execution model GDB > expects that they can confuse the debugger, even when the program is > compiled with gccgo. As a consequence, although GDB can be useful in some > situations, it is not a reliable debugger for Go programs, particularly > heavily concurrent ones. Moreover, it is not a priority for the Go project > to address these issues, which are difficult. In short, the instructions > below should be taken only as a guide to how to use GDB when it works, not > as a guarantee of success.

[https://golang.org/doc/gdb](https://golang.org/doc/gdb)

<comment><USER21> Have you tried out Delve? [https://github.com/derekparker/delve](https://github.com/derekparker/delve)

I've only used it for simple cases, so I don't know if it helps with your criticisms, but it was designed for Go. I mention this because it seems like many gophers aren't aware of Delve.

<comment><USER22> I've used Delve from the go plugin in PyCharm and it seems to work pretty well.

</comment></comment></comment><comment><USER23> I like slide 41 [0].

        What just happened?

        In just a few simple transformations we used Go's concurrency primitives
        to convert a

        - <USER2>
        - <USER3>
        - failure-sensitive

        program into one that is

        - <USER4>
        - <USER5>
        - <USER6>
        - robust.

        No locks. No condition variables. No futures. No callbacks.

It's the ability to make these kind of transformations effortlessly at any level, whenever I need to, that make me appreciate choosing Go when solving many tasks.

[0] [https://talks.golang.org/2016/applicative.slide#41](https://talks.golang.org/2016/applicative.slide#41)

<comment><USER24> >No locks.

I'm sure the author means there's no _explicit_ locking done by the programmer, but readers should be aware that channels are actually implemented internally using locks (which are 4x slower than using a sync.Mutex yourself).

<comment><USER25> _> channels are actually implemented internally using locks (which are 4x slower than using a sync.Mutex yourself)._

Is that for both buffered and non-buffered channels?

<comment><USER26> Channels are implemented using locks, but "4x slower" is a meaningless microbenchmark number.

<comment><USER24> You're welcome to benchmark it yourself. I got it from [1] which is a pretty recent comparison.

[1] [http://www.jtolds.com/writing/2016/03/go-channels-are-bad- an...](http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you- should-feel-bad/)

<comment><USER27> GP said meaningless, not wrong

<comment><USER24> I found switching from channels to plain ol' queues to be an enormous performance improvement in a program sending hundreds of millions of messages, though I do agree in general that most programmers won't need to care about it.

The program was a financial model backtesting framework which I ended up rewriting in Rust because Go was simply too slow for what I wanted to do.

<comment><USER28> Relevant: [https://www.datadoghq.com/blog/go-performance- tales/](https://www.datadoghq.com/blog/go-performance-tales/)

<comment><USER24> This is great, thanks!

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> I'd love to see Nim on this diagram: [https://talks.golang.org/2016/applicative.slide#13](https://talks.golang.org/2016/applicative.slide#13) \- it could be close to the top right corner.

<comment><USER30> The go devs are very careful to avoid mention of all the other languages that compete in the same space and are significantly better.

<comment><USER31> I'd love to hear about those languages.

<comment><USER32> Erlang and Ada are two that I consider superior to Go.

</comment></comment></comment></comment><comment><USER33> I will have to try Go again. It seemed really awesome at first then quickly seemed like a regression in a lot of PL design things (which is good in some cases). I personally like rust but maybe I am a glutton for type based punishment.

 _Solution: design the language for large code bases_

This seems crazy but whatever works. I would assume that would only buy you some wiggle room inside whatever order of magnitude of committers you have. It seems like eventually you would need to split up the code base if you are having contention issues.

</comment><comment><USER34> I once tried to convince an enterprise java developer to give golang a try. The guy passionately hated it and the reasons were very very petty. The other younger engineers who did not have prior bias loved golang and they were productive so fast.

The person truly had a java supremacy attitude that was very difficult to deal with. Golang is a kind of shift in thinking that you have to first unlearn your existing ways of thinking and then you will have a place for it. Some people are not willing to take that leap of faith unfortunately.

<comment><USER35> > you have to first unlearn your existing ways of thinking and then you will > have a place for it.

Unlearning is not always acceptable, especially when you have to unlearn sound and proven practices, which Go often requires to do.

I think it really depends where you're coming from: people coming from dynamically typed languages like Python and Ruby are quite happy with Go since it's a small ramp up on the type ladder, but anyone who's used to static types and generics will usually see Go as a step back and refuse to take that step (for good reasons in my opinion).

To draw an analogy, imagine a Go developer is being asked to switch to Python and in order to convince them, you tell them they just need to unlearn a few things. To them, you are asking them to give up types and other practices that makes their code more robust, so it's not an acceptable argument.

<comment><USER36> > especially when you have to unlearn sound and proven practices, which Go > often requires to do.

Such as? I'm not really sure what "sound and proven practices" a Java developer would have to "unlearn" to adopt Go. Most of the differences between Go and Java amount to removing features that 20 years of Java experience have proved to be unsound or unnecessary (inheritance and exceptions, for example). From a feature perspective, Go is mostly a subset of Java. The features Go adds are mostly related to concurrency, and I've not heard anyone say Java does concurrency better than Go.

<comment><USER37> I'll say that Java doesn't do currency _worse_ than Go, that's for sure. It has all of the primitives in whatever arrangement you want to put them (Javaflow and now Coroutines if you want go-I'm-sorry-coroutines, native threads if you want those, and Go channels can be implemented in maybe two dozen lines), more flexible, battle-tested abstractions (such as Akka offering you an asynchronous, message-passing actor model, which could be written in Go but seems in practice to be passed up in favor of channels), and tooling around these that I find to be head-and-shoulders better than anything Go has (like multi-threaded debugging).

I've basically (willingly or unwillingly) turned into a Ruby person over the last few years, as neither Go nor the JVM really have a _ton_ to offer me right now, but I don't think a fair comparison of concurrency-related stuff, either in terms of tooling, libraries, or the language itself (I'd give Go this, except that you can't build an unbounded buffered channel and at that point the use of channels for what I write rapidly approaches zero), is nearly as clear as you assert.

<comment><USER38> Java's concurrency story is weak overall. Nearly all code still uses the old- style "synchronized" blocks, rather than ReentrantLock. This shouldn't be a big surprise, considering that ReentrantLock was only introduced recently. With synchronized blocks, you don't have any way of releasing the lock other than by exiting the block, which leads to some very contorted-looking code.

The fact that you can synchronize on literally any object means that your object lock is effectively part of your public API. Some other piece of code can easily grab your object, synchronize on it, and then start calling your methods, assuming that this will be atomic. And if you change to use a different lock later, it will break.

Sure you could use BlockingQueue to get some of the benefits of Go channels. But the standard library and pretty much any software you'll interact with were written before BlockingQueue existed, so they won't make use of it. You will have to fight your lonely crusade to use message passing on your own. Which in practice means that you won't be using message passing, just plain old mutexes and volatiles.

In Go, all code runs in goroutines which get multiplexed to kernel threads. In Java, nearly all code is blocking and uses an entire kernel thread. Sure you can use NIO to write an event loop-- just as long as you're careful to never, ever call a blocking function. But nearly every interesting function in Java can block. Including the DNS lookup functions Java provides.

<comment><USER35> > The fact that you can synchronize on literally any object means that your > object lock is effectively part of your public API

I'd argue that the fact you can lock on any object is a strength. These days, hardly any Java developer will use synchronized on methods and instead prefer the idiom:

        public class A {
            private Object lock = "";

            public void foo() {
                synchronized(lock) {
                }
            }

This allows Java code to be extremely granular in what gets locked, which has enabled very powerful multithreaded constructs and libraries such as ForkJoinPool and many others described in the Java Concurrency In Practice book.

</comment></comment></comment></comment></comment></comment><comment><USER39> How do the bullet points in "Why does Go leave out those features?" address why Go leaves out the features on the preceding slide?

All it talks about is clarity (important but not the only important thing) and I just don't see how any of the left-out things are _inherently_ unclear. I think you can write clear and unclear code alike with all of those left-out features.

</comment><comment><USER40> There are some questionable statements:

> Go differs from Java in several ways

> Programs compile to machine code. There's no VM.

This tries to imply that having a VM is a bad thing.

> Simple, concise syntax

The syntax is simple, but not overly concise. For example the lack of generics leads to a lot of repetition.

> Statically linked binaries

You can have them with Java, too.

> Built-in strings (UTF-8)

Should this suggest that Java doesn't have trings?

> Built-in generic maps and arrays/slices

Yeah! Some of the most awesome things about Go is the limited set of data structures and the limitation of generics for exactly this few structures.

> Built-in concurrency

It is questionable whether this is good or not. There are a lot of good concurrency libs for the JVM.

> Sometimes this means writing out a loop instead of invoking an obscure > function.

This is completely strange! The lack of abstraction is sold as a good thing. Actually a lack of abstraction leads to redundant and error prone code.

<comment><USER41> In regards to your last comment, abstraction is a good thing but there's a conversation to be had around quality of abstraction. Good abstraction doesn't age, or at least ages very slowly. Lack of abstraction in languages leads to innovation and iteration, that then leads to good abstraction. We are general too quick to assume that a new thing is good abstraction. Better, in some cases, to leave abstraction discovery in userland, as good abstraction is rare. The cost of poor abstraction within a language is API and cultural lockin, when better solutions are found.

</comment></comment><comment><USER42> I had a PHP program that processed HTTP requests and stored some data onto a local database, and decided I needed to rewrite it for various reasons so I decided to choose Go. Some points I recall:

* Static typing is good.

* As I expected, the standard library and other packages available had the http & routing stuff I needed, which is all good.

* I like that errors are specified in function signatures, unlike exceptions in languages like ruby/python.

* I don't like errors being easily ignored, and return values being assigned default or arbitrary values. I once may have also accidentally used the wrong equality operator against nil.

* Defer is nice, but would be better if it was based on current {} scope.

* Append on arrays? has very bizarre semantics sometimes mutating or returning a different reference.

* Initially I ran into trouble reasoning how to use some sql package and ran into "invalid memory" deference issues or some such when passing a reference. Thus, I'm skeptical about "memory safety."

This was only a simple program though and turned out to be worthwhile for me in the end.

<comment><USER43> memory safety imply that if you do something bad you will be stopped (with "invalid memory" issues for example), not that it is illegal to write something bad

<comment><USER42> Well I am also then interested in it being hard or illegal to write something bad :)

</comment></comment></comment><comment><USER44> Holding up Perl and JavaScript as examples of languages that are 'fun for humans' makes it pretty clear I'm not the target market.

<comment><USER45> Can't speak for perl because I have only seen some horribly complicated code in it (which probably speak more of the author and not the language itself) but what's not fun about JavaScript ?

<comment><USER46> I used Perl for years, and it's still my go to language for quick text parsing. I stayed away from the bizzare "object oriented" syntax (They're not classes. They're packages, just called with arrow operators instead of like normal functions. But being Perl, you can just use the package and call the functions yourself because TMTOWTDI! (Blech.)) Also Perl's support (or at least Perl 5 (Does 6 even exist? It's like a unicorn like Duke Nukem Forever or Guns-n-Roses Chinese Democracy, only those eventually got released.)) for complex data structures (including multidimensional arrays) requires explicit reference instanteation and dereferencing, like C pointers. It's the biggest pain point.

<comment><USER47> I am no Perl apologist, but they DID finally release Perl 6:

[https://perl6advent.wordpress.com](https://perl6advent.wordpress.com)

</comment></comment></comment></comment><comment><USER48> What are some cases where I would choose to write a server in Go instead of in Erlang?

<comment><USER49> First thing on duckduckgo when you search for how to write a server in erlang:

[http://20bits.com/article/erlang-a-generic-server- tutorial](http://20bits.com/article/erlang-a-generic-server-tutorial)

That's just ridiculous. Erlang looks like php and python had an unholy child.

<comment><USER50> I won't downvote you because you are certainly entitled to your opinion, and there is no way I'm going to get into an Erlang vs Go For Writing Servers argument, but if you immediately write off Erlang/OTP because of how it looks, you are going to miss out on some pretty amazing server writing functionality.

</comment></comment></comment><comment><USER51> _" >50% of code base changes every month"_

I wonder what unit is being counted here. I don't think it's possible to actually review and rethink 50% of what has been created before. That's just not sustainable.

<comment><USER52> > 5000+ developers across 40+ offices

That's an _enormous_ amount of manpower.

<comment><USER51> That doesn't matter. Only growth of manpower matters. The fundamental problem stays the same regardless of how many people you have.

If you add code and revise 50% of it every month, the code base is bound to grow and the share of time spent on maintaining the old code grows as well until development of new code grinds to a halt.

Unless of course there is massive growth in hiring. But that isn't sustainable.

[Edit] Well, I forgot one possibility: Deleting code.

<comment><USER53> [https://www.theatlas.com/charts/4ySTybWY](https://www.theatlas.com/charts/4ySTybWY)

(Can't vouch for accuracy.)

</comment></comment></comment></comment><comment><USER54> One important niche I see that Go serves very well is in distributed, fault- tolerant deploy platforms (aka schedulers), like Kubernetes or Mesos. If you look at the amount of tooling that uses Go, you almost feel there just is no other choice out there.

I would not adventure to say state-of-the-art schedulers would not have been possible without Go, but for sure Go fits the requirements pretty well.

<comment><USER55> > I would not adventure to say state-of-the-art schedulers would not have been > possible without Go, but for sure Go fits the requirements pretty well.

AFAIK Mesos is mostly written in C++. Aurora - a Mesos framework & scheduler from the same folks is written in Java & Python.

<comment><USER54> Yes, what I meant is that a lot of tooling around those is done in Go.

</comment></comment></comment><comment><USER56> Can anyone convince me to use Rust over Go, or the other way around?

My target machines range from i7s with massive amounts of RAM to Raspberry Pi with slightly-less-massive amounts of RAM.

<comment><USER57> I think the tldr; of this (often raised...) argument boils down to:

        Don't use rust if you're asking that question.

If you _could_ implement your solution in go or rust, then go is probably a more appropriate choice; it's a good high level solution for high level problems.

Rust is not a good solution for high level problems; it's a good solution for low level problems where go would be a terrible choice; and it's a good solution for high level problems where other choices are even worse (eg. C++).

They're both good languages, and you'll _learn way more_ from picking up rust than you will from picking up go, so if you're just screwing around and want to learn a language this year, absolutely, pick rust or clojure. Go isn't on the list for 'interesting programming languages'.

...but if you have an actual problem you're trying to solve, I would be hard pressed to enumerate the reasons why you would pick rust if the problem was solvable using go. Maybe because your C dependencies would be easier to call from rust than go? That's all I can think of.

<comment><USER58> > Rust is not a good solution for high level problems

Who is saying that ? Not the Rust team, nor the Rust users … Rust is a general purpose programming language, and it's pretty high-level (in terms of features, think about functional programming for instance). The only reason I wouldn't advise everyone to write their stuff in Rust atm, is the youth of the ecosystem (which is growing rapidly, but is still a bit too early-stage): their is no intrinsic limitation in the language that make Rust «not a good solution».

<comment><USER57> I'm saying it.

The piston developers are doing what right now? Writing a _new programming language_ (dyon). Why are they doing that? Because rust is great for prototyping games in? no.

...rust _is_ verbose. It _is_ statically typed, it _is_ less productive than some other languages and it _is_ hard to learn.

Now, you get a whole lot of other benefits in exchange for that, absolutely, and technically speaking, rust is a super awesome and sophisticated language.

...but _right now_ , it has neither the ecosystem nor simplicity for picking up and _practically solving high level problems_.

If you have a problem, right now, you want to solve: pick go.

... _unless_ your problem is something that rust would be better at, and those things are low level things, like building game engines, not high level things like building web applications and cross platform desktop chat applications or machine learning solutions to driving cars.

You _can_ build high level applications in rust, and in C++; the point I'm making is that unless you actually have a reason for picking them (and there are plenty...), don't.

Pick the tool for the job; rust is a great tool for the right job.

Go is a better tool for a lot of applications; and a totally useless one for others.

/shrug.

We don't need to pretend rust is general high level language you should pick up and use for any problem domain. It's not. You're shooting yourself in the foot if you use it as though it was.

<comment><USER58> > The piston developers are doing what right now? Writing a new programming > language (dyon). Why are they doing that? Because rust is great for > prototyping games in?

I agree with that, Rust is not a scripting language. Dynamically-typed scripting languages have proven their efficiency for prototyping.

> rust is verbose. It is statically type, it is less productive than some > other languages

Than scripting languages yes, but it's exactly on the same side than Go on this point. Scripting languages are extremely convenient for small projects, but are more difficult to maintain in the long run if the project grows too big. (I personally live coding JavaScript, and a the project grows we are progressively add a static-typing layer (flowtype.org) to our code for the sake of maintenance).

> it has neither the ecosystem nor simplicity for picking up and practically > solving high level problems.

There is a real trade-off between scripting languages (Python, Ruby and Nodejs), and statically-typed ones (Java, Go, and Rust), but it's not related to being high-level or not. In term of abstractions and features, Rust is at least as high-level as Java & Go.

> If you have a problem, right now, you want to solve: pick go.

We are using some Go at my company because we wanted to follow the trend, but frankly unless you want to built a simple system with no dependencies, Go is not ready to solve problem «right now» either, because the ecosystem is still really poor. If you have a problem, right now, you want to solve, you should probably still pick Java over Go, even if a lot of people (me included) don't like Java … Basically I think Java is the most important factor of success of the Go language: Go feels like Java, but in a younger and trendier way.

> We don't need to pretend rust is general high level language you should pick > up and use for any problem domain. It's not. You're shooting yourself in the > foot if you use it as though it was.

Rust is a «general high level language», with the same high-level generality than Go or Java.

I bet one can chose any* Go or Java code sample, and rewrite it in Rust with around the same amount of code and without introducing any memory issues (what you wouldn't be able to do in C or C++). I think that's a good illustration of Rust being a «general high level language».

*unless it depends on a library that has no equivalent in Rust (as I said before, the youth of Rust's ecosystem is the reason not to use Rust in S1 2016).

> and it is hard to learn.

It is indeed, no discussion about that.

<comment><USER59> > (what you wouldn't be able to do in C or C++)

I would and many more people also would but for sure it would be harder/more complex in C/C++ than in Go. You wrote that as it would be impossible to do it in C or C++ which is not true.

<comment><USER58> Of course it's possible to do the same thing in C, but most likely not with «the same amount of code», nor with «memory safety». ;)

<comment><USER59> > nor with «memory safety»

I've wrote that you can do it with memory safety which is possible BUT it's more complex in languages like C/C++ that do not guarantee memory safety (it's your responsibility). If it was not possible then you would not have anything on your screen right now. I am writing that because someone that is not familiar with those languages would get impression from your comment that memory safety is impossible in C/C++ which is not true.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER60> > Clarity is critical.

When you need to write high performance code this is a great maxim. I enjoy the simplicity of Go and the guarantees it provides. Being able to reason about code and not having to guess is a win for any development team.

<comment><USER61> IME, clarity and reasoning are weak points of Go, relative to other systems programming languages (but perhaps not to dynamic languages):

1\. Slices make it hard to reason about aliasing. bar = append(foo, val): does bar now alias foo? The answer is the worst possible: "sometimes."

2\. Closure semantics make it hard to reason about thread safety. I converted this serial loop to parallel using goroutines; did I introduce a race condition? I have to look at each variable to decide. (Any sort of const capturing would go a long way here).

3\. Goroutine leaks can be hard to reason about. For example, a channel that is not sufficiently buffered can result in a leak.

4\. Nullable maps and channels reduce clarity.

5\. The "redeclare" semantics means := sometimes does not introduce a new variable

<comment><USER60> I didn't mean to gloss over the go routine problems. You're absolutely correct, when there exist tools like the race detector it makes it evident that you can write incorrect concurrent programs. Becoming proficient at using the concurrency patterns in Go takes time but it is an advanced topic.

Thanks for writing up these common mistakes.

<comment><USER38> Those aren't common mistakes, just things he dislikes about the language. For example, I don't care whether := sometimes does not introduce a new variable (have never had a bug related to that). I don't find the closure semantics any worse than Java's (sure Java requires captured variables to be final, but it doesn't require them to be immutable).

I find append's semantics to be pretty intuitive. But then again, I'm familiar with realloc in C, which is where it came from. At any rate, slices are references to an underlying array. If you are making one slice from another slice in a way that potentially doesn't involve copying, you should expect the new thing to alias the old thing.

People often complain about channels having limited buffer sizes. But if channels had unlimited buffering, they'd complain about memory leaks and inefficiency.

A list of common mistakes in Go would be interesting. It would probably start with the "assigning a typed nil value to an interface leads to interface != nil" wart.

<comment><USER62> They seem to be language issues which make development more error-prone.

And dismissing them just like that won't make them go away :)

</comment></comment></comment></comment></comment><comment><USER63> I use Go exclusively for command-line applications, previously using Perl (ducks). It's a fairly simple language, you can pick it up quickly, and gofmt/godoc/etc are useful utilities in reducing friction.

</comment><comment><USER64> I really like go. I just love that it compiles to a native binary and is so easy to distribute. I love the way interfaces work and that types specify interfaces automatically without explicitly specifying that.

I love the "strictness" of the language - for example the code won't compile if you declare a variable and not use it, or import a library and not use it. I love that there is a standard gofmt which means code auto formats to a standard format. These features really help set some "discipline" when working in a team.

I love the way concurrent code can be called easily and the use of channels. I love the performance - it has been more than fast enough for my use cases so far. I love that I can get started with an HTTP server using just the standard library, and the most popular web frameworks in go are micro frameworks.

Overall, there's a kind of a simplicity about the language that underlies all of the above things, and that is what makes me excited about go.

I have used go in some minor projects that have been running peacefully for months without any hitches, and am using it in a big project mostly in the form of microservices and scripts. It has become my favorite language now.

</comment><comment><USER65> "Sometimes this means writing out a loop instead of invoking an obscure function."

I can't help but think this is specifically a dig in C++'s direction. Since C++11 lambda's I've been using <algorithm> a lot more and I don't think you could get me to go back at this point... Yes I had to learn exactly what a few methods do, but now I have beautiful straight line code...

</comment><comment><USER66> I've been experimenting with this concept with C# recently [0], where I have a small backend written in C#, exposing a simple, RESTful HTTP server, that automatically finds itself a local port to run on and opens the default browser to a default page.

It's actually kind of nice. Until I did this the first time, I hadn't realized just how much bullshit I had previously put up with, with setting up local web servers, trying to get configurations down, etc., etc. At some point, I think most web framework's configuration options just got too complex to be considered _configuration_ options and became weird, poorly defined scripting languages for defining web servers. Having a real programming language to do that instead is just a wonderfully smooth experience.

Some things I plan on implementing with it:

* local file system access, to ultimately implement an FSN [1] clone in my WebVR project.

* my own Leap Motion WebSocket service, because the default one doesn't use the latest Orion beta and its associate JS library is complete garbage.

* A similar dude for MS Kinect data.

* Ultimately, get the previous two to run over WebRTC instead (not easy, there is no WebRTC library for Windows outside of major browser implementations) to be able to stream their respective camera data.

* Live raytracing of model textures for baked lighting in scenes in the WebVR session.

Right now, it's just a source file I drop into a standard C# console project. I'm thinking about making it a full-on library, though at this point there isn't much need.

[0] [https://github.com/capnmidnight/HereTTP](https://github.com/capnmidnight/HereTTP)

[1] [https://en.wikipedia.org/wiki/Fsn](https://en.wikipedia.org/wiki/Fsn)

</comment><comment><USER67> > Lingo: Logs analysis in Go, migrated from Sawzall

Would love to play around with this

<comment><USER68> As far as I could find not open sourced, but talked about at the data science blog (which is generally awesome): [http://www.unofficialgoogledatascience.com/2015/12/replacing...](http://www.unofficialgoogledatascience.com/2015/12/replacing- sawzall-case-study-in-domain.html)

</comment></comment><comment><USER69> _server is a pretty loose term. Most_ servers* these days require some sort of full stack, with frontend, ORM, etc... Go adds a lot of development time if you need all of that. ...On the other hand, one off tiny microservices, it's absolutely great!

</comment><comment><USER70> The slides are awesome and I really am fond of go, but the examples using channels are all more code to write considerably than I'd write in C# or JavaScript with async/await and not any more robust or safe.

Go is great for actor based systems where you model things using channels and goroutines for what they stand conceptually - not when you use it to simulate Task.WhenAll/Promise.all with a timeout.

I think _that's_ what they should be selling - that your server's architecture should typically be different.

<comment><USER36> Yes, but in Go you don't have to deal with the [colored function problem][1], and the code to parallelize I/O is no different than the code to parallelize computations. I agree that these examples don't do justice to Go's concurrency facilities--the most compelling examples are probably too complex for a slide deck.

[1]: [http://journal.stuffwithstuff.com/2015/02/01/what-color- is-y...](http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your- function/)

<comment><USER70> The code to make I/O concurrent _should_ in my humble opinion look different from the code to parallelize computations since well - in I/O you only care about concurrency and in computation you care about parallelism.

<comment><USER36> It's not obvious to me why this distinction is useful. Could you explain?

</comment></comment></comment></comment><comment><USER71> Any comment on Swift vs Go, potentially for server programming?

<comment><USER72> I don't think Swift is particularly mature in this area yet, and it's concurrency depends upon Grand Central Dispatch. Go on the other hand is rather mature, especially for its age.

Other than that, it really depends on what the server is for, but in general I would say Go is probably a better choice.

If you're interested in something similar to Swift for the server, I think Kotlin w/ Spring Boot would probably be a safer bet at this point.

</comment></comment><comment><USER73> Go is a phenomenal systems programming language and becoming quite useful as a general programming language too. It's clear from the projects that are now coming into existence that Go lends itself well to the world of distributed systems and from the language design you can see that it was created with network programming in mind. The fact that concurrency is built into the language and errors are treated as values that should be dealt with just highlights those facts.

We used Go at Hailo for our microservices platform and it served us incredibly well. I've gone on to create an open source project called Micro [https://github.com/micro/micro](https://github.com/micro/micro) that builds on those past experiences. It's just a joy to write micro services in Go.

</comment><comment><USER74> Go is my secret and I wish less people used it, so I had an advantage over them ;) Edit: typos

</comment><comment><USER75> The presentation focuses a lot on [web] servers and google scale, but I found that Go also works quite well for applications/services on embedded linux systems.

Main pros for me there are:

      - Easy to cross compile and deploy
      - Daemons often need to do a lot of communication (some also for providing web APIs) and need to embrace concurrency. Both are covered very well by Go's ecosystem.
      - Compile-to-binary eases distribution concerns in cases where you want to avoid to publish all source code (and thereby know-how) compared to VM languages or scripting languages.

</comment><comment><USER76> golang is great, i use it to do 3 things thus far: restful api server (net/http, gorilla mux), dynamic web server (net/http, amber, sql), and websocket server (net/http, gorilla websocket, redigo/redis). the libraries are well implemented, the syntax is beautiful imho, and i'm able to quickly write code similar to interpreted languages like ruby, python, but scale much higher. i used to do lamp, then shifted to python tornado, ruby sinatra, nodejs/expressjs, but find golang to just be more compact and fast. my sinatra environment required rbenv, gems, and i just wasn't impressed with it.

what i like the most about golang is that the end result is a binary where my production server doesn't need to have any dependencies except for the ability to run elf binaries. i like having this option, but in reality the binary size gets pretty unwieldy for upload, so i actually end up doing a pull on the source code, compiling and starting up.

package management has not been a problem for me.

i do find html template packages to be a bit deficient, amber, ace, there are ports of haml and jade, but they all seem pretty half baked. i had to have a lot of hacks in my code to get this stuff working.

also sucks that there isn't a standard orm, but i can hang and keep up with raw sql.

the language expressiveness is not as convenient as say ruby, but it's pretty close.

</comment><comment><USER77> I always see Go promote Clarity/Readability and yet in the second example its already "fmt.Fprintln". That is not easily readable for humans.

</comment><comment><USER78> I wonder why on that fun/fast diagram, it appears as if Perl faster than Python, which is faster than Ruby. They're all about as slow.

</comment><comment><USER79> The only place I would want to use Go is for a server tbh. It isn't all that great for anything else imho.

<comment><USER16> It is amazing for dev tools and CLIs.

Perfect example for this is Hashicorps products, taking out Vagrant it is 100% written in Go.

Having a single executable tool that you can download and run anywhere is super powerful. You develop once and you build it for every system. It's the definition of delight to me.

<comment><USER80> I'd argue that CLI tools are really a _better_ example of what Golang is good at.

Most of the things purported to be major wins for Golang on the server side are available or better in other environments.

For CLI programs that need to be a little more sophisticated than bash Golang is quite nice.

<comment><USER16> Agreed. Check out my comments on this threads...

</comment></comment></comment></comment><comment><USER81> The fast/happiness graph of languages is pretty interesting.

Unrelated: Rust would probably be around the right-most area in the horizontal axis, close to C and C++, and a little below Go in the vertical axis.

</comment><comment><USER82> Which kind of applications does one write in Go? Asking this from perspective of a developer working mostly on business apps with Angular frontend and .NET (C#/F#) backend.

<comment><USER8> If you use C#/F# you don't need Go, .net is coming to Linux by the way so you definitely don't need Go.

With Go you'll basically have to rewrite asp.net from scratch if you're used to that, because frankly the ecosystem is poor if you don't stick to data transformation/ marshaling with an HTTP server. No full featured ORM, no good Logging library, no Razor like view layer, piss poor web frameworks and an extremely rigid language with a rigid type system if you are used to F# and C#. The only advantage of Go is the fact that you can deploy a single executable with no dependencies on a server. That's it.

<comment><USER82> Oh, I definitely don't want to switch to Go :-) I did take a look at it once and decided that it is not for me.

That being said, I still wonder what types of applications are so suitable for Go that people decide to use it instead of other languages?

</comment></comment></comment><comment><USER83> Go is a fine language and a very good run time, though having written a large program with it I've learned its warts well enough to not want to use it again personally.

</comment><comment><USER84> I might have strange requirements for a server, but I need rdma, verbs, libfabric... Is there any way to use them in an idiomatic way in go?

<comment><USER85> Not that I know of. That sounds like it goes against much of what Golang builds around and the areas I've had to hook into low level areas such as the kernel for NetFilter required me to go down to C

</comment></comment><comment><USER86> I think "Program your next server in Go" is a little too broad, the specific language features that Go explicitly leaves out makes it hard to build an extensive backend server. Go is best suited to use cases listed in these slides: simple services that do very focused things.

I love Go and used it to build some very useful web hook and CLI tools. It just doesn't lend itself to something where you expect to have a vast set of APIs under one Go project.

</comment><comment><USER87> Can't read on IOS

</comment><comment><USER88> Here are the problems I had when tried to write a simple CLI utility (tool to run any program in seccomp-bpf based sandbox) in Go:

\- using case of a first letter of identifier as a public/private flag. You end up with half names starting in a lowercase letter, half in an uppercase (the code looks inconsistent) and forgetting how to spell them. And having to rename the function everywhere when you decide to change it from private to public.

\- no official package manager. Unclear how to add external libraries to your project and how to set specific version you need. I ended up adding necessary files into a separate folder in my project.

\- Go manual suggests you have single directory for all projects and libraries. That was inconvinient because I develop on Windows and use Linux only to test and run code in /tmp directory, I do not keep the code there. And why would I want to keep unrelated projects inside the same directory anyway?

\- no rules how to split contants, types and functions into files and folders. For example in PHP there are certain rules: each class goes to its own file and you always know that class Some\Name is stored at src/Some/Name.php. Easy to remember. And in Go you never know what goes where. Large projects probably look like a mess of functions scattered around randomly

\- no default values for struct members, no constructors

\- no proper OOP with classes

\- standard library is poor

\- open source libraries you can find on github are not always good. I looked for library to handle config files and command line arguments and didn't like any.

\- standard testing library doesn't have asserts

\- easy to forget that you need to pass structures by pointer (in OOP objects are passed by reference by default). And generally use of pointers makes the code harder to read and to write.

\- weird syntax for structure methods. They are declared separately from the structure.

\- go has 2 assignment operators (= and :=) and it is easy to use the wrong one

\- having to check and pass error value through function calls instead of using an exception. So most of functions in your code will have two return values - result and error

\- no collections library

\- simple things like reading a file by lines are not so simple to implement without mistakes

\- static typing is good but sometimes you cannot use it. For example I wanted to have the options in a configuration file mapped to the fields of a structure. I had to use reflection and every mistake lead to runtime panic. And you cannot use complex types like "pointer to any structure" or "pointer to a reflect.Value containg structure" or "list of anything" or "bool, string or int".

Of course Go has also many good parts that might outweight its disadvantages but I am not writing about them. For example I have not used goroutines but they look like a simple solution for processing async tasks or writing servers.

I think Go is not ready yet for writing large applications. It might be ok if you write a small utility but I cannot imagine ORM like Hibernate or web application written in Go.

Also I took a look at the code in the presentation. I wouldn't want to write such code. For example, here [https://talks.golang.org/2016/applicative.slide#20](https://talks.golang.org/2016/applicative.slide#20) they use static methods (http.HandleFunc(), log.Fatal()) instead of instance methods. So you cannot have two logs or two servers. Using static methods everywhere is bad especially in large applications. Google itself uses Go only for small utilities like simple proxy servers.

<comment><USER19> Many of these points are simply wrong, or confused.

</comment></comment><comment><USER89> I'm afraid HN has a serious problem with downvoters. Why -in heavens name- is the above a question that deserves downvoting? UPDATE: whoray - I got downvoted too. Gee man. Just not worth it. Buy and thanks for the fish.

<comment><USER90> We detached this subthread from [https://news.ycombinator.com/item?id=11856539](https://news.ycombinator.com/item?id=11856539) and marked it off-topic.</comment></comment>


Ionic-powered nanosatellite can go to the Moon on drops of fuel - <AUTHOR> http://www.kurzweilai.net/ionic-powered-nanosatellite-can-go-to-the-moon-on-drops-of-fuel

<comment><USER2> I am nowadays inherently distrustful of anything related to Kurzweil, and I ignore links to that domain. The article is probably a reposting of [http://www.physorg.com/news/2012-03-moon-fuel-ionic-motor- sm...](http://www.physorg.com/news/2012-03-moon-fuel-ionic-motor-small.html) , titled "Getting to the moon on drops of fuel: An ionic motor for small satellites"</comment>


Blizzard pushed release date of StarCraft II to the first half of 2010 - <AUTHOR>

This is bullshit...<p>http://www.sec.gov/Archives/edgar/data/718877/000110465909047364/a09-20544_1ex99d1.htm <comment><AUTHOR> "Blizzard Entertainment has moved the anticipated release date of StarCraft II to the first half of 2010 to coincide with the relaunch of its upgraded Battle.net® online -gaming service."</comment>


ReactJs Component Library – Powered by Robe - <AUTHOR> https://github.com/robeio/robe-react-ui <comment><USER2> I hope this can be wrapped for clojurescript. Good job

<comment><USER3> If you try please send us the results.

</comment></comment><comment><USER3> Hi, I am one of the contributors and I will be noting all the things you suggest. Thanks...

</comment><comment><USER4> Hi, it's a great framework that you develop projects in a short time!

<comment><USER3> Thank you</comment></comment>


Xtranormal software development video's  - <AUTHOR> http://www.leaseweblabs.com/2013/11/xtranormal-software-development-videos/

<comment><AUTHOR> Sad that Xtranormal is offline. These video's are very funny IMHO.</comment>


Show HN: Worfor – Curated list of job and internships in AI Industry - <AUTHOR> Hello, I'm maker of Worfor (https://worfor.com) . Worfor - curated list of jobs and internships in AI Industry. We have 20% discount for all HN members. Just use this coupon: HackerNews20. If you are an startup - ping me directly and we will try to find best solution for you. <comment><AUTHOR> 5 minutes after posting on HN. Hacker found way how to post job without payment:D If you are reading this - how did you do this?</comment>


Lets do these 10 things in a day? - <AUTHOR> http://ink.bluegape.com/lets-do-these-10-things-in-a-day/

<comment><USER2> Don't go into the office, and don't call your boss?

Call up your first kiss, and thank them + wish them well?

I will not do several of these things, any day, ever.

</comment><comment><USER3> Why is this on HN?

</comment><comment><USER4> No</comment>


Parser as Prototype: why choice-based games are more interesting (2013) - <AUTHOR> https://threeedgedsword.wordpress.com/2013/12/05/parser-as-prototype-why-choice-based-games-are-more-interesting/ <comment><USER2> I think the most promising interface is a parser with Threaded Conversations – an interface which isn't limited only to conversations btw. It allows the author to give suggestions for the next turn, while allowing the player to type anything at all. It allows for unique actions without coding up verb after verb each for a single use. It would even be possible to have the suggestions be hyperlinks so that the players wouldn't have to type unless they wanted to go beyond the suggested paths.</comment>


Amazon, in Threat to UPS, Tries Its Own Deliveries - <AUTHOR> http://online.wsj.com/news/article_email/SB10001424052702304788404579521522792859890-lMyQjAxMTA0MDIwNDEyNDQyWj <comment><USER2> I never understood why Amazon doesn't just get into the drive-through market.

As a consumer with children, it's a major hassle to go to the grocery store with my kids in tow. It's also unacceptable to wait 2 days to get what I order.

The ideal solution would be for me to go to Amazon Fresh, pick my location so I can be assured that everything listed is in stock, and then do my shopping.

On their end, the workers would pick the products from the shelves and toss it into bins with a barcode on them, just like they do at the Amazon Warehouses now. There would be 3 categories of bins: Frozen, refrigerated, and room temp.

When my order is ready, I would get an alert on my phone.

Then I would drive to an Amazon Fresh site and park in a numbered spot and either press a button on an adjacent speaker box or something or enter the parking spot number on my phone.

I would get a notice that an attendant is on their way. A few minutes later, a cart would come out with the bagged groceries and the attendant would load them into my car and I would leave.

This really seems like the best choice for Amazon. It lets them have regional centers for product warehousing so they don't have to ship cross-country, it lets consumers get products instantly without last-mile logistics problems, and it would let them gradually transition to their own in-house delivery for their regular products and not focus on the products that need instant delivery. Having their own delivery unit, UPS, and local delivery companies would encourage competition and keep the prices low for them.

<comment><USER3> > It's also unacceptable to wait 2 days to get what I order.

Holy crap you need a reality check.

<comment><USER4> "I really need those cough meds right now."

"Mooooom, we're out of milk, and I want CEREAL!!!"

"Alright, so I have everything for dinner, but it looks like we're a little low on butter, so I can't make the cake like I wanted to :/"

Now add that you have kids to the scenario, and you've got to drag them along to what should be a 3 minute shopping trip.

There are a lot of situations where taking that long for something is pretty unacceptable.

<comment><USER5> I can see how 2 days can be unacceptable, but those reasons are just plain bad planning.

<comment><USER6> People plan poorly. There's a lot of money to be made helping people through that.

And when these services are widespread, people will be free of the necessity to expend energy "planning" their access to the essentials of life. Then we can focus on bigger and better things.

<comment><USER7> How would this service solve running out of milk at breakfast? How is this a problem that must be solved before we focus on bigger and better things?

<comment><USER8> This is bigger and better things. Every cancer research scientist with kids probably loses hours of potential work time a month dealing with dumb shit like "we're out of milk" that this would solve. I don't think being super- narrow-minded about "big ideas" contributes a whole lot to the progress of society; if it's something lots of people are willing to pay for, you have to accept the possibility that it's useful and contributes to society in a way that you couldn't think of immediately.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> This is such a natural extension for Amazon to move in to. I've never had a consistently good experience with UPS, FedEx, or USPS. The success rate varies but all three have caused packages to get lost, sent back to the shipper, or I'd get a "we don't know where your package is". Needless to say my confidence in the current shipping industry is low.

Amazon could gain a leg on the current shipping/logistics companies even if they focused on just a few key areas:

        * Real-time shipment tracking
        * Cardboard-less / eco-friendly boxes
        * Neighborhood locations to deliver packages to

Real-time tracking I think is the easy win. Setting up some form of eco- friendly packaging could be as simple as shipping your items in a reusable plastic bin, and then leaving you with the individual items you've purchased.

However, one of the big problems particularly in NYC is reliability. Most people don't have a doorman and rarely will the postman leave the package for you. Even if they did, a lot of people don't like the idea of having their Amazon box sit outside their door for anyone to steal. Amazon already has their locker system and I think that could be the difference-maker. If I could ship to a convenience store, or a reliable place then I'd be able to grab my deliveries on the way home from work. Plus Amazon could reduce the number of deliveries they have to make in dense cities.

<comment><USER10> > * Neighborhood locations to deliver packages to

In France we have such a system, "Point relais Kiala", not every internet shop allows it as an option but all the bigger ones do including amazon france. I can get my delivery to about 5 different places within a 10 minutes walk radius of me, and the advantage are numerous: no need to be there for an entire to sign because they can't tell you when it will happen, no "you weren't there I put the notification paper and you have to get your package at the post office" (leaving the package in front is not a thing like it seems to be in the US), real ability to check your package before signing, more reliable delivery time, .... And cost is the same as a regular delivery.

It just is much better overall. And for Premium subscriber, it's free just like regular delivery options.

<comment><USER11> The German and Danish post offices offer this as an opt-in choice for postal package delivery. You indicate that you want your packages delivered to a kiosk instead of your house, and anything bigger than a regular envelope that's mailed to you will go there instead. That way the stores you order from don't even have to agree to ship to the kiosk; you can order from Amazon.co.uk, who don't know anything about Danish postal kiosks, have it addressed to your street address, and it'll go to the kiosk instead.

</comment></comment></comment><comment><USER12> This could be a bad move for Amazon.

Amazon has amazing customer service. It just works. Parcel delivery is hard. USPS etc don't cock it up because they're lazy or stupid. So currently Amazon does the stuff that works and lets another company tAke the blame for the hard stuff. But in future people won't be saying "some company lost my package". They'll be saying "Amazon lost my parcel".

(There are some things Amazon gets weirdly wrong - I cannot fathom how search is allowed to be so terrible)

<comment><USER13> Amusingly for hard-to-reach locations both UPS and FedEx rely on an even better organization (US Post Office) to do their last mile delivery - as with the limited margins for USPS (federally legislated), it's cost effective for private delivery companies to simply farm it out.

Only the USPS has a charter/requirement to actually deliver to every address.

<comment><USER14> Additionally-- in large cities, the USPS has a key to most apartment outer doors, which allows packages to be left in a secured location instead of on a stoop.

</comment></comment></comment><comment><USER15> Good, because UPS needs to die. Of my last 3 orders with them:

1) was reported "left at door" of ... my apartment building? so I never saw it and I had to reorder at my cost

2) my ouya was again marked "left at door"... of my apartment building and I never saw it (seems very likely the driver just took it home). Thankfully this time amazon reissued at their cost

3) after one failed day time delivery the package was left at a nearby ups pickup place, we called to confirm it would be there on the weekend and then they called the depot and promptly sent it back to the sender...

UPS's policy of allowing abandonment of packages is not remotely safe because drivers can just steal and mark it "left at door". It doesn't look good thought when it's an apartment building and they probably didn't even get inside.

So yes, UPS needs to die because they have cost me and amazon time and money.

<comment><USER16> Everything I order from Amazon I have delivered to work, because I never know which carrier service is going to get it, and I don't like not knowing if they're going to just dump it on my doorstep, leave it with my apartment's leasing office, take it back to some depot on the edge of town, or what.

Though it does mean I think twice about ordering things on Thursday or Friday. I once had a package shipped via Prime go missing for half a week, because I ordered it on Friday and Amazon decided to pleasantly surprise me with one-day shipping instead of two. That backfired immensely. I would have been perfectly happy with a Monday delivery.

When no one was at the office to sign on Saturday morning, the package went back to some mysterious depot and they didn't re-attempt delivery until the middle of the next week. Except they marked the tracking as "delivered" that Saturday - probably so they wouldn't get in trouble with Amazon for not meeting the two-day shipping window. I was freaking out about where the package could have gone, because if it was supposedly delivered, then where was it? Where could they have even delivered it? No one was here! You can't even get in the building on Saturday without an access card. Then suddenly the tracking re-updated on Wednesday to say it was at the depot and I got it later that day.

I wish I could remember which carrier that was now.

</comment></comment><comment><USER17> When it comes to groceries and other very time sensitive shipments then yes they should deliver on their own, but making your own nationwide to door delivery system would be a disaster. These are not easy businesses and it would be hard to beat the cost effectiveness of USPS, UPS and FedEx. They could start in fresh deliveries to limited markets and have those warehouses store commonly ordered products.

Currently Amazon most often uses a courier for only the final ground leg from a distribution center. They already have their own delivery to deliver inter- warehouse. It would not be possible to stock the huge variety of products available on Amazon in very local warehouses. So I would not be incredibly worried if I were a package carrier now. This could perhaps take some of the business in some markets but I doubt Amazon will go private for the majority of its deliveries.

<comment><USER18> Had a similar debate with my girlfriend when she suggested Amazon would take over their entire delivery process. Warehouse to warehouse, and warehouse to major city don't really seem like they would be a problem. The middle-of- nowhere deliveries would cause the most headaches, and be the least cost- effective. I guess the question is how much of their total deliveries do those comprise of.

</comment></comment><comment><USER19> I expect them to receive a lot of resistance from federal and state governments. I have a friend that works for UPS, and the union-enforced inefficiency stories he tells me would blow your mind. It's literally the gangster behavior that unions are notorious for. And those guys are no strangers to getting politicians to bend to their will.

Given a truly fair, free-market, Amazon (and the other companies the article listed) would blow traditional delivery services out of the water over the next decade, no question. Companies like UPS are just too bogged down with union bureaucracy. But that's something the delivery unions will fight tooth and nail. This war will involve just as much lobbying as innovating.

<comment><USER20> >union-enforced inefficiency stories he tells me would blow your mind

Vacation, breaks and a mild improvement on minimum wage? Limits to what they're expected to lift? What are these horror stories?

UPS is an awful job with awful wages. Of course you could make them work harder for lower wages if you made sure they lacked representation, but I wouldn't refer to that as a fair, free market.

<comment><USER19> I'll have to ask him for specifics when I see him again because I wouldn't want to regurgitate inaccurate information, but it's not nearly as bad a job as you might think, and nobody's making near minimum wage. Everybody has hefty pension plans. The drivers tend to make more than the web developers working for startups in my area. Way more.

Nobody gets a promotion based on competence. It's pure seniority. The people that are there the longest get first dibs on better positions. And if somebody can't hold their own and doesn't contribute, you can forget about letting them go. It's almost impossible to fire someone who isn't worth the union wages they're making.

Now that's fine and dandy, I hope lots of folks get nice retirements after working at UPS their whole life. But Amazon is more efficient and will replace these high-wage manual laborers with robots and algorithms, and the union guys will try and use the power of government to stop them.

</comment></comment></comment><comment><USER21> As Amazon becomes larger and larger, it makes more sense to vertically integrate.

Assume half of AMZN's 2013 net shipping costs of $3,538 occurred in U.S. and profit generated thereon was ~10% of revenues (UPS 2013 operating margin was ~13%), AMZN has a guaranteed (and growing) chunk of change to go after. Not to mention the custom delivery options and probable long-term improved delivery metrics. Of course, this is a somewhat capital intensive business (relative to our estimates of the existing core businesses at least), but still could generate attractive long-term returns.

A much more interesting thought experiment is to do the same calculations on credit card exchange fee savings AMZN would generate if the company processed its payments itself. The savings would be into the billions of dollars and would be incomparably less capital intensive than any physical delivery system.

<comment><USER22> I'd guess that Amazon gets very very low fee rates for payments. Amazon's not going to start competing with Visa, and it seems unlikely they'd be a bank, so I doubt there's a huge amount of profit to be made in taking over their own payments processing.

<comment><USER21> Why wouldn't they compete with everyone that is a material cost to them? 10 basis points on their revenues is already approaching $100M/year. My guess is they pay quite a bit more than 10 basis points too (spent a while looking for reliable source to corroborate this but couldn't find one).

AMZN seems to want to do everything they can to expand and lower their costs; I don't know why credit card fees would be excluded from this.

They could develop a completely novel solution over time. My guess is they will become much more serious about payments over time because of articles like this[1] and this[2].

[1] [http://recode.net/2014/04/12/jeff-bezos-to-amazon- payments-t...](http://recode.net/2014/04/12/jeff-bezos-to-amazon-payments- team-go-faster/) [2][http://techcrunch.com/2014/01/29/amazon-wants-to-include- pee...](http://techcrunch.com/2014/01/29/amazon-wants-to-include-peer-to-peer- payments-in-its-real-world-paypal-competitor/)

</comment></comment></comment><comment><USER23> I've noticed this in the UK in the last couple of weeks...

Normally a "next-day" package would be delivered by a number of different UK courier/delivery firms (Royal Mail/DPD/Yodel/etc.).

Nearly everyday, we've had deliveries to our office from unmarked white vans. I know this because our office is hard to find, and they generally phone me to say they can't locate us. Whenever I've gone outside to meet the delivery driver, I've seen the van full of Amazon packages and asked if he does deliveries for anyone else. They've have told me they "only" deliver for Amazon and won't really be pushed on the matter.

I think pretty soon those vans are going to have Amazon branding on them and a few courier companies will be wondering where their business went...

<comment><USER24> > They've have told me they "only" deliver for Amazon and won't really be > pushed on the matter.

Amazon Logistics UK

They bought-out APLE in Milton Keynes, which had previously worked as a contract courier for Amazon and others.

[http://www.aplemk.com/ContactUs.php](http://www.aplemk.com/ContactUs.php)

Not a company that had a stellar reputation.

</comment></comment><comment><USER25> Amazon has messed up my last few next day orders, seriously breaking down my confidence with them. I made a purchasing decision based on price with next day vs price in store right now. I went with amazon and 1 out of 3 items got there the next day. The other two items listed with delivery by 8pm, which I waited late at the office until after 8pm and I got an email telling me they would be there 2 days later and that they were refunding me. I don't care about the refund on shipping, the items were business sensitive and needed ASAP, so amazon really lost my confidence that next day actually means next day (this was not the first time either). So I think amazon definitely needs their own shipping because these third party companies don't give a shit about amazon customer service. I know Lasership especially in NYC has straight up lied to me about delivering a package that they forgot and just went home.

</comment><comment><USER26> I'm betting that at some point in the near future, you're going to see housing developments built on top of a distribution center.

It makes sense. A big DC could use the same robots that pack shipments to deliver goods direct to your door. One-hour delivery.

If they did this, then you could also get into renting items instead of purchasing them. Do you really need that big screen TV? Or could you just rent something a couple Saturdays each month? I could easily see a future where you're out by the pool and decide to have a party. Speaking a few commands into your smart phone, when you get home a couple hours later you have all sorts of things purchased/rented/installed and ready to go.

10 years out, maybe?

</comment><comment><USER27> 1\. Start collecting state sales tax.

2\. Build warehouses in state close to customers.

3\. Use your own delivery trucks for shipments from those warehouses, since same-day local deliveries are the simplest part of the delivery chain.

4\. Profit!

<comment><USER28> > same-day local deliveries are the simplest part of the delivery chain.

Was this a joke...you think splitting thousands of tiny parcels up for delivery in a city is simpler than sending some semis for a cruise down the interstate?

<comment><USER27> My thinking was that a 1:n delivery system is easier to manage than an n:n one. But you are right that the last mile is not the simplest part.

</comment></comment></comment><comment><USER29> Amazon already (sort of) do this in the UK for some of their deliveries, with deliveries often coming from an arm of their business called "Amazon Logistics"

I don't think it's a pure courier company though, I think they've just paid a bunch of different couriers to deliver parcels under the Amazon brand. For example if you are out, they'll leave a card with Amazon branding over it

<comment><USER30> I've recently had a few of my Prime deliveries come via "Amazon Logistics" and it's lacking compared to DPD who used to do most of them.

Amazon Logistics has no depots (that I can see - they don't tell you who the courier is), no real time tracking, no delivery windows... If this is their attempt at doing it on their own it's a terrible start.

</comment></comment><comment><USER31> This was inevitable; I posted about this almost a year ago: [https://news.ycombinator.com/item?id=6245975](https://news.ycombinator.com/item?id=6245975)

They were already shipping some items in their grocery trucks around that time.

</comment><comment><USER32> 2 Weeks back on HN -> [https://news.ycombinator.com/item?id=7572809](https://news.ycombinator.com/item?id=7572809)

</comment><comment><USER33> It's a free country, if they can pull it off, more power to them!

</comment><comment><USER34> Pretty soon Amazon will have it's own wine brand, a pinot noir.</comment>


Ask HN: Do domains ever get pulled for not representing the country of the TLD? - <AUTHOR> For example, I'm in the UK and want to register a business, the name ends in ps, so I'd like to use a .ps domain as the .com is taken, and it'll only be used for email anyway. If you look at http://devo.ps/ that's an example of a non-palestine company using it for branding.
If you read the ToS for .ps domains it states that domains should be used by local businesses, and international companies wanting to have a presence in Palestine.
What's the likelihood of a domain being taken back? <comment><USER2> I think it depends on the ccTLD. I've never heard of that happening, but I'm sure it could.

</comment><comment><USER3> Interested to know myself.

<comment><AUTHOR> I think we may never know.</comment></comment>


Paris makes all public transport free after 'worst air pollution for 10 years' - <AUTHOR> http://www.independent.co.uk/news/world/europe/paris-public-transport-free-air-pollution-spike-a7460191.html <comment><USER2> I'm glad this is happening somewhere, banning cars from cities should be something that is considered else where

The problem is banning cars with no alternative is not productive, cities should be rebuilt so cars can approach the outskirts and have trams/buses/ideas I've not thought of yet, take people around the centre of said cities

The ban bit is easy, the positive alternatives are not

<comment><USER3> Yeah, that's in short Paris' problem. The last few mayor all wanted to remove all cars from Paris, but they all failed to provide alternatives and failed to meaningfully improve public transportation, especially since most of the network is overworked.

Also most of the cars clogging the roads are going from one suburb to the other and the way the road network is built makes that going through Paris is the best (sometime only) way to go from one side of Paris to the other.

Edit: Not all cars are banned, half of them, based on Vehicle registration plate (even or odd number).

> The ban bit is easy

The ban was made in response to the current pollution problem, but removing half of the cars has a pretty weak impact on air poltution.

</comment></comment><comment><USER4> AQI in Paris is currently around 130. Almost exactly 1 year ago I flew into Beijing, and the AQI was up toward 500. I wrote a blog post about it, and included one of China's, "IoT solution" for this air quality challenge...

[http://www.patdel.com/2015/12/03/yes-that-fog-really-is- poll...](http://www.patdel.com/2015/12/03/yes-that-fog-really-is-pollution- but-theres-an-app-for-that/)

</comment><comment><USER3> It's useless. People who are not using public transport the rest of the time won't start using them now. They don't use public transport since they can't (no train line, no close train station, has to transport tools/materials). And most train lines are pretty bad, especially since they had to cancel a lot of trains for renovation works a few months ago.

And the mayor is busy trying to create more trafic jams by closing a major West/East roadway along the Seine.

<comment><USER5> >People who are not using public transport the rest of the time won't start using them now.

They don't have much choice: half of the cars are forbidden in or near Paris (except if there are 3 people inside).

<comment><USER6> They can also not go to work. Choice is fast to do.

<comment><USER7> That is not an acceptable option to many people, and isn't an option at all for entire professions (like doctors, utility and emergency personnel...).</comment></comment></comment></comment>


Withings' ScanWatch packs ECG and SpO2 sensors alongside the usual tools - <AUTHOR> https://www.engadget.com/withings-scanwatch-hands-on-ifa-2020-070001875.html <comment><USER2> Interestingly, newer version Fitbit devices also sport an SpO2 sensor, but they have dragged their feet on enabling direct readings or the expected sleep apnea detection features.

The delay seems to have come from the worry of the perception that it was being used for "diagnosis" of sleep apnea as that would put them in a different category with the FDA. You can imagine how direct access to the SpO2 sensor was a hot topic during the height of the pandemic of a repository illness. In short, the hardware is there, but corporate conservarivism kept it from being used or even exposed to the user.

I've bought a Withings Smart Scale (at that point they were briefly owned by Nokia). The scale is simple, clean, durable, featureful; the companion health app is one of the cleanest/effective specimins of UI I've seen in a while and has tons of integrations. I expect great things here and hopefully less fear about exposing the hardware readings of highly useful sensors.

<comment><USER3> I'm skeptical that _anyone_ can make an SpO2 sensor that is good enough to continuouly monitor someone during sleep without lots of false alarms. Even the ones hospitals use (that wrap around a finger or toe and shine red light through it) are quite jittery and prone to false alarms or weird readings if you move around too much.

e.g. it seems the SpO2 sensor on this Withings watch is an 'on request and then sit still for 10 seconds' type feature. No good for continuous monitoring.

<comment><USER4> I have the Wellue SleepU, and it seems to work pretty well. Granted I'm not counting on it to save my life in a hospital situation, so any false readings really don't matter. But looking at the nightly data, it seems to gather pretty solid data.

[https://getwellue.com/pages/sleepu-oxygen- monitor](https://getwellue.com/pages/sleepu-oxygen-monitor)

</comment></comment></comment><comment><USER5> You'd think a review like this would bother to cover the actual device accuracy rather than focusing on "subtle beveling" and the lug size. Anyone seen any reviews that do that?

<comment><USER6> Here are some video reviews looking into the sensor data accuracy:

[https://www.youtube.com/playlist?list=PLrpJQJ3tlvklPADcz- WML...](https://www.youtube.com/playlist?list=PLrpJQJ3tlvklPADcz- WMLuzNU3zlDztx6) (channel: The Quantified Scientist, playlist: Withings Scanwatch)

Not great unfortunately.

</comment></comment><comment><USER7> Not that I had any hope, but

[https://www.withings.com/us/en/legal/privacy- policy](https://www.withings.com/us/en/legal/privacy-policy)

Is there any device like this out there that doesn't require selling your privacy? Any service, for which I'll gladly pay, that doesn't sell you to 3rd parties?

</comment><comment><USER8> Is it actually ECG? as in sensing electrical signals?

<comment><USER9> It's not as detailed as the sort you'd get in a hospital with 12 electrodes stuck all over, but yes it's really sensing electrical signals

</comment></comment><comment><USER10> Any ideas what the SpO2 data look like? I like seeing raw graphs of both O2 and HR to monitor for sleep apneas.

</comment><comment><USER11> The question for everyone else than apple is what will the likely imminent next gen apple apple watch have on it and what will it cost, etc. The market isn't quite owned by apple & Garmin...) but it feels closer every cycle.

<comment><USER12> I've owned an Apple Watch and I'm an Apple Fanboi, but it'll take something amazing to get me to switch away from my Fitbit Charge.

The long battery life is a killer feature for me, because I can wear it overnight, and get sleep data. I also simply don't want the rest of the crap on my wrist — I have a phone for apps and notifications that I can easily put in a draw when I want it.

All that said, I'm pretty data hungry so I'll update my Charge the day they add a new sensor to it</comment></comment>


Ask HN: How to ensure reasonable entropy in Linux? - josh-wrale So today I am trying to install FreeIPA in a VM on Proxmox VE.  Neither the hypervisor nor the guest seem to have sufficient entropy to complete the install, per the developers.  On advice from IRC, I found out how to check entropy using 'cat /proc/sys/kernel/random/entropy_avail'.
Results:

  - desktop: 1456

  - hypervisor: 262

  - guest: 94
 Suggestions I've seen so far are:
1. Implement VirtIO-RNG for my VM. This would share and throttle the hypervisor's /dev/random with the guest.  This does little good IMHO, if even the hypervisor is starved of entropy.  http://wiki.qemu-project.org/Features-Done/VirtIORNG
2. haveged - "A simple entropy daemon"; Any thoughts on this?  http://www.issihosts.com/haveged/
I would enjoy having a hardware RNG, but I wonder what software can do to solve this issue.
https://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators
I seem to remember the random numbers as a service post about the NIST recently.  Is that worth looking into for this? <comment><AUTHOR> haveged seems to work quite well and, before I started using it months ago, I ran some of its output through dieharder, ent, etc.

There's also rngd which can also use the RNG in a TPM, if one is available.

<comment> josh-wrale Thanks, that is helpful.

I found the story of how haveged came to be, which was a surprise: [https://www.centos.org/forums/viewtopic.php?f=25&t=31111](https://www.centos.org/forums/viewtopic.php?f=25&t=31111)

I also found this. The answer for most part speaks to havege instead of haveged. The last part of the answer speaks to haveged.

[https://crypto.stackexchange.com/questions/8083/quality- of-r...](https://crypto.stackexchange.com/questions/8083/quality-of- randomness-on-a-linux-system-with-haveged)

</comment></comment><comment> josh-wrale Wishing nerdy stuff like this would get more upvotes.. :)</comment>


Ask HN: what are some good companies to work for on the west coast? - <AUTHOR>

Looking to hear about innovative companies that take a keen interest in employee development abd have good employee development programs, well funded and stable. Basically what else is out there besides google amazon and Facebook? <comment><USER2> You do realize that the majority of tech companies in the U.S. are on the west coast? This may be a good place to start:

[http://www.crunchbase.com/search/advanced/companies/1987518](http://www.crunchbase.com/search/advanced/companies/1987518)

You seem to want more established companies, so showing ones with over 500 employees, within 500 miles of the Bay Area. I think you will find that there is a great deal of depth in terms of the number of successful tech companies out this way.</comment>


Multi-window on Android - <AUTHOR> http://www.youtube.com/watch?v=cuFusMeUS-8

<comment><USER2> Where can I find the source for this? Supposedly with an explanation on when (and by whom) to expect this?</comment>


DINO PET // a living, bioluminescent night light / pet - <AUTHOR> http://www.kickstarter.com/projects/yonder/dino-pet-a-living-bioluminescent-night-light-pet

<comment><AUTHOR> Always an enticing product idea: something bioluminescent that sits on your nightstand. Not as cool as bioluminescent goldfish (as in Big Bang Theory), but still could be impressive. If successful, is this a harbinger of more biological toys?</comment>