Weekly Edition
Return to the Development page
| |||||||||||||
Quotes of the week
I was asked a few weeks ago, "What was the biggest surprise you
encountered rolling out Go?" I knew the answer instantly: Although
we expected C++ programmers to see Go as an alternative, instead
most Go programmers come from languages like Python and Ruby. Very
few come from C++.
— Rob
Pike
It's fair enough to say that I wouldn't be a programmer today if it weren't for an interest in game programming, and that is true of several of my friends as well. But if that is true, why then do we have so few finished and polished free software games? Answering that question actually deserves of a post of its own (and indeed, solving that riddle is a good portion of the motive behind Liberated Pixel Cup), but it's enough to say for now that we are missing opportunities of encouraging future hackers by not making free software a welcoming playground for game development.
— Chris Webber(Log in to post comments)
Quotes of the week Posted Jun 28, 2012 15:00 UTC (Thu) by rriggs (subscriber, #11598) [Link]
I think Mr. Pike's surprise is because Go solves a problem with Google's use of C++ that the rest of the world, using modern C++ programming practices, just doesn't have. One need only read Google's C++ programming guidelines to know that coding C++ for the Googleplex is going to be "difficult".
Go does solve a couple important problems for Python programmers -- performance and concurrency. I don't know if attitudes in the Python development community have changed recently, but one of my biggest frustrations as a Python developer in the '00s was "the GIL doesn't matter" attitude that prevailed, and which prevented any forward movement on multi-threaded programming with CPython.
Quotes of the week Posted Jun 29, 2012 8:01 UTC (Fri) by mgedmin (subscriber, #34497) [Link]
I think that attitude was a result of multi-thread scalability being hard, not the reason. When people encounter problems they can't solve, they go into denial.
I still remember when people used to say "anti-aliased fonts are bad for your eyes, so it's good that Linux doesn't support them!" back in the early days of desktop Linux.
Threading and concurrency Posted Jul 2, 2012 15:39 UTC (Mon) by oak (subscriber, #2786) [Link]
> I think that attitude was a result of multi-thread scalability
> being hard, not the reason.
One part of "hard" is that threading support can slow down things for everybody, also people who don't use threads (who most likely are the majority of users of any programming language). And there are also other approaches for solving performance and concurrency issues than threading.
While there are some specific cases where threads fit nicely, people overuse them. I've understood that to be some kind of Windows legacy because on Windows process overhead (at least earlier) was too high and threads got marketed & popularized as a solution for performance issues although the issue they solved was mostly Windows specific?
> When people encounter problems they can't solve, they go into denial.
Or when they need to debug[1] somebody else's threaded code, they may decide that advantages of threading are much over marketed compared to its disadvantages, such as heisenbugs & problems in testing; 100% coverage not being able to flush out race conditions, performance issues from lock contention and additional overhead from locking in general, level of threading support in underlying libraries etc.
What kind of performance issues you have?
Besides using separate processes to implement concurrency, there's Stackless Python which provides micro threads & coroutines. Nowadays there's also PyPy which is supposed to provide many of the same features.
Then there's MP. Eclipse IDE even seems to have separate support for it (OpenMP):
Which might be useful if one wants to write a parallelizing Python module that's (hopefully) safer & easier to maintain than a threaded one.
[1] When people extol on advantages of some feature (like threading) they often forget than they need to be maintained too, and maintaining, for example debugging, requires *good* tools for that specific purpose. What tools there are for debugging threading issues?
I know Valgrind has two tools for detecting data races (Helgrind & DRD), there's mutrace to find out lock contention issues and Gdb naturally can give backtraces to all of the threads, but these are all run-time tools. Even in the best case they can find the problems only if your tests trigger them.
Are there any (good) open source static tools for analyzing threading issues in code?
Quotes of the week Posted Jun 28, 2012 21:18 UTC (Thu) by kjp (subscriber, #39639) [Link]
>>most Go programmers come from languages like Python and Ruby<<
I'm sure that works great with the GO error handling model... hope they're not forgetting to check every close() for an error status.
Quotes of the week Posted Jul 3, 2012 22:31 UTC (Tue) by twm (guest, #67436) [Link]
As a Python programmer, I find Go's lack of exceptions to be one of its many attractive features. You only have to be bitten by an uncaught exception in production so many times to start questioning the whole concept.
Quotes of the week Posted Jul 4, 2012 0:27 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Try writing any non-trivial code in Go and you'll be bitten by ignored error code values.
That's even worse, exceptions are at least visible.
Quotes of the week Posted Jul 4, 2012 4:11 UTC (Wed) by twm (guest, #67436) [Link]
So don't ignore error code return values. You wrote buggy code that doesn't handle errors; it's not like Ruby or Python prevents the same. At the very least, it's a problem you can take measure of via static analysis---try doing that in Python. Worse, many Python library authors don't think that the exceptions a routine can throw are worth documenting! Go's style should at least make writing reliable software possible without try... except Exception blocks around everything. I'll readily admit that my experience with Go is limited to small programs, and I am partially extrapolating from C experience.
Quotes of the week Posted Jul 4, 2012 6:02 UTC (Wed) by raven667 (subscriber, #5198) [Link]
If you are going to check return codes how is that different, other than stylistically from putting try/except blocks around things? You have to do error checking and handling for either case, in the case of exceptions you have a default action (abort) and a detailed message, in the case of return codes your app weaves drunkenly along with incorrect/corrupt data doing bad things.
Quotes of the week Posted Jul 4, 2012 9:28 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Nope.
You DON'T need try..except blocks in correctly designed code. Well, you need them, but mostly on the upper level. The main reason for their use it to free acquired resources in case of exceptional conditions and that can be done well by "with(res):" statements (try-with-resources in Java).
C++ has an even better mechanism - destructors. It has a tremendous advantage over other error handling mechanisms because it unites error handling paths and normal exit paths.
Exception traces Posted Jul 4, 2012 13:09 UTC (Wed) by man_ls (subscriber, #15091) [Link] With exceptions users have a nice stack trace that they can send to the developer. At the uppermost level I just catch the errors to print them nicely along with debug information. When people send me stack traces I can find the error almost instantly.In the Google Play App Store (or however it is called this week) they have taken this idea to the next level: when the user clicks on "inform the developer" Google aggregates the information and shows the traces to the developer. Try doing that with ignored error values...
Exception traces Posted Jul 6, 2012 4:15 UTC (Fri) by twm (guest, #67436) [Link] The concept of a stack trace is not part of the exception error handling model. You can get stack traces in Go too; runtime.Callers looks like a good place to start.
Exception traces Posted Jul 6, 2012 8:05 UTC (Fri) by man_ls (subscriber, #15091) [Link] Well, then I suppose you need both exceptions and stack traces. The idea being that the stack trace is generated automatically by the runtime environment at the point that throws the exception and handled in the catch clause. Without exceptions stack traces have to be generated manually, which is not useful for unexpected error conditions.
Exception traces Posted Jul 11, 2012 6:51 UTC (Wed) by jamesh (guest, #1159) [Link]
Does that help you at the top level if you've called some well behaved Go code that checks and passes up error conditions, and you want to know precisely where the error originated?
Wouldn't an exception + stack trace be easier to debug?
Quotes of the week Posted Jul 4, 2012 20:14 UTC (Wed) by robert_s (subscriber, #42402) [Link]
"So don't ignore error code return values. You wrote buggy code that doesn't handle errors"
So don't not-handle exceptions. Or use an execution environment that can easily recover from such problems. You wrote buggy code that doesn't handle exceptions. Or would you prefer the inner exception-raising function just failed silently? Or segfault?
|
|||||||||||||