7 ms·

It's not clear how much experience the author really acquired with each language, and whether that experience was sufficient experience to justify his statement

by freyr 12y ago

It's not clear how much experience the author really acquired with each language, and whether that experience was sufficient experience to justify his statement: Go felt that way to me — it was good at everything, but nothing grabbed me and made me feel excited in a way I wasn’t already about something else in my ecosystem. He's apparently using each language to write relatively small command-line utilities. If Go is "amazing" at anything, its usually cited as a language of choice for (1) networked systems, and (2) large yet maintainable systems. I'm not sure his initial foray into the language would have provided enough experience to accurately assess those merits one way or the other. Rob Pike once expressed surprise that people migrating to Go weren't C++ programmers, but Ruby/Python/etc. programmers who needed more performance. That leads you to wonder: (EDIT: removed pejoratives) if a programmer desired to switch from C/C++ to another language but hasn't by now, why not? 1. They require the performance benefits of C/C++ (and as humanrebar pointed out, manual memory management). 2. They're tied to legacy code, with too little incentive to switch. 3. They have an organizational mandate. Any programmer who wasn't subject to the above constraints and wanted to switch could have done so before Go showed up on the scene. And if a programmer uses C or C++ solely because the above constraints, Go isn't likely to change that. Rust may have a better chance of converting C++ programmers, if it offers the performance and control demanded by programmers who are using C++ by necessity. It will be interesting to see if people migrating from Python/Ruby to a higher performance language will choose Go or Rust in the future. Kind of like the OP, I like Go but I'm excited about Rust.

agwa 12y ago
> Rob Pike once expressed surprise that people migrating to Go weren't C++ programmers, but Ruby/Python/etc. programmers who needed more performance. That leads you to wonder: who is still using C/C++ in 2014, and why? Here are some ideas: I (and many others) "still" use C++ (which is a very different language from C) in 2014 because it's an extremely powerful language that's still evolving and has produced many innovations that haven't been replicated by many other languages, such as destructors/RAII, strong compile-time type checking, generic programming, and ownership/move semantics. To me, Go looks like an update of C that has ignored all the good innovations of C++. It has no destructors, uses GC instead of ownership/move semantics, and requires runtime type checking instead of providing generics. I see it as a big step backward from C++, so unlike Rob Pike I'm not surprised it hasn't attracted C++ programmers. Rust, on the other hand, has taken many of the good parts from C++ and developed them even further, without the baggage of C++. Thus, while I haven't coded any Rust yet, it looks like a step forward from C++ and has me quite excited.
- freyr 12y ago
  I apologize, "still" came off as pejorative. My post became a little muddled there, but had my thoughts been clearer, I would have focused on just one group: programmers who currently use C++ even though they would prefer to switch to another language. My interest pertains to them -- what requirements have prevented them from switching, and does Go satisfy those requirements? >> [C++ is] still evolving and has produced many innovations You're absolutely right, those features extend beyond performance/control. >> Go looks like an update of C that has ignored all the good innovations of C++. Yes, Go feels much more like an updated C to me too. And it makes it all the more surprising they expected C++ programmers to jump on board. I double-checked the quote, and actually C wasn't mentioned at all.
  - nostrademons 12y ago
    For me - it's because Go exists in the same uncanny valley as Java. It is a language that manages to get a good number of trade-offs right, balances performance & productivity, and provides a good all-around package. However, it's not the best at anything. If you need super performance and the ability to control the machine directly, you still need C++. If you want super productivity and the ability to quickly try out ideas and see if they work, you still need Python or Ruby. If you want to write for web browsers, you still need Javascript. If you want to write for iPhones, you still need Objective C. If you want to write for Android, you still need Java. If you want to be absolutely certain your program will work as intended when it compiles, you still need Haskell. I guess Go is the best mainstream language available in one area, networking concurrency. And that's where we see its successes so far - Cloudflare and Doozer (Heroku's Paxos implementation) and dl.google.com. But virtually all the money in the tech industry is made on the margins - by being the best in the world at one specific task. If you want to build the fastest, most memory-efficient database possible - you still need C++. If you want to crawl, parse, and index the most pages on the web - you still need C++. If you want to have the highest-quality graphics at the best frame rate possible - you still need C++. I could see Go getting pretty widespread adoption within the enterprise (as in, software departments of companies whose primary product is not software), much like Java has. There, you don't need to be the best in the world at something, you only need to make the best use of the computing resources you can with the staff you have available, and a language that gives you a good trade-off works out well. But these people moved away from C++ a decade ago; the enterprise is all Java land now. The people who still are on C++ generally work for product companies where performance is critical; because of the economics of the software industry, it pays for these companies to hire a few more expensive developers and ensure that their product remains better than the competition than to switch to a more productive language and take the risk that their technology stack won't let them achieve the goals that make them competitive.
