5 ms·
I'm a C++ and python programmer with some basic experience in JavaScript. I started learning Go, as I looked into D some years ago, an was a bit puzzled by some
by chmike 14y ago
I'm a C++ and python programmer with some basic experience in JavaScript. I started learning Go, as I looked into D some years ago, an was a bit puzzled by some design choices.
I don't understand the need to enforce the use of { } and that the if of for line must end with a {. I don't like this writing. My preferred syntax is the one of Pythons, which is the most concise and clear. It seem Go could have used : and indentation as in python instead of { }.
Another puzzling choice of Go is slicing which differ from Python's and D's. In Go slicing is limited by the capacity and not by the number of items it contains. Returning 0 as default value looks to me like an open door to silent bugs.
The way Go handles errors looks original and interesting, but I'm lacking experience to determine how it compares to exceptions from the usage perspective.
From what I saw, I would say that Go is a better C and D is a better C++ where better means also closer. As a consequence Go seams simpler than D to learn and use. Thus I expect we will see much more Go programmers than D programmers in the future. Simplicity has been proven many times to be trump.
- mseepgood 14y ago> I don't understand the need to enforce the use of { } and that the if of for line must end with a {. I don't like this writing. My preferred syntax is the one of Pythons, which is the most concise and clear. This article explains the reasoning behind lots of Go's design choices: http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article "Some observers objected to Go's C-like block structure with braces, preferring the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause. It is better to forgo convenience for safety and dependability, so Go has brace-bounded blocks."
- ma2rten 14y agoMy personal opinion on the subject is that you should not obsess about those things. It is good that Go that enforces one consistent style. In practice it does not really matter for your productivity what that style is. That said, I don't consider this a convincing argument. They basically say "We had some problems in the past with embedding Python code in Java files". This is a very specific problem and I could think of at least 4 different specific solutions for this specific problem. I don't think this arguement can support very broad conclusions like "Spaces for indentation does not scale to big and heterogeneous code bases and compromises safety and dependability for convenience".
- nkozyra 14y ago> My personal opinion on the subject is that you should not obsess about those things. It is good that Go that enforces one consistent style. In practice it does not really matter for your productivity what that style is. My qualm with Go here is that it does not enforce a consistent style. (note: I use Go quite frequently). Trailing semicolons, parentheses, curly braces should either be valid or invalid. There are instances in the languages where either is fine.
- nemothekid 14y agoIts convinced if you consider that Go was made to solve most of Google's problems.
- hp50g 14y agoI find that the braces and termination policy forcibly avoid stuff like: for p = initial; p.next != nil; p = p.next; doSomething(p); This is a whole class of pain I've had to debug before. Better to be explicit. I'm not really a fan of python indentation as I've had to clean up a couple of messes before.
- dom96 14y agoSo use Nimrod instead: systems programming with indentation based syntax. It also has unmatched meta programming facilities, a realtime GC and checked exceptions done right (however, not in the 0.9.0 release).
- trailfox 14y agoInteresting, I hadn't heard of it before: http://nimrod-code.org/ http://nimrod-code.org/
- pjmlp 14y agoIt looks it could be another language to use for writing native code across iOS, Android and Windows.
- dom96 14y agoIndeed. In fact Nimrod has already been used on Android (http://forum.nimrod-code.org/t/61#319 http://forum.nimrod-code.org/t/61#319) and iOS devices.
- NateDad 14y agoThe formatting has been well thought out. The main problems with Python formatting are copy and paste problems, source control merges, and relying on the count of invisible characters to determine indenting. Any time you're merging two bits of code, it's very easy for the indenting to get messed up. In go, that's not a problem, since the braces are the only thing that matter. This is also what allows gofmt to format your code for you. I think you misunderstand slicing. It's very similar to python's slices, except that python makes a copy of the list and Go does not. This is a really nice feature for reducing data copies. The default values are very useful in many situations, and code is often designed around the fact that uninitialized variables have specific values. As for error handling, Go's error handling is one of its biggest strengths, in my opinion. You never have to worry that your function will exit out in the middle unexpectedly. This is really great when dealing with third party libraries, since you don't have to know if something 6 levels deep is going to throw an exception... if something returns an error, you can deal with it right there. I find I write much more reliable code in Go, because error handling is so much simpler.
- TylerE 14y agoI find it acceptable, since they did away with semi-colons, which always offended me a lot more than braces.
- ansible 14y ago...since they did away with semi-colons, which always offended me a lot more than braces. The semi-colons are still there, but in most cases they can be inserted automatically when the program is being compiled.
- __david__ 14y ago> The way Go handles errors looks original and interesting, but I'm lacking experience to determine how it compares to exceptions from the usage perspective. Having done a lot of straight C programming in my life, the error handling in Go is very familiar. Most C code returns errors and doesn't use exceptions (though I have used setjmp()/longjmp() fairly successfully at times). In practice, the code is more verbose with Go's style of returned errors, but requires you to think more explicitly about errors and recovery, resulting in potentially better code overall. However, since Go doesn't have an RIAA like C++ and doesn't have "goto" like C, it makes cleaning up from errors more ugly and repetitious (and potentially error prone). File handling, in particular, is causing me headaches right now (getting files closed on errors). I am admittedly a Go newbie, so I may be missing some style that makes it cleaner.
- timewasted 14y agoGetting files closed on errors should look something like: file, err := os.Open(filename) if err != nil { // handle the error however you see fit } defer file.Close() // continue working, knowing that file.Close() will be called when the surrounding function returns See: http://golang.org/doc/effective_go.html#defer http://golang.org/doc/effective_go.html#defer
- __david__ 14y agoAh! Thanks! I had seen panic/recover but hadn't caught "defer". That will make my code much better.