Rob Pike list of simplifications in Go over C++

gistfile1.txt

http://commandcenter.blogspot.pt/2012/06/less-is-exponentially-more.html

"In the end of course it came out quite different from either C or C++. More different even
 than many realize. I made a list of significant simplifications in Go over C and C++:

    regular syntax (don't need a symbol table to parse)
    garbage collection (only)
    no header files
    explicit dependencies
    no circular dependencies
    constants are just numbers
    int and int32 are distinct types
    letter case sets visibility
    methods for any type (no classes)
    no subtype inheritance (no subclasses)
    package-level initialization and well-defined order of initialization
    files compiled together in a package
    package-level globals presented in any order
    no arithmetic conversions (constants help)
    interfaces are implicit (no "implements" declaration)
    embedding (no promotion to superclass)
    methods are declared as functions (no special location)
    methods are just functions
    interfaces are just methods (no data)
    methods match by name only (not by type)
    no constructors or destructors
    postincrement and postincrement are statements, not expressions
    no preincrement or predecrement
    assignment is not an expression
    evaluation order defined in assignment, function call (no "sequence point")
    no pointer arithmetic
    memory is always zeroed
    legal to take address of local variable
    no "this" in methods
    segmented stacks
    no const or other type annotations
    no templates
    no exceptions
    builtin string, slice, map
    array bounds checking


And yet, with that long list of simplifications and missing pieces, Go is, I believe, more 
expressive than C or C++. Less can be more.

But you can't take out everything. You need building blocks such as an idea about how types behave, 
and syntax that works well in practice, and some ineffable thing that makes libraries interoperate well.

We also added some things that were not in C or C++, like slices and maps, composite literals, 
expressions at the top level of the file (which is a huge thing that mostly goes unremarked), 
reflection, garbage collection, and so on. Concurrency, too, naturally."

I don't argue about the use of exceptions. I use them, a lot. Its a safety net. Can ensure clean and organized code, and that's why I will stick with Ruby as my class object based language.

I don't know how will Rubinius team handle its roadmap. I sometimes try some scripts (RVM ftw!!) and still face problems. Even in JRuby. JRuby has some interesting benchmarks, more and more people using it, but there still are compatibility issues to solve, even if the team is doing a great job.

I honestly feel safer with the "official" Ruby VMs. And the amount of dependencies matters. Even if more dependencies may mean easier/faster job done, one needs to evaluate the "what if this faces a dead end?".
Sincerely hope Go won't lose traction. The team is superb. Google backed. Used inside Google. Growing community. With an infrastructure ready to deploy, AppEngine (think Heroku easiness). Great package libs. Open sourced. Free license. Compiled. Binaries. Strong type. Easy declaration.

http://youtu.be/sln-gJaURzk Hey, Ken Thompson !! :-)

On Tue, Jul 10, 2012 at 6:15 PM, pedro mg < ***@***.*** > wrote: I don't argue about the use of exceptions. I use them, a lot. Its a safety net. Can ensure clean and organized code, and that's why I will stick with Ruby as my class object based language.

I'd argue it's much more than that. But over a beer, please. :P

I don't know how will Rubinius team handle its roadmap. I sometimes try some scripts (RVM ftw!!) and still face problems. Even in JRuby. JRuby has some interesting benchmarks, more and more people using it, but there still are compatibility issues to solve, even if the team is doing a great job.

Fair enough.

I honestly feel safer with the "official" Ruby VMs. And the amount of dependencies matters. Even if more dependencies may mean easier/faster job done, one needs to evaluate the "what if this faces a dead end?". Sincerely hope Go won't lose traction. The team is superb. Google backed. Used inside Google. Growing community. With an infrastructure ready to deploy, AppEngine (think Heroku easiness). Great package libs. Open sourced. Free license. Compiled. Binaries. Strong type. Easy declaration. http://youtu.be/sln-gJaURzk Hey, Ken Thompson !! :-)

I have to watch this! :)

Rob Sir, your contribution to Golang is amazing. Great simplifications. I like it. I love Golang and its features. Sir, in line number 27, there is a little mistake, the 'postincremet' word is coming repeatedly. I should not notify this but I did this. This is very nice list of simplifications that I was looking for.