Official Go support

Post by skybrian » Wed, Sep 24, 2014, 8:32 PM UTC

pjmlp wrote: post #82

skybrian wrote: post #55

Earlier quoted context omitted.

Yes, there are many more features to come, but they don't look like they will be as important as lambdas (and default methods) for everyday coding. Thanks for the links.

I think you underestimate you important some of those are. Specially for people doing big data analysis in JVM languages or jumping out of Java to languages like C and C++ for the last performance increase.

Post by skybrian » Wed, Sep 24, 2014, 11:54 PM UTC

pjmlp wrote: post #112

skybrian wrote: post #111

Earlier quoted context omitted.

The Java community is so large that these are important communities in themselves. But they're still subsets. Someone writing a portable Java library isn't going to want to call into native code or rely on specific hardware. Changing the language itself affects everyone.

If you bothered to follow the links, they imply language changes.

Post by general_failure » Thu, Sep 25, 2014, 5:14 PM UTC

NateDad wrote: post #91

general_failure wrote: post #74

Earlier quoted context omitted.

The graph has no numbers.

Developers & managers at Stripe decided that Go was being used often enough to spend precious dev time writing an official library which will have to be supported from here on. They wouldn't do that if the numbers didn't justify it.

Post by methodology » Fri, Oct 03, 2014, 1:28 AM UTC

enneff wrote: post #57

methodology wrote: post #39

Earlier quoted context omitted.

Go's syntax and semantics seem ad-hoc, hard to remember, and inconsistent, but that's because Go was designed from uses cases and experience by prominent thought leaders such as Rob Pike and Ken Thompson, and Google. For example, sometimes you'll get Unicode code points, but sometimes you'll get bytes of UTF-8. The language was designed to give you the right one in the right case. UTF-8 is coupled with the language b…

> If any thread runs in an infinite loop that doesn't call built in functions, the entire runtime will freeze. That's not entirely true. Go 1.3 introduced pre-emptive scheduling, so now only the most trivial (useless) of infinite loops will hog the scheduler. But if you're doing real CPU-bound work you won't block other goroutines from executing.

    package main
    import "fmt"
    func main() {
      go func() {
        for ;; {}
      }()
      for ;; {
        fmt.Println("still here")
      } 
    }

    package main
    import "fmt"
    func f(v int) int {
      return v+1
    }
    func g(x int) int {
      if (x > 100) {
        return 1
      }
      return 0
    }
    func main() {
      go func() {
        for ;; {
          if g(f(111)) == 0 {
            break
          }
        }
      }()
      for ;; {
        fmt.Println("still here")
      } 
    }