8 ms·

Go for C++ Programmers

54 points by cyber1 12y ago

Animats 12y ago
From the article: Go is "safe" by default. Pointers cannot point to arbitrary memory, and buffer overruns result in crashes, not security exploits. That's only true for single-thread Go. Go is not memory-safe in multithread mode, because exploits using race conditions are known.[1] This, incidentally, is why Go is locked down to one thread when running under Google's AppEngine. Go is a good language for server-side web work - all the expected libraries are there and in good shape. That makes sense; that's why Google had Go created. Go is a good option when Python and Javascript/node.js are too slow. But Go's concurrency isn't as clean as its enthusiasts claim. I'd recommend Go for programmers coming from the Javascript/Python/Perl world. Although Go is a hard-compiled language, it's surprisingly similar to the scripting languages when writing routine server-side code. C++ programmers will find Go easy, mainly because it's garbage collected. (The replacement for C++ will, if we're lucky, be Rust. Rust has roughly the complexity level, headaches, and gotchas of C++, but it catches all the memory-related bugs at compile time. Rust isn't ready for production use yet, though. Give it a year.) [1] http://research.swtch.com/gorace http://research.swtch.com/gorace
- mempko 12y ago
  I have already replaced C++. C++14 has already replaced C++98 for me.
  - pjc50 12y ago
    Can you ban "native"/bare pointers in C++14? And C-style casts?
    - plorkyeran 12y ago
      -Werror=old-style-cast will make C casts an error in gcc and clang.
      - nly 12y ago
        and -Wconversion and -Wsign-conversion coupled with the new C++11 {braced} initialisers deal with a lot of bad implicit conversions inherited from C
      - detrino 12y ago
        Unfortunately this can be problematic if you include any library headers that use old-style-casts.
        plorkyeran 12y ago
        Using -isystem rather than -I makes gcc/clang not emit warnings for headers found in those paths, which does extend to -Werror.
        detrino 12y ago
        Thanks for the tip.
      - cannam 12y ago
        The one time I still use C casts in C++ is when comparing an int against the size of a container: if (i < (int)container.size()) This is because container.size() returns an unsigned type, and I try to avoid unsigneds in everyday code, and I like to use -Wall -Werror which, amongst other things, produces errors for signed/unsigned comparison warnings. I don't want to have to make the variable "i" unsigned, because using unsigneds for anything other than bit arithmetic is quite hazardous in practice (http://soundsoftware.ac.uk/c-pitfall-unsigned http://soundsoftware.ac.uk/c-pitfall-unsigned). How do others resolve this problem?
        mappu 12y ago
        You've traded one hazard for another there, now you have a bug at runtime if the container size is between the range of signed int and unsigned int. Hope that container size isn't user controlled. I'm guilty of a few C-style casts, but certainly prefer catching things at compile time than runtime. So +1 unsigned types for me. At least the compiler helps with catching signedness issues.
- cyber1 12y ago
  Very interesting article http://research.swtch.com/gorace http://research.swtch.com/gorace, but it's very old, published in 2010. First Golang stable release r56 in 2011/03/16 https://golang.org/doc/devel/release.html https://golang.org/doc/devel/release.html.
- tptacek 12y ago
  This article comes up every so often on HN, and it's great, but the people citing it tend to muddy its argument, as you've done here. The "exploit" rsc is referring to here is hypothetical. To wit: if there existed some service (like multithreaded GAE, or an especially weird browser) that allowed content-controlled Golang code to run, that code could exploit mutability to violate assumptions made by other code, in much the same way as you could by dropping down to "unsafe" in Golang and Rust. For that vulnerability to matter, you have to suppose a system that rigorously constrains the runtime to block system calls, containerize I/O, shut off the "unsafe" APIs, and somehow fence off state for crypto. Nothing does that. Real-world systems that allow users to upload arbitrary Golang code give up on protecting the runtime, and use OS-level protections to maintain integrity. I agree that Golang isn't a great fit for C++ programmers. If you're still writing C++ in 2015, it's because you're productive using all the bells and whistles C++ provides. Golang is very much a one bell, no whistle language.
  - heinrich5991 12y ago
    It just means that Go isn't memory-safe by default.
  - Animats 12y ago
    For that vulnerability to matter, you have to suppose a system that rigorously constrains the runtime to block system calls, containerize I/O, shut off the "unsafe" APIs, and somehow fence off state for crypto. Nothing does that. Google AppEngine does exactly that.
