-
-
Save pedromg/3045216 to your computer and use it in GitHub Desktop.
| 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." |
My feelings either. I've been paying some attention to Go for 2y. Now, starting a project using it + Google App Engine + Datastore. The procedural way as opposed to OOP.
They made some simple decisions like just by looking at a variable you know of its accessibility/visibility: capitalized first letter is public, lower case first letter makes the variable or struct private; No need to go up in the code to the definition to find out its visibility.
Working with procedural languages almost feels like a step back, but hopefully speed, the good core packages (ruby ecosystem exploded here, its big community gets almost everywhere with gems), a quickly compiled binary, and a good infrastructure integration, pays.
Have you tried it ?
Just for toy stuf. I have some pipe dreams that need to be flushed first. ;)
The procedural isn't mandatory. You can still get most part of the OO. You might not have hard inheritance but you still have LSP. And it isn't necessarily a step back. Look at DCI. They're just advocating procedural inside OO. ;P
Even with that luddite opinions, I will miss destructors/finalizers (I didn't bump into this when I was learning go. I sure hope they have solved this by now. Defer just doesn't cut it), I abhor their loathing of exceptions (panics are demi-exceptions in disguise. Why not go all the way?), I'm still not convinced on the "fake inheritance" and delegations thing, etc.
But alas, only practice will tell if those were decent tradeoffs. But, do mind, I generally like the lang very much and I'm very eager to experiment more on it.
When solving some real world problems, like some client problems, it is necessary to follow an approach that allows us to get back to the code for years. The ''internetwebs'' is full of hyped "blog demo" cases, solutions that may be interesting but make it hard to solve real problems. That is one of the reasons I am following Go for some time. Try to solve specific real problems. Real cases. In an integrated infrastructure that allows auto scale (even if it sounds "judgement day").
There's a Google IO12 talk by some devs referring their specific case Go experience in production (what matters), and they seem to be pleased. Speed is recurring. GC seems not to be an issue in their cases.
In Ruby land I tend to feel safe with exception handling but admit it may be an overused "safety net" and workaround for missing validations, testing, etc. Raising and dealing with an exception is easy. Almost all kinds of sloppy code is allowed using exception handling. A basic example: Client.get(9876).name will raise an exception if Client id 9876 isn't found because "name" isn't a defined method for nil (NilClass). And because get() returns nil in that case, and nil doesn't respond_to?('name'). But we now could go into the Client model to add a method get_the(args) so that if arg is_a? Numeric then we'll consider it an ''Id'' and if a String, fetch a ''name''. Then hours later we are proud of our increased abstraction level even if it takes 0,5 seconds to figure things out.
Exception handling is really awesome, but code inside blocks should be taken seriously.
The cleanness of ruby code, inside Modules, Classes, methods is (((super))). I really like it.
However highly abstraction levels seem not to be coping with the speed and concurrency levels that (global web) apps need when facing (hopefully) brutal access numbers. These guys in that IO12 talk by porting from Ruby to Go (once again there are pros and cons, each of these is driven by real different mindsets), downsized the number of servers on a brutal factor. That's a good "metric", server cardinality :)
Build a rails app; optimize it porting the code to Go. Why do I feel it will be a trend ? :-/
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 !! :-)
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.
I'm still trying to see where this will lead us. I'm quite happy with some decisions, not so much with others. But, in the end, all it matters is what we're capable of doing elegantly (maintenance included), not how much one agrees with the ways.