4 ms·

They are both being used, where C and C++ were the only alternative Some of the points to be made here is that C and C++ are being used for a very wide range o

They are both being used, where C and C++ were the only alternative Some of the points to be made here is that C and C++ are being used for a very wide range of applications So if you do compare Go and Rust, you will find distinct technical advantages and disadvantage Rust/Go are currently the C/C++ alternative

k__ 9y ago
But it seems to me that Go is used especially by non C/C++ devs.
- systems 9y ago
  well, people wrote servers in all sorts of languages I like to think of it this way (image the line below is the range of software c/c++ is being used for, systems software on far left and apps on far right) (systems)------------------C/C++------------------(apps) People coming from left prefer Rust, people coming from the right prefer Go
- matt_wulfeck 9y ago
  Of course it is and it makes sense. Learning safe and correct C/C++ is a big challenge. You can do this, or write it in Go. It will be 80% as fast but take you much less time. It will also be safe. Once you’ve learned all of the ins-outs of C/C++ then you don’t have an incentive to use Go to replace them. When you don’t need performance you can use a scripting language like ruby or python. I see this happen often.
zeveb 9y ago
> They are both being used, where C and C++ were the only alternative > Some of the points to be made here is that C and C++ are being used for a very wide range of applications That's a really good point. C is an odd language: people used it to squeeze every ounce of performance out of machines, even when they didn't need to. E.g. an ls or cat written in C is almost certainly a premature optimisation. Even a program like Sendmail should probably have been written in something like Lisp or Go (had it existed) rather than in C (and anyone over a certain age knows the high price of Sendmail being written in C: vulnerability after vulnerability). People were using C almost as a scripting language, which in retrospect is insane. Using it as a portable assembler to build the bulk of an OS, or at least the low-level parts of an OS, made sense — trying to use it for high-level programming was a mistake. I write Go every day, but I'd like to take a look at Rust eventually. I wonder if decent Rust can be written as quickly as decent Go can.
- vram22 9y ago
  >People were using C almost as a scripting language, which in retrospect is insane. Using it as a portable assembler to build the bulk of an OS, or at least the low-level parts of an OS, made sense — trying to use it for high-level programming was a mistake. Before C++ and some of the less and more recent higher-level languages became available and were stable enough, people were writing both business applications and desktop / server software products in C - a lot. Biz apps that required database-like functionality were written either using ISAM-type libraries or low-level proprietary database APIs (specific to a particular database server) or using embedded SQL in C (e.g. Pro-C for Oracle, ESQL/C for Informix, DB-Library for Sybase, etc. And lots of successful Unix and Win32 software products were written in C, for both the logic and GUI parts of the apps. I've worked some earlier on real projects / products of all those types I mentioned (except Sybase). Some higher level products such as 4GLs also existed (for reporting and other purposes) and those were used too, but C was still used, even for business apps. When there were less of good higher-level-but-still performant choices available, and hardware was not as powerful, it was not an insane option at all. Plus, as is known to C programmers, "in C you can do anything." Not many higher-level languages can say that - except by linking to C libs via FFIs of some type. Obviously there were cons involved too, such as string handling, memory and pointer management, and less productivity than higher-level tools. https://en.wikipedia.org/wiki/Embedded_SQL https://en.wikipedia.org/wiki/Embedded_SQL https://en.wikipedia.org/wiki/Pro*C https://en.wikipedia.org/wiki/Pro*C https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.esqlc.doc/ids_esqlc_0862.htm https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0...

k__ 9y ago

But it seems to me that Go is used especially by non C/C++ devs.

systems 9y ago
well, people wrote servers in all sorts of languages I like to think of it this way (image the line below is the range of software c/c++ is being used for, systems software on far left and apps on far right) (systems)------------------C/C++------------------(apps) People coming from left prefer Rust, people coming from the right prefer Go
matt_wulfeck 9y ago
Of course it is and it makes sense. Learning safe and correct C/C++ is a big challenge. You can do this, or write it in Go. It will be 80% as fast but take you much less time. It will also be safe. Once you’ve learned all of the ins-outs of C/C++ then you don’t have an incentive to use Go to replace them. When you don’t need performance you can use a scripting language like ruby or python. I see this happen often.

zeveb 9y ago

> They are both being used, where C and C++ were the only alternative > Some of the points to be made here is that C and C++ are being used for a very wide range of applications That's a really good point. C is an odd language: people used it to squeeze every ounce of performance out of machines, even when they didn't need to. E.g. an ls or cat written in C is almost certainly a premature optimisation. Even a program like Sendmail should probably have been written in something like Lisp or Go (had it existed) rather than in C (and anyone over a certain age knows the high price of Sendmail being written in C: vulnerability after vulnerability). People were using C almost as a scripting language, which in retrospect is insane. Using it as a portable assembler to build the bulk of an OS, or at least the low-level parts of an OS, made sense — trying to use it for high-level programming was a mistake. I write Go every day, but I'd like to take a look at Rust eventually. I wonder if decent Rust can be written as quickly as decent Go can.

vram22 9y ago
>People were using C almost as a scripting language, which in retrospect is insane. Using it as a portable assembler to build the bulk of an OS, or at least the low-level parts of an OS, made sense — trying to use it for high-level programming was a mistake. Before C++ and some of the less and more recent higher-level languages became available and were stable enough, people were writing both business applications and desktop / server software products in C - a lot. Biz apps that required database-like functionality were written either using ISAM-type libraries or low-level proprietary database APIs (specific to a particular database server) or using embedded SQL in C (e.g. Pro-C for Oracle, ESQL/C for Informix, DB-Library for Sybase, etc. And lots of successful Unix and Win32 software products were written in C, for both the logic and GUI parts of the apps. I've worked some earlier on real projects / products of all those types I mentioned (except Sybase). Some higher level products such as 4GLs also existed (for reporting and other purposes) and those were used too, but C was still used, even for business apps. When there were less of good higher-level-but-still performant choices available, and hardware was not as powerful, it was not an insane option at all. Plus, as is known to C programmers, "in C you can do anything." Not many higher-level languages can say that - except by linking to C libs via FFIs of some type. Obviously there were cons involved too, such as string handling, memory and pointer management, and less productivity than higher-level tools. https://en.wikipedia.org/wiki/Embedded_SQL https://en.wikipedia.org/wiki/Embedded_SQL https://en.wikipedia.org/wiki/Pro*C https://en.wikipedia.org/wiki/Pro*C https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.esqlc.doc/ids_esqlc_0862.htm https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0...