amelius 12y ago
So, when writing a high-performance, scalable web-server, which language should I pick: Go, C++, Rust, Scala, other?
- rjammala 12y ago
  Go is the easiest.
  - Zikes 12y ago
    I'm a Go fan, but ease is a very subjective measure.
- jonnybgood 12y ago
  Clojure should also be a consideration.
- anom9999 12y ago
  Whichever you're most competent in. Any of those languages (and many others) would be a suitable option, so it boils down to what you are most proficient in.
  - lomnakkus 12y ago
    I would amend that. Start with whichever you're fastest (not necessarily most competent) in. Once you discover whether the whole thing is worth the effort, move towards safe languages. That's basically Rust, Scala, or (functional-language-of-your-choice-or-) Haskell. EDIT: Personally, I would start in something like Haskell or Scala just to do a proof-of-concept without having to worry too much about undefined behavior (C/C++) or absurd verbosity (Java), but then I am pretty familiar with those two languages. Maybe it would be worth learning one or two very terse languages to start with, just in case you hit upon a great idea? (Btw, I think Python or Perl qualifies.) EDIT#2: As a sort of second or third order bit of advice, I'd encourage anyone to brush up on programming languages that might make you faster. It's a sort of "propellant" and can increase your speed exponentially.
- npalli 12y ago
GFK_of_xmaspast 12y ago
As a C++ programmer, if I wanted that kind of stuff why wouldn't I switch to java.
- vowelless 12y ago
  Go is less verbose than Java arguably. Multi-threadedness in Go is very straightforward. Native code binaries can be beneficial in some cases.
  - lomnakkus 12y ago
    That would be amazing if Java didn't have AOT compilers. (See my other comment.)
  - justinsb 12y ago
    For me, the killer feature of Go is that it produces executables that are quick to start up and run with a small memory footprint. It is great for utilities or agents or small daemons; where startup time or memory size are critical. It can also run without a JRE or other dependencies, which is nice if you are distributing software to end-users. So I'm not sure I agree on your first two points. For me, lack of exceptions and generics means Go code is at least as verbose as Java, if not more so. Multi-threadedness is a wash for me; channels vs fork-join and executors are just not that different. I think Java can produce native code today, but it isn't worth it for most scenarios where you would actually use Java. I think we'll see that change if Oracle ships an AOT compiler in "official Java".
    - pjmlp 12y ago
      AOT compilers are available in many licensed JVMs, but one is planned for official Java around Java 10 time-frame. http://cr.openjdk.java.net/~jrose/pres/201502-JVMChallenges.pdf http://cr.openjdk.java.net/~jrose/pres/201502-JVMChallenges.... Slide 12.
    - vowelless 12y ago
      Coming from a C++ heavy background, I do miss generics. But I have been trying to be cautious of bringing my C++ habits to Go, opting instead to embrace the alternate model Go brings to the table. spf13 goes over some of these points in his talk here: http://vimeo.com/115776445 http://vimeo.com/115776445 I do not use exceptions in C++ so that was not a big change for me. Our code needs to be relatively deterministic (even though we are not hard real-time yet) and exceptions hamper with that goal. I incorrectly used the word "multi-threadedness". Concurrency in go is very straightforward. Channels are extremely lightweight and are different from forking (which creates a new process with its own address-space).
vinkelhake 12y ago
Go for C++ programmers, or.. trying to keep a straight face when explaining that no, just implementing "Less" to sort an array of some type isn't enough. You'll also need to tell Go how to get the length of an array and how to swap two elements. Now, don't get me wrong. I actually like Go for the things I use it for: replacing Python.
- 0xdeadbeefbabe 12y ago
  Well go has a nice grammar. Seems like you won't have to write much boilerplate if when you can automate writing the code. What bugs me most is this popularity contest. For example, the idea that go will go mainstream and writers of the future will write about people that did keep a straight face when explaining what you said. You know how people unwittingly revise history. This field has too much fashion going on and not enough engineering.