shin_lao 12y ago
To met it's pretty clear that the language C++ programmers were waiting for is called C++ 14.
- humanrebar 12y ago
  As a C++ programmer, I'm waiting for C++ZZ where ZZ is the version that has a sane module system. Something like Cargo isn't even on the radar for C++ developers for a lot of reasons, but many of them can be traced back to textual inclusion.
  - girvo 12y ago
    This is going to sound weird, and possibly ignorant, but PHP uses textual inclusion and we still have Composer/Packagist and PSR-4? I'm guessing the difference lies in 'spl_autoload_register'?
  - ziotom78 12y ago
    I absolutely agree! And I hope that a module system will help C++ in improving its compilation times too: templates slow gcc a lot. Just an example. In the previous months I had to re-write a medium-sized project (~5000 lines of C++), and I chose to use Free Pascal instead of C++. The old C++ code took ~1 min to compile, while Free Pascal only requires ~1 sec! It is so fast that my makefile uses the "rebuild all" switch every times it calls "fpc". In this way, at each recompilation all the hints/warnings are printed again and again, and there is no risk that I miss any of them. Another thing that C++14 lacks is a decent set of features in the standard library. How can it be possible that the STL includes esoteric features (see "partition", "is_permutation"...), but not a printf-like formatting facility à la "boost::format"? I cannot stand the usage of ios::setw et similia!
- bjz_ 12y ago
  Isn't it C++17? Modules and concepts?
humanrebar 12y ago
who is still using C/C++ in 2014, and why? Systems programmers. Embedded programmers. Kernel developers. Compiler developers. Language runtime developers. Safety critical software developers. I guess you can group them under "performance benefits" but it's as much about the ability to drop down, write arbitrary bits to arbitrary addresses, and (re)implement low-level constructs as it is about performance. The most obvious example of the need for a powerful language is manual memory management. For C and C++ developers, manual memory management isn't a drawback of their language but a feature. If you want that sort of freedom to rebuild from the ground up, the only mainstream choices are C and C++. We'll see if Rust gets it right too. All that being said, I think there's more room in the systems programming space. Both C and C++ tend to pick fast (or reverse-compatible) over correct when deciding which way to go on a feature. There are many, many applications that could really benefit from a "safety first" attitude towards systems programming. Browsers are the driving example but encryption libraries, medical systems, safety-critical software, and many other domains would benefit from a new perspective on things.
- Cyther606 12y ago
  Nim performance compares favorably to C++. It features a Pythonic syntax, optional soft real-time GC, optional manual memory management. Porting an elliptic curve implementation over to Nim from Python was a cinch: elliptic.nim: https://github.com/def-/bigints/blob/master/examples/elliptic.nim https://github.com/def-/bigints/blob/master/examples/ellipti... elliptic.py: https://github.com/wobine/blackboard101/blob/master/EllipticCurvesPart4-PrivateKeyToPublicKey.py https://github.com/wobine/blackboard101/blob/master/Elliptic... Others have reported success converting Python codebases directly to Nim. To put it in perspective [1]: > The problem asked students to do a hundred runs and to try sample sizes of 10 and 100. For kicks, I did 1000 runs with a sample size of 1000. This took nearly 4 minutes in Python (macbook pro retina with i7 or i5? I forget...) and under 5 secs in Nim. [1]: http://forum.nimrod-lang.org/t/589 http://forum.nimrod-lang.org/t/589 Rust and Go vs Nim: http://goran.krampe.se/2014/10/20/i-missed-nim/ http://goran.krampe.se/2014/10/20/i-missed-nim/
  - dbaupp 12y ago
    The Rust vs Nim comparison is tainted by very out of date documentation hosted on some MIT servers (the condition system is entirely gone). It's unfortunate and we have contacted the web master but there's not much they can do to remove or change how it appears in search engine rankings. For reference, doc.rust-lang.org is the only place to look for documentation for the standard libraries; any other hosting of those docs is likely to be out-of-date.
