5 ms·

C is hard. You're right though, why not use C? It's a good language, and it's hard to beat for it's low level powers, portability and speed. What go gives you

C is hard. You're right though, why not use C? It's a good language, and it's hard to beat for it's low level powers, portability and speed. What go gives you is high level productivity, testing, a solution for package management (abit a rubbish one), and a good ecosystem of 3rd party libraries for things like AWS. The things that suck about C: - It's hard to do right. There's a great book called 'Deep C Secrets' on this topic by Peter van der Linden. If you haven't read it, I recommend against writing a large project in C until you have. - C has no package management solution at all. Go doesn't have a great one, but at least it has some kind of high level management for this. Working with C dependencies and the C various build tools for them is a nightmare. - C has no memory safety, which means if you do screw up, the 'things that can do wrong' are much much worse than if you screw up in a relatively safe language like python or java. - C (and even 'modern C++') suffer from major portability problems. Not that it's not portable; it is, but in order to be portable, you have to write weird, arcane and terrible code. It's entirely common to see code littered with `#ifdef WIN32 ...` or a typedef for every primitive type (eg. mInt32) to abstract across compiler differences etc. This means any code coverage you get is probably going to poorly represent the actual code in the library. Oh, did I mention C has no test runner? (although to be fair, CMake helps). On the other hand, it is extremely embedable, and if you know what you're doing, it is the right choice. Have a look at this excellent highly portable IPC library: https://github.com/saprykin/plibsys https://github.com/saprykin/plibsys <-- That's the right choice for the right job. It's also the right choice, arguably, for a low level component that might import into some other slow-as-balls language like python. I'd argue Rust is a better choice, but hey, its much of a muchness. ...but for a web service or web framework? nah. Go was written specifically for those purposes, with high throughput performance as its goal, and a significant amount of effort devoted to optimizing that. It's not suitable for something like plibsys either.

vegabook 10y ago
I have to write a whole bunch of if Sys.info()["sysname"] == "Windows" even in R!
oneloop 10y ago
Thanks for this answer. After reading it it seems to me that every other answer is just saying "C is hard" with a lot of words.
gummiruessel 10y ago
>Have a look at this excellent highly portable IPC library: https://github.com/saprykin/plibsys https://github.com/saprykin/plibsys <-- That's the right choice for the right job. >[...] >...but for a web service or web framework? >nah. >Go was written specifically for those purposes, with high throughput performance as its goal, and a significant amount of effort devoted to optimizing that. >It's not suitable for something like plibsys either. I found this part of your comment difficult to understand. Is C not suitable for plibsys after all, or is it Go which wouldn't be suitable, or something else?
- shadowmint 10y ago
  Sorry, I was referring to go at the end there. The point I was making is: Don't pick go. Or C. Or Rust. ...unless it's the right tool for the job. Or at least the right sort of tool; there's plenty of cross over. In this case (web framework), C isn't the right tool for the job. ...but, to be fair, C is the right tool for some jobs.
znpy 10y ago
Besides, keep in mind that the C language has some "weird corners" and in some considtions, you might encounter an "unspecified behaviour" scenario. For short, there are some cases in which the C language specification does not tell you what to do and how to interprete code and in this cases, the choice is left to the compiler. This is not trivial as it might look. For example, what happens when you omit the return statement at the end of a function? GCC will to automatically insert a return statement for you, but Clang will not. Both are perfectly fine behaviours... As long as you are aware of it. If you always compiled your code with GCC and suddenly switch to clang you might see weird shit, because the processor reached the end of your function, found no return instruction, and just went ahead and executed whatever code was put after your function (and it might not be so obvious what code is there). (But in a way, this is part of the beauty of the C language: there is very little abstraction, and it is easy to understand what will happen when you run C code.)
Shorel 10y ago
> C has no package management solution at all. Curiously, I just found this today: https://conan.io/ https://conan.io/ It seems to be a full featured package manager to use with C and C++.

vegabook 10y ago

I have to write a whole bunch of if Sys.info()["sysname"] == "Windows" even in R!

oneloop 10y ago

Thanks for this answer. After reading it it seems to me that every other answer is just saying "C is hard" with a lot of words.

gummiruessel 10y ago

>Have a look at this excellent highly portable IPC library: https://github.com/saprykin/plibsys https://github.com/saprykin/plibsys <-- That's the right choice for the right job. >[...] >...but for a web service or web framework? >nah. >Go was written specifically for those purposes, with high throughput performance as its goal, and a significant amount of effort devoted to optimizing that. >It's not suitable for something like plibsys either. I found this part of your comment difficult to understand. Is C not suitable for plibsys after all, or is it Go which wouldn't be suitable, or something else?

shadowmint 10y ago
Sorry, I was referring to go at the end there. The point I was making is: Don't pick go. Or C. Or Rust. ...unless it's the right tool for the job. Or at least the right sort of tool; there's plenty of cross over. In this case (web framework), C isn't the right tool for the job. ...but, to be fair, C is the right tool for some jobs.

znpy 10y ago

Besides, keep in mind that the C language has some "weird corners" and in some considtions, you might encounter an "unspecified behaviour" scenario. For short, there are some cases in which the C language specification does not tell you what to do and how to interprete code and in this cases, the choice is left to the compiler. This is not trivial as it might look. For example, what happens when you omit the return statement at the end of a function? GCC will to automatically insert a return statement for you, but Clang will not. Both are perfectly fine behaviours... As long as you are aware of it. If you always compiled your code with GCC and suddenly switch to clang you might see weird shit, because the processor reached the end of your function, found no return instruction, and just went ahead and executed whatever code was put after your function (and it might not be so obvious what code is there). (But in a way, this is part of the beauty of the C language: there is very little abstraction, and it is easy to understand what will happen when you run C code.)

Shorel 10y ago

> C has no package management solution at all. Curiously, I just found this today: https://conan.io/ https://conan.io/ It seems to be a full featured package manager to use with C and C++.