4 ms·

YouTube is using Golang http://code.google.com/p/vitess/ http://code.google.com/p/vitess/. So 10% of Internet traffic now depends on it. I wouldn't call it not

YouTube is using Golang http://code.google.com/p/vitess/ http://code.google.com/p/vitess/. So 10% of Internet traffic now depends on it. I wouldn't call it not production ready. From the project goal page: "Go is miles ahead of C++ and Java in terms of expressibility and close in terms of performance. It is also relatively simple and has a straightforward interaction with Linux system calls. The main drawback is also its strength - the garbage collector. vtocc has made spot optimizations to minimize most of the adverse effects of Go’s stop-the-world gc. At this point, we are trading some amount of performance for greater creativity and efficiency at lower layers. unless you’re trying to max out on qps for your servers, you should see acceptable performance from vtocc. Also, go’s garbage collector is being improved. So, this should only get better over time. Go’s existing mark-and-sweep garbage collector is sub-optimal for systems that use large amounts of static memory (like caches). In the case of vtocc, this would be the row cache. To alleviate this, we intend to use memcache for the time being. If the gc ends up addressing this, it should be fairly trivial to switch to an in-memory row cache. Note that the row cache functionality is not fully ready yet."

pjmlp 15y ago
"Go is miles ahead of C++ and Java in terms of expressibility and close in terms of performance. It is also relatively simple and has a straightforward interaction with Linux system calls." How can this be when Go lacks: - enumerations - exceptions - generics - dynamic loading The short compilation times are possible in any language with modules. Channels are available as part of concurrency libraries in Java, .NET, C++ and Erlang. Goroutines are also possible in other languages, in form of continuations or task pools.
- agentS 15y ago
  - It has a more general analogue to enumerations, one that does not add a lot of verbiage to the language spec. (http://play.golang.org/p/HSh4Ke3pCJ http://play.golang.org/p/HSh4Ke3pCJ) - It has an "exception" mechanism that is rarely used, in favour of error-valued returns. (http://blog.golang.org/2010/08/defer-panic-and-recover.html http://blog.golang.org/2010/08/defer-panic-and-recover.html) - Apparently, vitess didn't need generics. You'll notice a bit of casting here in their implementation of an LRU cache, but writing containers isn't exactly the main purpose of the library. I do admit I want generics, for the sole purpose of stopping people parroting that criticism without actually using the language. (http://code.google.com/p/vitess/source/browse/go/cache/lru_cache.go http://code.google.com/p/vitess/source/browse/go/cache/lru_c...) - Not sure what you mean here. If you mean a Go library is being loaded, then there's an issue for that, but one unlikely to be fixed in the short-term because of Go's unusual calling convention. If you mean Go loading a library at runtime, I don't know why you'd want this. Either way, static linking seems cleaner and more self contained to me. "Short compilation times" being available in any language is total bull. Try building chromium or firefox in a reasonable amount of time, without a build cluster. Don't you think if there was a way to speed that up, the developers would make that priority 1? Channel/Goroutines are of course available in all languages, Turing-completeness implies that they must. However, in practice, does all code in those languages make use of the same concurrency primitives? Do they read as nicely as Go does?
  - zvrba 15y ago
    > Try building chromium or firefox in a reasonable amount of time He wrote "in any language with modules". C++ doesn't have them.
    - pjmlp 15y ago
      Thanks. I am not sure what it is up with these kids today, that only seem to know C and C++ as languages for native development. There are many others out there that always had modules and fast compilation times.
      - agentS 15y ago
        Apologies. I misread your post because you were comparing Go to Java and C++, and I erroneously assumed the entire post was talking about those languages.
- sirclueless 15y ago
  None of those things are really roadblocks to Getting Shit Done though, except maybe dynamic loading. Go has plenty of support for global constant values that take the place of enumerations, even to the point of having an "iota" syntax to make initializing constants easier. Exceptions are generally an anti-pattern in my opinion: a hack to get around the ability to return multiple values from a function, so that error conditions can be handled in-band. The other technical challenge exceptions sometimes provide -- guaranteed cleanup after code that might fail to execute -- can be handled by Go's deferred function execution. Generics are a powerful abstraction, but Go has very good support for (un)boxed values and interfaces, so the only thing you would get from generics is a bit more type safety. The additional complexity required to support generics isn't worth it. Dynamic loading is arguably a blocker for certain modes of development and distribution, but by not supporting dynamic loading, Go can make tremendous simplifications in its module system. Making the assumption that every go library is distributed in source form greatly reduces compatibility friction and runtime bugs. "DLL Hell" may be a "solved" problem on most systems nowadays, but there are a lot of moving parts to enable that. The simplifications that Go makes are 100% worth it in my opinion. There is one place where Go sacrifices something that can't be replaced is that a stop-the-world garbage collector may be unacceptable for some applications. Other than that, codebases aren't actually served by having too much power in their languages, even if an individual programmer might be.
  - pjmlp 15y ago
    ioata is a poor man's solution to enumerations. Why should I do the work for the compiler? Even C has enumerations, a language developed in 1972! This is how modern Go is. The lack of generics makes everyone that writes generic data structure code like it was the 90's again. Copy-pasting code or writing template processors to generate code. Talk about evolution. Dynamic loading is an important way to write modular applications that can be composed on run-time. Something like Eclipse would be impossible to write in Go, due to performance constrains of interprocess communication. If Go did not had Google behind it, I doubt it would be noticed, it would fail as just another language. Look how successful Limbo and Alef were. And Go is nothing more than a reinvention of them.
    - 15y ago
- deleted 15y ago
  [deleted]

pjmlp 15y ago

"Go is miles ahead of C++ and Java in terms of expressibility and close in terms of performance. It is also relatively simple and has a straightforward interaction with Linux system calls." How can this be when Go lacks: - enumerations - exceptions - generics - dynamic loading The short compilation times are possible in any language with modules. Channels are available as part of concurrency libraries in Java, .NET, C++ and Erlang. Goroutines are also possible in other languages, in form of continuations or task pools.

agentS 15y ago
- It has a more general analogue to enumerations, one that does not add a lot of verbiage to the language spec. (http://play.golang.org/p/HSh4Ke3pCJ http://play.golang.org/p/HSh4Ke3pCJ) - It has an "exception" mechanism that is rarely used, in favour of error-valued returns. (http://blog.golang.org/2010/08/defer-panic-and-recover.html http://blog.golang.org/2010/08/defer-panic-and-recover.html) - Apparently, vitess didn't need generics. You'll notice a bit of casting here in their implementation of an LRU cache, but writing containers isn't exactly the main purpose of the library. I do admit I want generics, for the sole purpose of stopping people parroting that criticism without actually using the language. (http://code.google.com/p/vitess/source/browse/go/cache/lru_cache.go http://code.google.com/p/vitess/source/browse/go/cache/lru_c...) - Not sure what you mean here. If you mean a Go library is being loaded, then there's an issue for that, but one unlikely to be fixed in the short-term because of Go's unusual calling convention. If you mean Go loading a library at runtime, I don't know why you'd want this. Either way, static linking seems cleaner and more self contained to me. "Short compilation times" being available in any language is total bull. Try building chromium or firefox in a reasonable amount of time, without a build cluster. Don't you think if there was a way to speed that up, the developers would make that priority 1? Channel/Goroutines are of course available in all languages, Turing-completeness implies that they must. However, in practice, does all code in those languages make use of the same concurrency primitives? Do they read as nicely as Go does?
- zvrba 15y ago
  > Try building chromium or firefox in a reasonable amount of time He wrote "in any language with modules". C++ doesn't have them.
  - pjmlp 15y ago
    Thanks. I am not sure what it is up with these kids today, that only seem to know C and C++ as languages for native development. There are many others out there that always had modules and fast compilation times.
    - agentS 15y ago
      Apologies. I misread your post because you were comparing Go to Java and C++, and I erroneously assumed the entire post was talking about those languages.
sirclueless 15y ago
None of those things are really roadblocks to Getting Shit Done though, except maybe dynamic loading. Go has plenty of support for global constant values that take the place of enumerations, even to the point of having an "iota" syntax to make initializing constants easier. Exceptions are generally an anti-pattern in my opinion: a hack to get around the ability to return multiple values from a function, so that error conditions can be handled in-band. The other technical challenge exceptions sometimes provide -- guaranteed cleanup after code that might fail to execute -- can be handled by Go's deferred function execution. Generics are a powerful abstraction, but Go has very good support for (un)boxed values and interfaces, so the only thing you would get from generics is a bit more type safety. The additional complexity required to support generics isn't worth it. Dynamic loading is arguably a blocker for certain modes of development and distribution, but by not supporting dynamic loading, Go can make tremendous simplifications in its module system. Making the assumption that every go library is distributed in source form greatly reduces compatibility friction and runtime bugs. "DLL Hell" may be a "solved" problem on most systems nowadays, but there are a lot of moving parts to enable that. The simplifications that Go makes are 100% worth it in my opinion. There is one place where Go sacrifices something that can't be replaced is that a stop-the-world garbage collector may be unacceptable for some applications. Other than that, codebases aren't actually served by having too much power in their languages, even if an individual programmer might be.
- pjmlp 15y ago
  ioata is a poor man's solution to enumerations. Why should I do the work for the compiler? Even C has enumerations, a language developed in 1972! This is how modern Go is. The lack of generics makes everyone that writes generic data structure code like it was the 90's again. Copy-pasting code or writing template processors to generate code. Talk about evolution. Dynamic loading is an important way to write modular applications that can be composed on run-time. Something like Eclipse would be impossible to write in Go, due to performance constrains of interprocess communication. If Go did not had Google behind it, I doubt it would be noticed, it would fail as just another language. Look how successful Limbo and Alef were. And Go is nothing more than a reinvention of them.
  - 15y ago
deleted 15y ago
[deleted]