7 ms·

Go hasn't been intended for "systems programming" for quite a while. It is a general purpose language.

by Ironballs 12y ago

tomwilde 12y ago
Those properties are not mutually exclusive.
- seabee 12y ago
  C++ is the counterexample in nearly all such cases, for better or worse!
- rakoo 12y ago
  The important distinction here is that go creators never set "system programming" as a goal, contrary to what OP implied in the blog post. Now, whether go turns out to be good at that task is another story
  - andralex 12y ago
    Go has been announced as a systems programming language: https://www.youtube.com/watch?v=rKnDgT73v8s https://www.youtube.com/watch?v=rKnDgT73v8s. After some backlash the slogan has been changed quietly.
jacques_chester 12y ago
Nevertheless, many of the design decisions make sense in that context. For example: the difference in initialisation of simple data types vs slices and maps. For an application programmer these are weird inconsistencies. But they make sense in the domain. Or the way error handling works. Very tedious to have to do-check, do-check, and not be able to have automatic upwards delegation. But in system programming it's about robustness, not ease of development. A database server can't just restart if it has a file or memory problem. There needs to be a solution and it needs to be immediately next to the problem.
- Gracana 12y ago
  I don't do anything quite so tedious in my Go-based webserver projects. For functions that can return errors that I don't have a way to recover from (db calls, for example), I use a simple rapper function that automatically logs errors and panics. That doesn't seem to me like much of a source of difficulty or complexity.
  - jacques_chester 12y ago
    Web apps are apps, they have different expectations and provide different levels of robustness guarantees. As I said, Go's design decisions are motivated by a different problem domain. That being said, I've followed a similar pattern in writing Go web apps. I passed errors upwards from their originating site to the HTTP handler functions, because that was where the error handling was possible with the best context.

Go hasn't been intended for "systems programming" for quite a while. It is a general purpose language.

tomwilde 12y ago

Those properties are not mutually exclusive.

seabee 12y ago
C++ is the counterexample in nearly all such cases, for better or worse!
rakoo 12y ago
The important distinction here is that go creators never set "system programming" as a goal, contrary to what OP implied in the blog post. Now, whether go turns out to be good at that task is another story
- andralex 12y ago
  Go has been announced as a systems programming language: https://www.youtube.com/watch?v=rKnDgT73v8s https://www.youtube.com/watch?v=rKnDgT73v8s. After some backlash the slogan has been changed quietly.

jacques_chester 12y ago

Nevertheless, many of the design decisions make sense in that context. For example: the difference in initialisation of simple data types vs slices and maps. For an application programmer these are weird inconsistencies. But they make sense in the domain. Or the way error handling works. Very tedious to have to do-check, do-check, and not be able to have automatic upwards delegation. But in system programming it's about robustness, not ease of development. A database server can't just restart if it has a file or memory problem. There needs to be a solution and it needs to be immediately next to the problem.

Gracana 12y ago
I don't do anything quite so tedious in my Go-based webserver projects. For functions that can return errors that I don't have a way to recover from (db calls, for example), I use a simple rapper function that automatically logs errors and panics. That doesn't seem to me like much of a source of difficulty or complexity.
- jacques_chester 12y ago
  Web apps are apps, they have different expectations and provide different levels of robustness guarantees. As I said, Go's design decisions are motivated by a different problem domain. That being said, I've followed a similar pattern in writing Go web apps. I passed errors upwards from their originating site to the HTTP handler functions, because that was where the error handling was possible with the best context.