- tptacek 12y ago
  Python outcompetes C++ in the market by a significant multiple. Python is used in diverse applications, many of them quite ambitious --- game backends, computer algebra, cryptography, network filesystems, simulation code, machine learning. So is it just that the subset of applications that still get written, for some reason, in 2015 C++ are heavily dependent on specialized Sort implementations? Or is it instead the case that really Sort just isn't that big a deal? It's pretty easy to look around briefly and see that a fair amount of ambitious stuff is being built in Golang. Somehow, they manage to do it without sum types and generics!
  - pjmlp 12y ago
    It's pretty easy to look around briefly and see that a fair amount of ambitious stuff is being built in Assembly. Somehow, they manage to do it without structured programming and high level languages!
    - tptacek 12y ago
      No, it's not easy to look around and see that, because that isn't happening.
0xdeadbeefbabe 12y ago
And it also doesn't encourage long compile times, so you might be tempted to do less thinking and more compiling.
blt 12y ago
> Go provides automatic garbage collection of allocated memory. It is not necessary (or possible) to release memory explicitly. There is no need to worry about heap-allocated vs. stack-allocated storage, new vs. malloc, or delete vs. delete[] vs. free. There is no need to separately manage std::unique_ptr, std::shared_ptr, std::weak_ptr, std::auto_ptr, and ordinary, "dumb" pointers. Go's run-time system handles all of that error-prone code on the programmer's behalf. This is not an attractive statement to C++ programmers like the author probably imagines it is. We like being in control of our memory. C++ programmers who would prefer to not manage memory have probably already switched to Java or C#.
- deleted 12y ago
  [deleted]
- enneff 12y ago
  Ian Lance Taylor wrote the article; he's one of the best C++ programmers I know. So I imagine he is speaking to _some_ subset of C++ programmers, just maybe not the one you belong to.

54 points by cyber1 12y ago

From the article: Go is "safe" by default. Pointers cannot point to arbitrary memory, and buffer overruns result in crashes, not security exploits. That's only true for single-thread Go. Go is not memory-safe in multithread mode, because exploits using race conditions are known.[1] This, incidentally, is why Go is locked down to one thread when running under Google's AppEngine. Go is a good language for server-side web work - all the expected libraries are there and in good shape. That makes sense; that's why Google had Go created. Go is a good option when Python and Javascript/node.js are too slow. But Go's concurrency isn't as clean as its enthusiasts claim. I'd recommend Go for programmers coming from the Javascript/Python/Perl world. Although Go is a hard-compiled language, it's surprisingly similar to the scripting languages when writing routine server-side code. C++ programmers will find Go easy, mainly because it's garbage collected. (The replacement for C++ will, if we're lucky, be Rust. Rust has roughly the complexity level, headaches, and gotchas of C++, but it catches all the memory-related bugs at compile time. Rust isn't ready for production use yet, though. Give it a year.) [1] http://research.swtch.com/gorace http://research.swtch.com/gorace

