aaronbee

The trade off is discussed here: https://github.com/golang/go/issues/70835

Your code is an example of a "pull iterator", and it's not as much of a concern.

The harder case to deal with is a "push iterator", which are often much simpler to implement, but less flexible to use. See https://github.com/golang/go/discussions/56413

The OP is about converting a push iterator into a pull iterator efficiently by using coroutines. This provides the best of both worlds, simple iterator implementation and flexible use by its caller.

There are some folks working on porting SwissTable to Go: https://github.com/golang/go/issues/54766

What’s holding it back currently is coming up with a way to do incremental rehash, which Go’s current map provides.

Here’s a description of the new map implementation and why it’s more efficient: https://www.pypy.org/posts/2015/01/faster-more-memory-effici...

Russ Cox has a few good explainer blog posts: https://research.swtch.com/mm

I believe they made a mistake with that example. It doesn't look unsafe to me because the myResults sliced passed to the goroutine is not used. Or perhaps the racy part was left out of their snippet.

Below is what might be what they have meant. This code snippet is racy because an unsafe read of myResults is done to pass it to the goroutine and then that version of myResults is passed to safeAppend:

  func ProcessAll(uuids []string) {
    var myResults []string
    var mutex sync.Mutex
    safeAppend := func(results []string, res string) {
      mutex.Lock()
      myResults = append(myResults, res)
      mutex.Unlock()
    }

    for _, uuid := range uuids {
      go func(id string, results []string) {
        res := Foo(id)
        safeAppend(myResults, id)
      }(uuid, myResults) # <<< unsafe read of myResults
    } 
  }

EDIT: Formatting and clarity

go1.18 is coming out soon with generics. The first release candidate came out 2 weeks ago. You can track the open issues here: https://github.com/golang/go/milestone/201

I believe the GP's point is that even with a 10,000x increase in data center energy consumption, the effect on ocean temperature is tiny.

Even more exciting, this is already present in go1.13. I believe the author of these slides made a mistake.

Here it is mentioned in go1.13 release notes: https://golang.org/doc/go1.13#compiler

And GitHub says the commit is present in go1.13: https://github.com/golang/go/commit/996a687ebbf81b26f81b41b8...

TCL is pronounced "tickle." https://en.wikipedia.org/wiki/Tcl

Amazon's pricing is yearly.

This suggests that Google/Facebook/Twitter will still be able to track you, assuming you use their websites regularly, but advertising companies that don't have pages frequented by the average internet user won't.

Cool Earth [1] is a highly rated [2] charity fighting climate change.

[1] https://www.coolearth.org/ [2] https://www.givingwhatwecan.org/charity/cool-earth/

When it comes to accessing shared data it's often much simpler and more efficient to use a lock to protect that data.

Channels are good in other scenarios.

The Chrome team has been working on power efficiency improvements [1], some of them have gone into the already released Chrome 44.

[1] https://plus.google.com/+PeterKasting/posts/GpL63A1K2TF

Google cache: http://webcache.googleusercontent.com/search?q=cache:srB_qjf...

Facebook's Wedge 1U switch is what this builds on. https://code.facebook.com/posts/681382905244727/introducing-...

This article from 2013 makes the argument that lead in the environment is responsible for violent crime. http://www.motherjones.com/environment/2013/01/lead-crime-li...

The problem with soft-links is that if the underlying file/directory is deleted, you are screwed. For example if you have 100 full-machine backups and want to free some space so you decide to delete every other one, you have to be careful that none of the backups you are keeping, have soft-links to files in the backups you are deleting.

With hard-links the underlying data is not deleted until all hard-links are deleted, so you can delete any individual backup directory without losing data in any other backup directory.

A soft-link is like a pointer in C whereas a hard-link is like a C++ shared_ptr, ie. reference counted.

Another relevant benchmark is x32 vs. x86. In a memory constrained environment you may be forced to use x86. x32 gives you the ability to get the performance benefits of x86-64 (possibly plus some) while staying in your memory constraints.

This sounds like a great idea and should make the game a lot more rewarding. For one, it will make crafting useful instead of a waste of money.

Scala has the Try [0] and Either [1] types that can be used to achieve this. However, I believe Scala also allows any type to be NULL. In Rust there is no NULL so you don't have to worry if a value is ever NULL unless it is explicitly wrapped in an option instance.

[0] http://www.scala-lang.org/api/current/index.html#scala.util.... [1] http://www.scala-lang.org/api/current/index.html#scala.util....

The point is to avoid writing to disk entirely by compressing RAM that may otherwise be swapped to disk when remaining RAM is low.

See http://thread.gmane.org/gmane.linux.kernel.mm/91969

Every packet goes through special switching hardware or ASIC. This ASIC has a pipeline for processing packets like a CPU has a pipeline for processing instructions. The ASIC also contains very fast tables optimized for storing and looking up MAC and IP addresses.

One part of the pipeline checks if the destination MAC matches the switch's MAC. If it does then the packet is routed and the ASIC will read the destination IP address from the packet. The dest IP is looked up in the routing table to figure out which port the next hop lives on and what it's MAC address is. If the destination MAC is for another host, then the MAC table is checked to see what port to send the mac.

Modern ASICs are designed to handle both cases very quickly.

If Apple plans on enabling the second core with a software update then they would have tested both cores during manufacturing.