6 ms·

It's interesting how many people post about moving to Go from an interpreted or VM language background. The original presentation video pitched it as a C++ repl

by blt 14y ago

It's interesting how many people post about moving to Go from an interpreted or VM language background. The original presentation video pitched it as a C++ replacement, but that is clearly not the whole story. This author does not seem to have much experience in native development. I wonder if the Go designers predicted how many people they'd convert from python/ruby/java.

pjmlp 14y ago
Yeah, what many of these people state as Go features are actually common to many static compiled languages in the Pascal/Modula family. Old becomes new when you don't know it.
kbuck 14y ago
Frankly, I think a lot of the people currently working with C/C++ are avoiding Go because of the garbage collector. You can't trust a garbage collector; you don't know when it will run, how long it'll take, or how quickly it will free the memory you used. C/C++ programmers are used to having complete control over all of this. Sure, you could familiarize yourself with the internals of whichever GC you're working with, but at that point you might as well have invested the same amount of time writing the program in a language without a GC.
- wting 14y ago
  That's one of the reasons Rust appealed to me more than Go. Go has a global mark and sweep GC. OTOH Rust has a thread local, optional GC.
- dualogy 14y ago
  > You can't trust a garbage collector; you don't know when it will run, how long it'll take, or how quickly it will free the memory you used You can certainly control the GC somewhat. For example, disable unpredictable automatic GC and run GC yourself at a more opportune time, or never (if the program terminates before consuming all swap space of course). I have one app where I loop continously and invoke the GC every second. Why so often -- crazy, right? No because the "garbage" generated over that second --thanks to some memory-aware development practices-- is minimal, so the GC call will typically return in way under 1ms. Of course that's a meaningless number without app context and other numbers, but you do get some control. Basically Go gives you both philosophies. On one hand, you can auto-GC and never worry about mem or perf and simply "code out" your need, like you would in Java/C#/Python etc. Or, you can carefully design data structures and operations with allocations and GC (or supressed/non-existing GC) in mind. Sure, you don't get direct access to malloc()/free(), but implicitly (via Go's data structures, struct values vs pointers etc etc) you have a great deal more control over memory accesses, allocations etc.
- blt 14y ago
  Yeah, I've had to push code down from our C# layer to our C++ layer on more than one occasion because the GC wasn't freeing memory promptly enough. I guess I don't know the GC well enough to nudge it in the right direction - but now I don't trust it and I plan to keep all high performance stuff in the native layer. I'd like to hear from someone who figured out how to tame the GC in applications where lots of new data is created and destroyed quickly.
- jff 14y ago
  I'm going to make the argument that a lot, if not the majority, of C/C++ programmers don't need complete control over memory management. I think in many cases (not OS, not real-time), saying "but I need absolute control over memory management so I can optimize!" is the equivalent of "I write everything in hand-coded assembly because it's more efficient". It's probably not, the machine can probably handle it better, and you're missing out on useful functionality. You know what happens when I allocate and free memory myself? I generally end up with either a leak or a double-free, and I doubt I'm such a terrible programmer that I'm the only one like that.
  - p0nce 14y ago
    False dichotomy. If you use RAII, exceptions, and smart pointers in C++ there will be no leaks, no double-free, and not even a need for a GC. I know it is difficult to make a point on the Internet, but resource leaks really are a solved problem in C++.
    - jff 14y ago
      Yes, but then you're stuck using C++, RAII, and exceptions. Let's not even get into which smart pointer you should use--a Googler I know has recounted stories of massive internal mailing list arguments over exactly which of the half-dozen smart pointer implementations they should be using.
      - p0nce 14y ago
        So, because C++ has imaginary problems, we should all switch to a language that solve them, while being worse at all other things that matters (you know, like code generation)?
KMag 14y ago
Yes, I think coming from C++, Rust is a more compelling language than Go. However, the Rust type system is a bit more complicated than the Go type system. Go provides much better static guarantees and much better speed than Python/Ruby/JavaScript, without having to spend any time learning about the type system. However, Go's weaker type system doesn't appeal to a lot of people used to more powerful type systems.
- MatthewPhillips 14y ago
  > Go provides ... much better speed than Python/Ruby/JavaScript, Citation?
  - wting 14y ago
    No citation needed as long as you understand both languages' runtime stack. Python is an interpreted language that runs on top of a virtual machine (usually CPython). Types are determined at run time. .py -> .pyo* (bytecode) -> VM -> OS On the other hand, Go (and other C languages) have a different runtime stack: .go -> binary* -> OS Between source and binary are a bunch of compiler steps[0], but * is where both binaries are executed. Statically compiled languages do not have to determine types at runtime and therefore are able to optimize code paths much better. Still don't believe me? Here's a Fibonacci calculation micro benchmark[1] I ran: ╭─ting@noa /tmp/fib ‹python-2.7.3› ‹ruby-1.9.3› ╰─➤ time ./go 1346269 real 0.02s user 0.01s sys 0.00s ╭─ting@noa /tmp/fib ‹python-2.7.3› ‹ruby-1.9.3› ╰─➤ time python3 ./fib.py 1346269 real 0.61s user 0.60s sys 0.00s Sidenote: Java runs on a virtual machine (JVM) but it's performance comes very close to C languages due to static typing, JIT compilation, and heavy investment in the JVM from many companies. [0]: For C, compilation goes through these steps: hello.c (preprocessor) hello.tmp (compiler) hello.s (assembler) hello.o (linker) hello <-- binary to run [1]: https://gist.github.com/wting/77c9742fa1169179235f https://gist.github.com/wting/77c9742fa1169179235f
    - dilap 14y ago
      Dynamically-typed languages can be fast when run with a jit -- for example, Lua+luajit is close to Go in your microbenchmark. On my computer, for n=40, Go is 0m2.156s and luajit is 0m3.199s.