mempko 12y ago
I have already replaced C++. C++14 has already replaced C++98 for me.
- pjc50 12y ago
  Can you ban "native"/bare pointers in C++14? And C-style casts?
  - plorkyeran 12y ago
    -Werror=old-style-cast will make C casts an error in gcc and clang.
    - nly 12y ago
      and -Wconversion and -Wsign-conversion coupled with the new C++11 {braced} initialisers deal with a lot of bad implicit conversions inherited from C
    - detrino 12y ago
      Unfortunately this can be problematic if you include any library headers that use old-style-casts.
      - plorkyeran 12y ago
        Using -isystem rather than -I makes gcc/clang not emit warnings for headers found in those paths, which does extend to -Werror.
        detrino 12y ago
        Thanks for the tip.
    - cannam 12y ago
      The one time I still use C casts in C++ is when comparing an int against the size of a container: if (i < (int)container.size()) This is because container.size() returns an unsigned type, and I try to avoid unsigneds in everyday code, and I like to use -Wall -Werror which, amongst other things, produces errors for signed/unsigned comparison warnings. I don't want to have to make the variable "i" unsigned, because using unsigneds for anything other than bit arithmetic is quite hazardous in practice (http://soundsoftware.ac.uk/c-pitfall-unsigned http://soundsoftware.ac.uk/c-pitfall-unsigned). How do others resolve this problem?
      - mappu 12y ago
        You've traded one hazard for another there, now you have a bug at runtime if the container size is between the range of signed int and unsigned int. Hope that container size isn't user controlled. I'm guilty of a few C-style casts, but certainly prefer catching things at compile time than runtime. So +1 unsigned types for me. At least the compiler helps with catching signedness issues.
cyber1 12y ago
Very interesting article http://research.swtch.com/gorace http://research.swtch.com/gorace, but it's very old, published in 2010. First Golang stable release r56 in 2011/03/16 https://golang.org/doc/devel/release.html https://golang.org/doc/devel/release.html.
tptacek 12y ago
This article comes up every so often on HN, and it's great, but the people citing it tend to muddy its argument, as you've done here. The "exploit" rsc is referring to here is hypothetical. To wit: if there existed some service (like multithreaded GAE, or an especially weird browser) that allowed content-controlled Golang code to run, that code could exploit mutability to violate assumptions made by other code, in much the same way as you could by dropping down to "unsafe" in Golang and Rust. For that vulnerability to matter, you have to suppose a system that rigorously constrains the runtime to block system calls, containerize I/O, shut off the "unsafe" APIs, and somehow fence off state for crypto. Nothing does that. Real-world systems that allow users to upload arbitrary Golang code give up on protecting the runtime, and use OS-level protections to maintain integrity. I agree that Golang isn't a great fit for C++ programmers. If you're still writing C++ in 2015, it's because you're productive using all the bells and whistles C++ provides. Golang is very much a one bell, no whistle language.
- heinrich5991 12y ago
  It just means that Go isn't memory-safe by default.
- Animats 12y ago
  For that vulnerability to matter, you have to suppose a system that rigorously constrains the runtime to block system calls, containerize I/O, shut off the "unsafe" APIs, and somehow fence off state for crypto. Nothing does that. Google AppEngine does exactly that.

amelius 12y ago

So, when writing a high-performance, scalable web-server, which language should I pick: Go, C++, Rust, Scala, other?

rjammala 12y ago
Go is the easiest.
- Zikes 12y ago
  I'm a Go fan, but ease is a very subjective measure.
jonnybgood 12y ago
Clojure should also be a consideration.
anom9999 12y ago
Whichever you're most competent in. Any of those languages (and many others) would be a suitable option, so it boils down to what you are most proficient in.
- lomnakkus 12y ago
  I would amend that. Start with whichever you're fastest (not necessarily most competent) in. Once you discover whether the whole thing is worth the effort, move towards safe languages. That's basically Rust, Scala, or (functional-language-of-your-choice-or-) Haskell. EDIT: Personally, I would start in something like Haskell or Scala just to do a proof-of-concept without having to worry too much about undefined behavior (C/C++) or absurd verbosity (Java), but then I am pretty familiar with those two languages. Maybe it would be worth learning one or two very terse languages to start with, just in case you hit upon a great idea? (Btw, I think Python or Perl qualifies.) EDIT#2: As a sort of second or third order bit of advice, I'd encourage anyone to brush up on programming languages that might make you faster. It's a sort of "propellant" and can increase your speed exponentially.
npalli 12y ago

GFK_of_xmaspast 12y ago

As a C++ programmer, if I wanted that kind of stuff why wouldn't I switch to java.

vowelless 12y ago
Go is less verbose than Java arguably. Multi-threadedness in Go is very straightforward. Native code binaries can be beneficial in some cases.
- lomnakkus 12y ago
  That would be amazing if Java didn't have AOT compilers. (See my other comment.)
