4 ms·

The simple proof that Go's approach is wrong is to look for all the Hello World examples. I have yet to find one that looks at the error return of the println,

by papaf 14y ago

The simple proof that Go's approach is wrong is to look for all the Hello World examples. I have yet to find one that looks at the error return of the println, just like none look at the return of C's printf. The builtin println does not return a value. As stated in the language specification: http://golang.org/ref/spec#Bootstrapping http://golang.org/ref/spec#Bootstrapping

drivebyacct2 14y ago
You're also not meant to use those, they're generally discouraged. rogerbinns is right, fmt.Println() does indeed return an error value. I still don't understand the argument. Println() can fail. That's why it is able to return an error. You can choose to ignore it, that's fine. If it's something that you're worried about failing, then it's worth the "effort" to handle the error where and when it happens. I guess ultimately, all of this stuff is such a non-issue. It's a cliched response to a lot of Go criticism, but acutally write something in it. Armchair critics would have you believe that exceptions and generics missing is the end of the world. Number one, it's not. Number two, these simplifications exist for a reason. One of Go's guiding principles is minimizing magic that is not visible or explicit. (That's why new/make exist, no exceptions, no generics). It eases development speed, code clarity and compile times.
- ntrel 14y ago
  Lack of generics does not ease development speed. Generic programming is about safe reusability. (Development speed includes the test, debug, fix cycle). No generics actually harms code clarity and destroys type safety.
  - sadga 14y ago
    Missing generics -- it doesn't destroy type safety, it just forces the developer to write boilerplate variations of every method. The official stance on that issue is: yeah, but it's better than the hassle of supporting generics (compiler effort, object code size/slowness, and excessive high-level abstraction (a bad thing in the Go world). I have a foot on both sides: I miss generics when I'm writing one-off low-scalability code, but it's nice to have the speed of low-level Go code, and perversely fun to actually spend some of my coding time writing all those low-level sorting and array-building routines that are the meat of programmer interviews. Now, when a candidate asks "When will I need to write a method to sort the keys of a map?", I can answer "Every time you use a map[string]T for a novel T!" I hate novel T now. (<-- This is also a design feature of Go, the passive pressure to not use large hierarchical types, and try to do your work with just maps and slices of primitives)
  - wonderzombie 14y ago
    Most of the time, a combination of interfaces and slices (read: souped up arrays) is enough. In practice, when your arrays don't suck like they do in C, C++, or Java, you can get a lot of work done with them. It's actually clearer as to what's going on since slices are a language primitive. They are simple and extremely transparent. This is absolutely not the case with Java's collections library or the C++ STL. It wouldn't be a trade-off if there weren't situations where generics are really useful. But this rings more like an armchair criticism of Go than a criticism from someone who's written some Go programs. For my part, I wish languages like Java were less hostile to arrays.
    - ntrel 14y ago
      Arrays and slices really have nothing to do with generic programming. Java has poor generic support (type erasure) and C++ has poor syntax and a bad design for iterators. Languages with decent generics support have none of these problems. If this is 'armchair criticism' why do Go's designers say they are considering adding generics support?
- rogerbinns 14y ago
  I did mean fmt.PrintLn. A canonical hello world program should have a non-success exit code if the "hello world" printing failed. This will happen automatically with exceptions and similar mechanisms. The problem with Go's error approach is that you have to handle it where it happens. You can't delegate the error handling to a function 5 levels back in the call chain. So you end up having to write boilerplate code around every single call and intermediary layer, or just not be diligent, and that lack of diligence starts with hello world. It is the boilerplate code I object to, and exceptions are just one pre-existing solution. For example Go could recognise code patterns and automatically run code that returns errors to the caller if not otherwise handled or marked as ignored, although this is a certain amount of magic. Since there is no code for ignored errors, that means there is no code test coverage for them. For example coverage on hello world will always be 100% even though the case of println failing didn't happen. Multiply this by a larger program and there be gremlins.

by papaf 14y ago

drivebyacct2 14y ago

You're also not meant to use those, they're generally discouraged. rogerbinns is right, fmt.Println() does indeed return an error value. I still don't understand the argument. Println() can fail. That's why it is able to return an error. You can choose to ignore it, that's fine. If it's something that you're worried about failing, then it's worth the "effort" to handle the error where and when it happens. I guess ultimately, all of this stuff is such a non-issue. It's a cliched response to a lot of Go criticism, but acutally write something in it. Armchair critics would have you believe that exceptions and generics missing is the end of the world. Number one, it's not. Number two, these simplifications exist for a reason. One of Go's guiding principles is minimizing magic that is not visible or explicit. (That's why new/make exist, no exceptions, no generics). It eases development speed, code clarity and compile times.

ntrel 14y ago
Lack of generics does not ease development speed. Generic programming is about safe reusability. (Development speed includes the test, debug, fix cycle). No generics actually harms code clarity and destroys type safety.
- sadga 14y ago
  Missing generics -- it doesn't destroy type safety, it just forces the developer to write boilerplate variations of every method. The official stance on that issue is: yeah, but it's better than the hassle of supporting generics (compiler effort, object code size/slowness, and excessive high-level abstraction (a bad thing in the Go world). I have a foot on both sides: I miss generics when I'm writing one-off low-scalability code, but it's nice to have the speed of low-level Go code, and perversely fun to actually spend some of my coding time writing all those low-level sorting and array-building routines that are the meat of programmer interviews. Now, when a candidate asks "When will I need to write a method to sort the keys of a map?", I can answer "Every time you use a map[string]T for a novel T!" I hate novel T now. (<-- This is also a design feature of Go, the passive pressure to not use large hierarchical types, and try to do your work with just maps and slices of primitives)
- wonderzombie 14y ago
  Most of the time, a combination of interfaces and slices (read: souped up arrays) is enough. In practice, when your arrays don't suck like they do in C, C++, or Java, you can get a lot of work done with them. It's actually clearer as to what's going on since slices are a language primitive. They are simple and extremely transparent. This is absolutely not the case with Java's collections library or the C++ STL. It wouldn't be a trade-off if there weren't situations where generics are really useful. But this rings more like an armchair criticism of Go than a criticism from someone who's written some Go programs. For my part, I wish languages like Java were less hostile to arrays.
  - ntrel 14y ago
    Arrays and slices really have nothing to do with generic programming. Java has poor generic support (type erasure) and C++ has poor syntax and a bad design for iterators. Languages with decent generics support have none of these problems. If this is 'armchair criticism' why do Go's designers say they are considering adding generics support?
rogerbinns 14y ago
I did mean fmt.PrintLn. A canonical hello world program should have a non-success exit code if the "hello world" printing failed. This will happen automatically with exceptions and similar mechanisms. The problem with Go's error approach is that you have to handle it where it happens. You can't delegate the error handling to a function 5 levels back in the call chain. So you end up having to write boilerplate code around every single call and intermediary layer, or just not be diligent, and that lack of diligence starts with hello world. It is the boilerplate code I object to, and exceptions are just one pre-existing solution. For example Go could recognise code patterns and automatically run code that returns errors to the caller if not otherwise handled or marked as ignored, although this is a certain amount of magic. Since there is no code for ignored errors, that means there is no code test coverage for them. For example coverage on hello world will always be 100% even though the case of println failing didn't happen. Multiply this by a larger program and there be gremlins.