staticint

A mutex held for up to 10ms on each iteration, over 500 iterations, averaging out to 2s doesn't seem surprising at all. In fact, this is quite expected. It would take considerably longer if the random sleep hit 10ms every time.

If you modify the code to release the lock before sleeping...

    func (c *Counter) add(ch chan int) {
            c.Lock()
            tmp := c.Num
            c.Unlock()
            tmp += 1
            time.Sleep(time.Duration(rand.Intn(10)) * time.Millisecond)
            c.Lock()
            c.Num = tmp
            c.Unlock()
            ch <- 1
    }

...and reacquiring it after, it still finishes in 10ms on my machine, as you'd expect. As you can see, the problem isn't so much that locks are inherently slow in Go, but rather the mutex, as the acqusition function name implies, is doing what it is supposed to do: Lock. What is true is that you have to be careful to use them properly.

I imagine not that much in practice. It is not like someone is going to manually write out identical functions twenty times for each type they want to support. That's precisely what computers are good at doing and there are countless tools to do it painlessly.

The bigger problem is that Go doesn't have type inheritance or similar. Meaning, there's no great way to say that this generic function will only work with number types, for example. You leave the burden on the programmer to ensure their generalized function is applied only to types which it is intended to be used with.

While that is less than ideal, I cannot see that increasing developer time by a significant margin.

About as hard as it is to understand that correlation does not imply causation, but these people were still expecting career success out of their education anyway. The downside of making education available to everyone is that you get everyone.

That seems to play into the parent's point though:

   * Not-so-exceptional people are not granted admission
   * Exceptional people are demonstrably exceptional even before admission

There is no path for unexceptional people to find exceptional success by simply going to the right school, like certain interest groups want you to believe. The flaw is thinking that academia and business are supposed to be intertwined at all, of course. They are completely separate institutions for a reason.

Or to be confused with http://website-archive.mozilla.org/www.mozilla.org/firefox_r... (web browser)

An interesting choice for a name of a software project, given its history.

Perhaps the issue is actually with your provider? In practice, HSPA+ (3G) usually allows for 20Mbps in my experience, which fits right inside your 10-40Mbps LTE window. Going from 20Mbps to even 40Mbps really isn't going to be noticeable in many circumstances. In theory, HSPA+ actually allows for download speeds greater than LTE allows, although less so on the upload side.

I agree with you entirely. I read recently that the population growth of downtown Toronto has tripled in the past five years. Assuming that is a trend consistent with most major North American cities, the cost of housing has to compensate.

> I believe that CCD has basically been conclusively traced to a certain class of pesticides.

However, the initial data on bee deaths following the use of dust-off mitigation strategies, like using Fluency Agent, looks promising. Granted, it is still early days to be forming any formal concluions, but the data that is available shows a significant change. Even if we can point to neonicotinoids as the cause, where do we go from here if changing our handling strategies resolves the problem?