- justinsb 12y ago
  For me, the killer feature of Go is that it produces executables that are quick to start up and run with a small memory footprint. It is great for utilities or agents or small daemons; where startup time or memory size are critical. It can also run without a JRE or other dependencies, which is nice if you are distributing software to end-users. So I'm not sure I agree on your first two points. For me, lack of exceptions and generics means Go code is at least as verbose as Java, if not more so. Multi-threadedness is a wash for me; channels vs fork-join and executors are just not that different. I think Java can produce native code today, but it isn't worth it for most scenarios where you would actually use Java. I think we'll see that change if Oracle ships an AOT compiler in "official Java".
  - pjmlp 12y ago
    AOT compilers are available in many licensed JVMs, but one is planned for official Java around Java 10 time-frame. http://cr.openjdk.java.net/~jrose/pres/201502-JVMChallenges.pdf http://cr.openjdk.java.net/~jrose/pres/201502-JVMChallenges.... Slide 12.
  - vowelless 12y ago
    Coming from a C++ heavy background, I do miss generics. But I have been trying to be cautious of bringing my C++ habits to Go, opting instead to embrace the alternate model Go brings to the table. spf13 goes over some of these points in his talk here: http://vimeo.com/115776445 http://vimeo.com/115776445 I do not use exceptions in C++ so that was not a big change for me. Our code needs to be relatively deterministic (even though we are not hard real-time yet) and exceptions hamper with that goal. I incorrectly used the word "multi-threadedness". Concurrency in go is very straightforward. Channels are extremely lightweight and are different from forking (which creates a new process with its own address-space).

vinkelhake 12y ago

Go for C++ programmers, or.. trying to keep a straight face when explaining that no, just implementing "Less" to sort an array of some type isn't enough. You'll also need to tell Go how to get the length of an array and how to swap two elements. Now, don't get me wrong. I actually like Go for the things I use it for: replacing Python.

0xdeadbeefbabe 12y ago
Well go has a nice grammar. Seems like you won't have to write much boilerplate if when you can automate writing the code. What bugs me most is this popularity contest. For example, the idea that go will go mainstream and writers of the future will write about people that did keep a straight face when explaining what you said. You know how people unwittingly revise history. This field has too much fashion going on and not enough engineering.
tptacek 12y ago
Python outcompetes C++ in the market by a significant multiple. Python is used in diverse applications, many of them quite ambitious --- game backends, computer algebra, cryptography, network filesystems, simulation code, machine learning. So is it just that the subset of applications that still get written, for some reason, in 2015 C++ are heavily dependent on specialized Sort implementations? Or is it instead the case that really Sort just isn't that big a deal? It's pretty easy to look around briefly and see that a fair amount of ambitious stuff is being built in Golang. Somehow, they manage to do it without sum types and generics!
- pjmlp 12y ago
  It's pretty easy to look around briefly and see that a fair amount of ambitious stuff is being built in Assembly. Somehow, they manage to do it without structured programming and high level languages!
  - tptacek 12y ago
    No, it's not easy to look around and see that, because that isn't happening.

0xdeadbeefbabe 12y ago

And it also doesn't encourage long compile times, so you might be tempted to do less thinking and more compiling.

blt 12y ago

> Go provides automatic garbage collection of allocated memory. It is not necessary (or possible) to release memory explicitly. There is no need to worry about heap-allocated vs. stack-allocated storage, new vs. malloc, or delete vs. delete[] vs. free. There is no need to separately manage std::unique_ptr, std::shared_ptr, std::weak_ptr, std::auto_ptr, and ordinary, "dumb" pointers. Go's run-time system handles all of that error-prone code on the programmer's behalf. This is not an attractive statement to C++ programmers like the author probably imagines it is. We like being in control of our memory. C++ programmers who would prefer to not manage memory have probably already switched to Java or C#.

deleted 12y ago
[deleted]
enneff 12y ago
Ian Lance Taylor wrote the article; he's one of the best C++ programmers I know. So I imagine he is speaking to _some_ subset of C++ programmers, just maybe not the one you belong to.