The Go Programming Language, or: Why all C-like languages except one suck.

Post by beagle3 » Fri, Mar 09, 2012, 5:41 PM UTC

cageface wrote: post #59

robot wrote: post #35

dynamic_cast >(funky_iterator >(foo::iterator_type (obj)) Yeah. Right. Don't get me wrong, I love templates, but contemporary C++ using STL looks like a classic case of the "If all you have is a hammer"-syndrome. GCC had to implement special diagnostic simplifications just so you can actually find out that that 5-line error message was a simple const'ness mistake when using a std::string method. Even worse, they can…

Every language has its pathological corner cases. Modern C++ using the STL is almost as terse as modern dynamic languages but runs 100x faster.

Post by grannyg00se » Fri, Mar 09, 2012, 8:02 PM UTC

jganetsk wrote: post #82

grannyg00se wrote: post #58

Earlier quoted context omitted.

Some of the implementations in JS went wrong, but fundamentally it really doesn't have anything horrible going on for what it's meant to do. Unfortunately some of the implementation details do allow for seriously horrible code and some seriously horrible traps. But if you can clear the fog, and use "the good parts", it's actually pretty nice. As for the article, I think it's very well written and seems to have a good…

I am not talking about any APIs in JS or any "implentation in JS". JS, the language, as specified, is wrong at the core. It has a lot of insensible semantics. It's not even at a local maximum. I could just write a list of 10 changes to the language right now that would spur near-unanimous agreement of benefit with no downside.

Post by casualsuperman2 » Fri, Mar 09, 2012, 11:23 PM UTC

ericbb wrote: post #71

klon wrote: post #56

Earlier quoted context omitted.

Ok but exceptions also give you alot of context about the error like exactly where it occured. How is that handled in Go?

The error type is an interface. You can return values that contain contextual information as long as the error value you return has an Error() method returning a string. type ParseError struct { line int } func (e ParseError) Error() string { return "Parse error at line: " + fmt.Sprint(e.line) } Note: The current release may vary slightly on the details. I'm using a pre-release build. But older versions are similar.

   switch err.(type) {
      case db.IOError:
          // Database exception here
      case io.FileNotFoundError:
          // File exception
      default:
          // Pass it to our caller for them to handle.
          return nil, err
   }