pjc50 12y ago
Never underestimate the legacy. I've resolved not to start another C++ project, but I'm learning MFC at the moment for working on a codebase that's 35 years old and was rewritten into C++ at some point in the 90s.
- blt 12y ago
  I'm sorry you have to do that.
  - pjc50 12y ago
    I'm finding it not too bad; the style is somewhere between 'C with classes' and EnterpriseJavaReallyLongNames, and aggressive testing has kept it working over the years. MFC itself is pretty intuitive and I like the window message system.
threeseed 12y ago
>(2) large yet maintainable systems I have never seen anyone suggest Go for large systems or seen any open source code that even comes close to enterprise system size. I would argue that Go is inadequate for large systems compared to the JVM languages. The absence of operational tooling, exceptions, declarative annotations, runtime management etc all make it much harder to support and scale to large numbers of developers. Go seems perfect for micro services, command line utilities and single purpose applications. Which is where it seems to have gained a lot of traction in companies to date.
- _bpo 12y ago
  A big problem in large-scale systems is dependency management. One of the significant decisions that Go makes in its design is its approach to package management. Its approach isn't perfect, but is simple, making it a breath of fresh air compared to C++ or JVM-based languages... e.g. how many hours have been spent tweaking Maven or debugging discrepancies between classpaths referencing different copies of commons-logging? Speaking of Maven - `go build` normalizes build systems so there is less time twiddling builds. It's not a silver bullet, but it's specifically intended for large systems. Go's strong decisions around formatting (`go fmt`) are another example of planning for enterprise-size. There is no need for a style guide for go programs - it's built into the language, and with an approach that feels less pedantic than Python. Go isn't perfect, but it's certainly designed for large-scale systems. I agree with you that the JVM languages have better large-scale system support currently (20 years does give you something) -- but Go's goal is not dissimilar to the one Java eventually settled on after the applet craze. Contrary to what you've seen, Go seems (to me) to be a go-to language for new companies principally concerned with distributed systems / cloud infrastructure (particularly those that once might have hired a hybrid of C and scripting language devs). One of the trends in those communities is toward microservices / SOA / etc, but the total codebases managed are certainly enterprise-scale. All that said I have absolutely no significant opinions on Go vs Rust :) Just had to take issue with the "go is not enterprise scale" idea.
  - desdiv 12y ago
    Go's strong decisions around formatting (`go fmt`) are another example of planning for enterprise-size. There is no need for a style guide for go programs - it's built into the language, and with an approach that feels less pedantic than Python. How is that different from the 40 years old Unix utility indent? Pretty much every single non-trivial programming language has its own code formatter. Auto code formatting is neither novel nor unique to Go.
shurcooL 12y ago
It seems relatively clear that he's quite new to both languages, with maybe a few weeks worth of familiarity if not less. From his rookie mistake of using path package instead of path/filepath to join system file paths [1], to non idiomatic naming with underscores, and what he describes in general. It's interesting from the perspective of what a fresh perspective on both languages is, but the comments have less value once you've spent significant time with either language and used them to build large projects. [1] https://gist.github.com/adamhjk/5a475b8dd45971a4e814#comment-1333555 https://gist.github.com/adamhjk/5a475b8dd45971a4e814#comment...
- holoway 12y ago
  I am absolutely quite (completely) new to both languages.
