5 ms·

Go has committed the same faux-pas as C. It is true it won't make a difference for the truly diligent programmer, but not everyone is, and even the best can be

Go has committed the same faux-pas as C. It is true it won't make a difference for the truly diligent programmer, but not everyone is, and even the best can be off at 3am. 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. Your example is because of Java's use of checked exceptions. Exceptions are fine - checked exceptions are stupid and cause a different class of programming errors.

thraxil 14y ago
Sometimes the correct approach is to ignore the error. If printf or equivalent in a hello world program can't print to stdout, what should it do instead of crashing? Send an email? I don't think I've ever seen a hello world for a language with exceptions (checked or not) that actually handled an exception from printf either.
- 0xABADC0DA 14y ago
  Something like this: # /bin/echo "Hello World" >&- /bin/echo: write error: Bad file descriptor You get this kind of thing for free with exceptions.
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?
Peaker 14y ago
I don't think checked exceptions are stupid. I think Java's checked exceptions are bad, because the type system around them is too weak.

thraxil 14y ago

Sometimes the correct approach is to ignore the error. If printf or equivalent in a hello world program can't print to stdout, what should it do instead of crashing? Send an email? I don't think I've ever seen a hello world for a language with exceptions (checked or not) that actually handled an exception from printf either.

0xABADC0DA 14y ago
Something like this: # /bin/echo "Hello World" >&- /bin/echo: write error: Bad file descriptor You get this kind of thing for free with exceptions.

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?

Peaker 14y ago

I don't think checked exceptions are stupid. I think Java's checked exceptions are bad, because the type system around them is too weak.