by blt 14y ago

pjmlp 14y ago

Yeah, what many of these people state as Go features are actually common to many static compiled languages in the Pascal/Modula family. Old becomes new when you don't know it.

kbuck 14y ago

Frankly, I think a lot of the people currently working with C/C++ are avoiding Go because of the garbage collector. You can't trust a garbage collector; you don't know when it will run, how long it'll take, or how quickly it will free the memory you used. C/C++ programmers are used to having complete control over all of this. Sure, you could familiarize yourself with the internals of whichever GC you're working with, but at that point you might as well have invested the same amount of time writing the program in a language without a GC.

wting 14y ago
That's one of the reasons Rust appealed to me more than Go. Go has a global mark and sweep GC. OTOH Rust has a thread local, optional GC.
dualogy 14y ago
> You can't trust a garbage collector; you don't know when it will run, how long it'll take, or how quickly it will free the memory you used You can certainly control the GC somewhat. For example, disable unpredictable automatic GC and run GC yourself at a more opportune time, or never (if the program terminates before consuming all swap space of course). I have one app where I loop continously and invoke the GC every second. Why so often -- crazy, right? No because the "garbage" generated over that second --thanks to some memory-aware development practices-- is minimal, so the GC call will typically return in way under 1ms. Of course that's a meaningless number without app context and other numbers, but you do get some control. Basically Go gives you both philosophies. On one hand, you can auto-GC and never worry about mem or perf and simply "code out" your need, like you would in Java/C#/Python etc. Or, you can carefully design data structures and operations with allocations and GC (or supressed/non-existing GC) in mind. Sure, you don't get direct access to malloc()/free(), but implicitly (via Go's data structures, struct values vs pointers etc etc) you have a great deal more control over memory accesses, allocations etc.
blt 14y ago
Yeah, I've had to push code down from our C# layer to our C++ layer on more than one occasion because the GC wasn't freeing memory promptly enough. I guess I don't know the GC well enough to nudge it in the right direction - but now I don't trust it and I plan to keep all high performance stuff in the native layer. I'd like to hear from someone who figured out how to tame the GC in applications where lots of new data is created and destroyed quickly.
jff 14y ago
I'm going to make the argument that a lot, if not the majority, of C/C++ programmers don't need complete control over memory management. I think in many cases (not OS, not real-time), saying "but I need absolute control over memory management so I can optimize!" is the equivalent of "I write everything in hand-coded assembly because it's more efficient". It's probably not, the machine can probably handle it better, and you're missing out on useful functionality. You know what happens when I allocate and free memory myself? I generally end up with either a leak or a double-free, and I doubt I'm such a terrible programmer that I'm the only one like that.
- p0nce 14y ago
  False dichotomy. If you use RAII, exceptions, and smart pointers in C++ there will be no leaks, no double-free, and not even a need for a GC. I know it is difficult to make a point on the Internet, but resource leaks really are a solved problem in C++.
  - jff 14y ago
    Yes, but then you're stuck using C++, RAII, and exceptions. Let's not even get into which smart pointer you should use--a Googler I know has recounted stories of massive internal mailing list arguments over exactly which of the half-dozen smart pointer implementations they should be using.
    - p0nce 14y ago
      So, because C++ has imaginary problems, we should all switch to a language that solve them, while being worse at all other things that matters (you know, like code generation)?

KMag 14y ago

Yes, I think coming from C++, Rust is a more compelling language than Go. However, the Rust type system is a bit more complicated than the Go type system. Go provides much better static guarantees and much better speed than Python/Ruby/JavaScript, without having to spend any time learning about the type system. However, Go's weaker type system doesn't appeal to a lot of people used to more powerful type systems.

MatthewPhillips 14y ago
> Go provides ... much better speed than Python/Ruby/JavaScript, Citation?
- wting 14y ago
  No citation needed as long as you understand both languages' runtime stack. Python is an interpreted language that runs on top of a virtual machine (usually CPython). Types are determined at run time. .py -> .pyo* (bytecode) -> VM -> OS On the other hand, Go (and other C languages) have a different runtime stack: .go -> binary* -> OS Between source and binary are a bunch of compiler steps[0], but * is where both binaries are executed. Statically compiled languages do not have to determine types at runtime and therefore are able to optimize code paths much better. Still don't believe me? Here's a Fibonacci calculation micro benchmark[1] I ran: ╭─ting@noa /tmp/fib ‹python-2.7.3› ‹ruby-1.9.3› ╰─➤ time ./go 1346269 real 0.02s user 0.01s sys 0.00s ╭─ting@noa /tmp/fib ‹python-2.7.3› ‹ruby-1.9.3› ╰─➤ time python3 ./fib.py 1346269 real 0.61s user 0.60s sys 0.00s Sidenote: Java runs on a virtual machine (JVM) but it's performance comes very close to C languages due to static typing, JIT compilation, and heavy investment in the JVM from many companies. [0]: For C, compilation goes through these steps: hello.c (preprocessor) hello.tmp (compiler) hello.s (assembler) hello.o (linker) hello <-- binary to run [1]: https://gist.github.com/wting/77c9742fa1169179235f https://gist.github.com/wting/77c9742fa1169179235f
  - dilap 14y ago
    Dynamically-typed languages can be fast when run with a jit -- for example, Lua+luajit is close to Go in your microbenchmark. On my computer, for n=40, Go is 0m2.156s and luajit is 0m3.199s.