panic 12y ago
That leads you to wonder: if a programmer desired to switch from C/C++ to another language but hasn't by now, why not? Another reason to use C for your project is the ubiquity of C compilers and C bindings to other languages. Software like Lua and SQLite wouldn't be as widely-used if they were written in another language.
nhaehnle 12y ago
Another aspect that makes me hopeful about Rust as a way forward for C++ programmers is that it is designed to play well with the C (if not C++) ecosystem. Go is in this weird place where they insist that you have to be 100% Go or not at all, at least with the official Go package (gccgo is different, but this divergence in the ecosystem doesn't exactly inspire confidence). This is convenient when you have small isolated processes, but completely prevents Go adoption in other environments. I'm working in an electronic design automation software system which is basically a large number of C/C++ shared libraries/plugins loaded into a Tcl interpreter which you do not want to rewrite (lots of tricky and finely tuned optimization and design analysis algorithm). Go is not a good fit in this environment because of its all-or-nothing attitude. Rust, on the other hand, is fairly easy to imagine as an addition to the toolset from a purely technological point of view (ignoring the social and management issues which add a huge amount of inertia). There is an unfortunate impedance mismatch between idiomatic C++ and idiomatic Rust, but communication is possible via a thin C interface.
- NateDad 12y ago
  Uh... Go plays very well with C and C++. https://dennisforbes.ca/index.php/2013/07/23/the-most-powerful-feature-of-go-is-the-least-sexy/ https://dennisforbes.ca/index.php/2013/07/23/the-most-powerf...

by freyr 12y ago

agwa 12y ago

> Rob Pike once expressed surprise that people migrating to Go weren't C++ programmers, but Ruby/Python/etc. programmers who needed more performance. That leads you to wonder: who is still using C/C++ in 2014, and why? Here are some ideas: I (and many others) "still" use C++ (which is a very different language from C) in 2014 because it's an extremely powerful language that's still evolving and has produced many innovations that haven't been replicated by many other languages, such as destructors/RAII, strong compile-time type checking, generic programming, and ownership/move semantics. To me, Go looks like an update of C that has ignored all the good innovations of C++. It has no destructors, uses GC instead of ownership/move semantics, and requires runtime type checking instead of providing generics. I see it as a big step backward from C++, so unlike Rob Pike I'm not surprised it hasn't attracted C++ programmers. Rust, on the other hand, has taken many of the good parts from C++ and developed them even further, without the baggage of C++. Thus, while I haven't coded any Rust yet, it looks like a step forward from C++ and has me quite excited.

freyr 12y ago
I apologize, "still" came off as pejorative. My post became a little muddled there, but had my thoughts been clearer, I would have focused on just one group: programmers who currently use C++ even though they would prefer to switch to another language. My interest pertains to them -- what requirements have prevented them from switching, and does Go satisfy those requirements? >> [C++ is] still evolving and has produced many innovations You're absolutely right, those features extend beyond performance/control. >> Go looks like an update of C that has ignored all the good innovations of C++. Yes, Go feels much more like an updated C to me too. And it makes it all the more surprising they expected C++ programmers to jump on board. I double-checked the quote, and actually C wasn't mentioned at all.
- nostrademons 12y ago
  For me - it's because Go exists in the same uncanny valley as Java. It is a language that manages to get a good number of trade-offs right, balances performance & productivity, and provides a good all-around package. However, it's not the best at anything. If you need super performance and the ability to control the machine directly, you still need C++. If you want super productivity and the ability to quickly try out ideas and see if they work, you still need Python or Ruby. If you want to write for web browsers, you still need Javascript. If you want to write for iPhones, you still need Objective C. If you want to write for Android, you still need Java. If you want to be absolutely certain your program will work as intended when it compiles, you still need Haskell. I guess Go is the best mainstream language available in one area, networking concurrency. And that's where we see its successes so far - Cloudflare and Doozer (Heroku's Paxos implementation) and dl.google.com. But virtually all the money in the tech industry is made on the margins - by being the best in the world at one specific task. If you want to build the fastest, most memory-efficient database possible - you still need C++. If you want to crawl, parse, and index the most pages on the web - you still need C++. If you want to have the highest-quality graphics at the best frame rate possible - you still need C++. I could see Go getting pretty widespread adoption within the enterprise (as in, software departments of companies whose primary product is not software), much like Java has. There, you don't need to be the best in the world at something, you only need to make the best use of the computing resources you can with the staff you have available, and a language that gives you a good trade-off works out well. But these people moved away from C++ a decade ago; the enterprise is all Java land now. The people who still are on C++ generally work for product companies where performance is critical; because of the economics of the software industry, it pays for these companies to hire a few more expensive developers and ensure that their product remains better than the competition than to switch to a more productive language and take the risk that their technology stack won't let them achieve the goals that make them competitive.

shin_lao 12y ago

To met it's pretty clear that the language C++ programmers were waiting for is called C++ 14.

