3 ms·

I Like the ethos behind Dash but language design is also an art, and judging by Go - Google is not very good at it.

• equark 15y ago
  Your best bet is to check out Strongtalk to see if the main designers have a good artistic sense. It actually has a number of similarities to how Dart/Dash is described. http://www.strongtalk.org/index.html http://www.strongtalk.org/index.html Although perhaps because it's Smalltalk you can't learn much from this example.
• enneff 15y ago
  Wow, way harsh. Those of us that actually use Go are pretty enamored with it.
  • mythz 15y ago
    Let me explain, Rather than trying to make a language as aesthetically pleasing to the programmer as possible, the Go team tried to get by its limitations with design kludges and workarounds that are visually less appealing and intuitive then the many well-designed solutions that preceded it, e.g: - Error codes are a poor substitutions for Exceptions - Have to code around lack of generics, e.g. by abusing their typed map if possible - Defer less desirable and intuitive than C# using - array bracket notation prefixing the variable - No proper classes? I mean, take their example on a File type (http://golang.org/doc/go_tutorial.html http://golang.org/doc/go_tutorial.html): type File struct { fd int name string } func (file File) Read(b []byte) (ret int, err os.Error) {} func (file File) Write(b []byte) (ret int, err os.Error) {} file := &File{fd, "file.txt"} The same signatures in CoffeeScript can be achieved by: class File constructor: (@name) -> read: (cb) -> write: (contents) -> file = new File "file.txt" Which I'm sure a majority of people would find a lot more readable. Just for kicks I decided to rewrite Go's Cat example to StdOut in CoffeeScript for a side-by-side comparison. The examples are fairly close but not exact, i.e. cat.Go implements via streaming while CoffeeScript's is non-blocking. https://gist.github.com/1207994 https://gist.github.com/1207994 The CoffeeScript version ways in at 12 LOC, while Go's example is over 110 LOC and a lot more unfriendlier on the eye.
    • akkartik 15y ago
      That's a terribly biased comparison. The go example defined stdin/stdout/stderr from scratch and much else besides, while the coffeescript version basically called a library function. It's very hard to compare statically-typed system languages with dynamically-typed HLLs. And it's utterly misleading to judge one by the standards of the other.
      • deleted 15y ago
        [deleted]
      • mythz 15y ago
        That was Go's cat example not mine (I just copied and pasted what was needed for the e.g. to work) - and they both delegated to underlying system/lib calls to do the actual work. The examples do show how to create a higher-level 'File' api to encapsulate lower level os functions, which was the primary motive for their example. The readability of on the different approaches on how to do this is clear in both source files. As for the dynamic vs static argument, well I've added the C# version (sync and streaming) both of which are still less code and more intuitive than go's. https://gist.github.com/1208021 https://gist.github.com/1208021
    • phoboslab 15y ago
      Your comparison is unfair, because CoffeeScript and Go try to do vastly different things. Go is a fairly low level systems language, while CoffeeScript is as high level as it gets. That said, what Go achieves with its syntax is remarkable, imho. Consider this: How do you add another function (e.g. "close()") to your file class in CoffeeScript? By extending the existing class into a "MyFile" class? But then you have to make sure all your "File" instances are actually instances of "MyFile", so you can call your newly defined function on them. In Go you just define the new function.
      • Ezku 15y ago
        Not to detract from your point of vastly different things, but you picked a bad example. You add a method to the prototype: File::close = -> Et voilà, all Files are closeable.
  • DanWaterworth 15y ago
    Speak for yourself, I really don't like Go.
  • jroseattle 15y ago
    As are those who use just any language/environment of their choice. So what?