1. 19
    aje avatar aje 4 years ago | link | on: What are you working on this week?

    Building a photo booth for my wedding next month! Raspberry Pi, DSLR camera, python and Flask.

    1. 4
      shazow avatar shazow 4 years ago | link

      Are you going to be publishing the source anywhere? It occurs to me that I have both a Raspberry Pi and a DSLR I’m not using, would be fun to setup a semi-permanent photo booth at my house. :D

      Also, congratulations in advance!

      1. 2
        johnbender avatar johnbender 4 years ago | link

        Yes, good luck with the project and your photo booth too! :)

        1. 1
          jasono avatar jasono 4 years ago | link

          That sounds fun! Good luck with all the less nerdy details and I hope you enjoy the big day :)

          1. 1
            psuter avatar psuter 4 years ago | link

            Good luck with the project! We had a (rented) photo booth at our wedding, and it was a huge it. Many months later, we still enjoy going over the pictures.

          1. 4
            polyfractal avatar polyfractal edited 4 years ago | link | on: Java is the COBOL of my generation and Go is its successor (and other reflections after GopherCon)

            Honestly, the only thing that worries me about Go is the garbage collector. Not that it has a GC, but that its GC is so young. Java’s GC was garbage (heh) when it was first introduced. But it has the advantage of 10+ years of intense optimization. CMS is a great GC nowadays, and G1 looks very promising.

            I’m positive that Go will eventually arrive at a great GC too…but I’m worried it is going to take the same 10+ year trajectory to get there. I think we will start to see more people complaining about Go GC issues once companies/products really start to push the language with high-performance apps.

            1. 10
              kragen avatar kragen 4 years ago | link

              Java, Python, ML, Smalltalk and Lisps have an object-graph memory model; while this has big advantages, it also makes their overall performance really sensitive to the garbage collector’s performance. Go’s memory model is from C, and it’s an object-embedding memory model, but without the object-slicing problem that C++ has from combining object embedding with subclass extension. This means the garbage collector is dramatically less important to Go’s performance.

              1. 2
                polyfractal avatar polyfractal 4 years ago | link

                Interesting, I didn’t know this. Do you have any other resources/reading to look at? I’d love to dig into the technical details about how these two different memory models work.

                1. 2
                  kragen avatar kragen 4 years ago | link

                  I don’t know of any good essays about this, although I’ve started a draft of one to post to kragen-tol. I don’t even know if someone has already invented terminology for it. Even “memory model” is a bad term, because it already means at least two other conflicting things (one from multiprocessor concurrency, and one from the MS-DOS days of segment:offset).

                  There’s a third common “memory model” other than object-graph and object-embedding, although I mostly don’t recommend it: parallel arrays, as traditionally used in Fortran but also found in APL, J, and K. Beyond that, there are a multitude of other possible ways of organizing memory, but most of them are less useful in some way.

                  Describing the Java or Python heap as an object graph is established terminology, but part of what I’m working from here is Allen Short’s insight in describing Python as an “object-graph language” the other day on IRC.

              2. 5
                codahale avatar codahale 4 years ago | link

                This was my big initial worry with Go, but I have reasons for optimism.

                In just two years, Go has gone from having a conservative GC in 1.0 to having a fully precise GC in 1.3, with major improvements to parallelism along the way. The unsafe package means a generational/compacting/concurrent GC may be a ways off, but unlike many open-source languages, the Go team is fully capable of shipping a first-class GC.

                It’s also easier to write GC-friendly applications in Go, in large part due to the control over memory layout and allocation. (The fact that you can trivially write a benchmark and measure memory allocation for your code doesn’t hurt, either.)

                Finally, most of the big-heap problems which cause grief for GC’d languages are best solved by managing use-specific memory pools off-heap. If you’re willing to pay the cgo tax and copy data, you can pretty easily leverage the existing ecosystem of highly-tuned in-memory data structures to store data off-heap while keeping your Go-managed heap nice and light.

                1. 1
                  johnbender avatar johnbender edited 4 years ago | link

                  I’m curious is if this is actually an issue for two reasons:

                  1. The knowledge / research that defines how the Java garbage collector works is widely available (afaik), which means the Go maintainers can make use of it where appropriate.
                  2. It might be that Go’s programming model is “easier” to build a GC for (I have no idea).
                  1. 1
                    polyfractal avatar polyfractal 4 years ago | link

                    I agree to an extent. The knowledge about Java’s GC has been well documented and transcribed. Future systems will have an easier time building robust GCs, but there is still a lot of work to be done.

                    For example, Go is only just now getting a precise GC, which is a mandatory pre-req for a higher performance generational collector. If Go wants to be a serious server language, it should really offer a pauseless collector too…which means it will also have to develop a concurrent, compacting, generational, precise GC like Azul.