humanrebar 12y ago
As a C++ programmer, I'm waiting for C++ZZ where ZZ is the version that has a sane module system. Something like Cargo isn't even on the radar for C++ developers for a lot of reasons, but many of them can be traced back to textual inclusion.
- girvo 12y ago
  This is going to sound weird, and possibly ignorant, but PHP uses textual inclusion and we still have Composer/Packagist and PSR-4? I'm guessing the difference lies in 'spl_autoload_register'?
- ziotom78 12y ago
  I absolutely agree! And I hope that a module system will help C++ in improving its compilation times too: templates slow gcc a lot. Just an example. In the previous months I had to re-write a medium-sized project (~5000 lines of C++), and I chose to use Free Pascal instead of C++. The old C++ code took ~1 min to compile, while Free Pascal only requires ~1 sec! It is so fast that my makefile uses the "rebuild all" switch every times it calls "fpc". In this way, at each recompilation all the hints/warnings are printed again and again, and there is no risk that I miss any of them. Another thing that C++14 lacks is a decent set of features in the standard library. How can it be possible that the STL includes esoteric features (see "partition", "is_permutation"...), but not a printf-like formatting facility à la "boost::format"? I cannot stand the usage of ios::setw et similia!
bjz_ 12y ago
Isn't it C++17? Modules and concepts?

humanrebar 12y ago

who is still using C/C++ in 2014, and why? Systems programmers. Embedded programmers. Kernel developers. Compiler developers. Language runtime developers. Safety critical software developers. I guess you can group them under "performance benefits" but it's as much about the ability to drop down, write arbitrary bits to arbitrary addresses, and (re)implement low-level constructs as it is about performance. The most obvious example of the need for a powerful language is manual memory management. For C and C++ developers, manual memory management isn't a drawback of their language but a feature. If you want that sort of freedom to rebuild from the ground up, the only mainstream choices are C and C++. We'll see if Rust gets it right too. All that being said, I think there's more room in the systems programming space. Both C and C++ tend to pick fast (or reverse-compatible) over correct when deciding which way to go on a feature. There are many, many applications that could really benefit from a "safety first" attitude towards systems programming. Browsers are the driving example but encryption libraries, medical systems, safety-critical software, and many other domains would benefit from a new perspective on things.

Cyther606 12y ago
Nim performance compares favorably to C++. It features a Pythonic syntax, optional soft real-time GC, optional manual memory management. Porting an elliptic curve implementation over to Nim from Python was a cinch: elliptic.nim: https://github.com/def-/bigints/blob/master/examples/elliptic.nim https://github.com/def-/bigints/blob/master/examples/ellipti... elliptic.py: https://github.com/wobine/blackboard101/blob/master/EllipticCurvesPart4-PrivateKeyToPublicKey.py https://github.com/wobine/blackboard101/blob/master/Elliptic... Others have reported success converting Python codebases directly to Nim. To put it in perspective [1]: > The problem asked students to do a hundred runs and to try sample sizes of 10 and 100. For kicks, I did 1000 runs with a sample size of 1000. This took nearly 4 minutes in Python (macbook pro retina with i7 or i5? I forget...) and under 5 secs in Nim. [1]: http://forum.nimrod-lang.org/t/589 http://forum.nimrod-lang.org/t/589 Rust and Go vs Nim: http://goran.krampe.se/2014/10/20/i-missed-nim/ http://goran.krampe.se/2014/10/20/i-missed-nim/
- dbaupp 12y ago
  The Rust vs Nim comparison is tainted by very out of date documentation hosted on some MIT servers (the condition system is entirely gone). It's unfortunate and we have contacted the web master but there's not much they can do to remove or change how it appears in search engine rankings. For reference, doc.rust-lang.org is the only place to look for documentation for the standard libraries; any other hosting of those docs is likely to be out-of-date.

pjc50 12y ago

Never underestimate the legacy. I've resolved not to start another C++ project, but I'm learning MFC at the moment for working on a codebase that's 35 years old and was rewritten into C++ at some point in the 90s.

blt 12y ago
I'm sorry you have to do that.
- pjc50 12y ago
  I'm finding it not too bad; the style is somewhere between 'C with classes' and EnterpriseJavaReallyLongNames, and aggressive testing has kept it working over the years. MFC itself is pretty intuitive and I like the window message system.

threeseed 12y ago

>(2) large yet maintainable systems I have never seen anyone suggest Go for large systems or seen any open source code that even comes close to enterprise system size. I would argue that Go is inadequate for large systems compared to the JVM languages. The absence of operational tooling, exceptions, declarative annotations, runtime management etc all make it much harder to support and scale to large numbers of developers. Go seems perfect for micro services, command line utilities and single purpose applications. Which is where it seems to have gained a lot of traction in companies to date.

_bpo 12y ago
A big problem in large-scale systems is dependency management. One of the significant decisions that Go makes in its design is its approach to package management. Its approach isn't perfect, but is simple, making it a breath of fresh air compared to C++ or JVM-based languages... e.g. how many hours have been spent tweaking Maven or debugging discrepancies between classpaths referencing different copies of commons-logging? Speaking of Maven - `go build` normalizes build systems so there is less time twiddling builds. It's not a silver bullet, but it's specifically intended for large systems. Go's strong decisions around formatting (`go fmt`) are another example of planning for enterprise-size. There is no need for a style guide for go programs - it's built into the language, and with an approach that feels less pedantic than Python. Go isn't perfect, but it's certainly designed for large-scale systems. I agree with you that the JVM languages have better large-scale system support currently (20 years does give you something) -- but Go's goal is not dissimilar to the one Java eventually settled on after the applet craze. Contrary to what you've seen, Go seems (to me) to be a go-to language for new companies principally concerned with distributed systems / cloud infrastructure (particularly those that once might have hired a hybrid of C and scripting language devs). One of the trends in those communities is toward microservices / SOA / etc, but the total codebases managed are certainly enterprise-scale. All that said I have absolutely no significant opinions on Go vs Rust :) Just had to take issue with the "go is not enterprise scale" idea.
- desdiv 12y ago
  Go's strong decisions around formatting (`go fmt`) are another example of planning for enterprise-size. There is no need for a style guide for go programs - it's built into the language, and with an approach that feels less pedantic than Python. How is that different from the 40 years old Unix utility indent? Pretty much every single non-trivial programming language has its own code formatter. Auto code formatting is neither novel nor unique to Go.

shurcooL 12y ago

It seems relatively clear that he's quite new to both languages, with maybe a few weeks worth of familiarity if not less. From his rookie mistake of using path package instead of path/filepath to join system file paths [1], to non idiomatic naming with underscores, and what he describes in general. It's interesting from the perspective of what a fresh perspective on both languages is, but the comments have less value once you've spent significant time with either language and used them to build large projects. [1] https://gist.github.com/adamhjk/5a475b8dd45971a4e814#comment-1333555 https://gist.github.com/adamhjk/5a475b8dd45971a4e814#comment...

holoway 12y ago
I am absolutely quite (completely) new to both languages.

panic 12y ago

That leads you to wonder: if a programmer desired to switch from C/C++ to another language but hasn't by now, why not? Another reason to use C for your project is the ubiquity of C compilers and C bindings to other languages. Software like Lua and SQLite wouldn't be as widely-used if they were written in another language.

nhaehnle 12y ago

Another aspect that makes me hopeful about Rust as a way forward for C++ programmers is that it is designed to play well with the C (if not C++) ecosystem. Go is in this weird place where they insist that you have to be 100% Go or not at all, at least with the official Go package (gccgo is different, but this divergence in the ecosystem doesn't exactly inspire confidence). This is convenient when you have small isolated processes, but completely prevents Go adoption in other environments. I'm working in an electronic design automation software system which is basically a large number of C/C++ shared libraries/plugins loaded into a Tcl interpreter which you do not want to rewrite (lots of tricky and finely tuned optimization and design analysis algorithm). Go is not a good fit in this environment because of its all-or-nothing attitude. Rust, on the other hand, is fairly easy to imagine as an addition to the toolset from a purely technological point of view (ignoring the social and management issues which add a huge amount of inertia). There is an unfortunate impedance mismatch between idiomatic C++ and idiomatic Rust, but communication is possible via a thin C interface.

NateDad 12y ago
Uh... Go plays very well with C and C++. https://dennisforbes.ca/index.php/2013/07/23/the-most-powerful-feature-of-go-is-the-least-sexy/ https://dennisforbes.ca/index.php/2013/07/23/the-most-powerf...