8 ms·
Go: 90% perfect, 100% of the time
- etenil666 12y agoSell your soul to Google 100% of the time.
- justinsb 12y agoIs this an old presentation? Doesn't Go now start with 8KB stacks per goroutine, which is the same as OS level threads (which physically allocate 8KB from a larger virtual mapping)? I thought the benefits of goroutines were now about more efficient scheduling, not lower memory utilization?
- cnbuff410 12y agoit's latest. Go 1.3 will have a minimum stack size back down at 4 kB. I think they have plan to even trim it down to 1-2 KB in Go 1.4
- 4ad 12y agoGo 1.3 will ship with contiguous stacks that start at 8kB. The original plan was to cut them back at 4kB, but it was not feasible ritgh now (while maintaing performance). It will probably be reduced in the future.
- 4ad 12y agoNo, threads don't use 8kB stacks, they use 2-8MB stacks. A particular point of goroutines is that they use less address space than threads. Both goroutines and threads use roughly the same amount of physical memory.
- lmm 12y agoYet another piece of Go advocacy from someone who seems to have never heard of any modern functional languages. If the only alternatives were perl/python/ruby/javascript/java/C then Go would probably be a good choice for some problems. But what about OCaml, F#, Haskell or Scala?
- xyproto 12y agoHe mentions both Haskell and C#, but I agree with your overall point. Nimrod, Rust, D, C++11 and Julia are also missing from the comparison. (and more)
- VeejayRampay 12y agoWell, I understand your point, but there's a limit to how much namedropping you can do in one article. There are hundreds of programming languages, each with their own little niche of enthusiasts ready to get outraged that their raison de vivre language hasn't been mentioned. The fact that Nimrod, D or Julia weren't mentioned isn't necessarily relevant in the overall estimation of the quality of the contents of the article.
- NateDad 12y agoRust is not a stable language, so no long running project can safely use it. Is Julia a stable language with backwards compatibility? It's v0.2.1 right now, which doesn't fill me with confidence. He mentions C++, pretty sure he knows about C++11. And yeah, you can only drop so many names.
- cnbuff410 12y agoA lot of FP people tend to think people don't use FP are those who have "never heard of any modern functional languages". I don't know where does this kind of arrogance come from. Sure, functional language can be used in almost all the programming related projects. But are they really a good fit or not is not decided by FP advocacy, but the people who actually tackle these problems. Go for now shines in a pretty niche market, it is extremely good fit for this niche market, and this fact is not advocated by Go fans or Go team, but by large amount of open source projects and emerging usage in quite a few serious companies/startups. You can certainly go ahead and ask them "Why not use OCaml, F#, Haskell or Scala", or you can use FP to make a better project in this field to show people FP is indeed much better fit. To some of us, programming language is merely a tool to solve a problem, not to show off the shining design concept. For us, Go hits a incredibly sweet point on the balance of coding efficiency and running efficiency. Note that, coding efficiency has nothing to do with "how beautiful and elegant this code snippet is", it has everything to do with "if this project is easy to read, easy to maintain and easy to expand"
- afandian 12y agoIs there a way to disable slide transitions? It's very difficult to navigate with all that movement.
- anentropic 12y agoDoes anyone have the numbers to go with the claim that Perl is faster than Python?
- Kototama 12y agoMaybe here http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=python3&lang2=perl&data=u32 http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... But basically they seem to be both in the same category.
- SwellJoe 12y agoFor fun, many years ago, I did a series of benchmarks of ack vs grin (both are programmers greps, one in Perl the other in Python, and both were written and maintained by excellent developers well-known in their respective languages). Because the tools do almost identical work, and can be configured to behave nearly identically, in terms of enabled features, types of searching to do, etc. I believe it's a useful real world performance test. At the time, ack (in Perl) ran in roughly a tenth the time of grin (in Python) on most tests. Similarly, find+grep with the right options (and occasionally run through sed or awk to get further refined results) was approximately an order of magnitude faster than ack (but was much harder to use, and so ack or grin were still preferable tools). It would likely be useful to repeat the experiment with modern Perl and Python versions. Both have improved and likely have better performance. It seems likely Python will have closed the performance gap some in the ensuing years. It's also worth keeping in mind that this may be a sweet spot for Perl, given its genesis as a language processing language. And, it may be a tough one for Python given its historic aversion to regular expressions as a common solution to problems. So, saying Perl is (or was) ten times faster for this class of problem may simply mean this is a problem that Perl is particularly good at, and may not cover other classes of problem. I'm suspicious of microbenchmarks, though enough microbenchmarks can give some sort of indication of what larger programs will do. But, they may also be indicative of the quality of the programmer contributing solutions...a better algorithm implementation can often erase language differences. Which is why I liked comparing two nearly identical programs, both by known excellent developers and not doing anything particularly prone to algorithmic complexity, as a means of testing language performance. I imagine one could find other examples that would be good to compare. scons and cons, perhaps, would be another decent choice, assuming cons is still actively maintained.
- higherpurpose 12y agoStill no talk about Go for Android, then.
- lazyjones 12y agoWhat Go really lacks right now for oldtimers like me: NOT generics, but a good single-step debugger. We've had these almost 30 years ago built into our awesome Assembler (Devpac ST anyone?), C, Pascal etc. IDEs. Go is still lacking even proper gdb support and IDEs build on this shaky foundation. Why?
- 4ad 12y agoBecause the people who need it most don't actually need it that much, otherwise they would have written it. When I debug most Go programs, I'm doing high-level debugging. A debugger is a sharp tool. For 90% of my debugging task I don't need scalpels, I need tools that can provide a holistic view of a system from above. I use DTrace for that. When I actually use a debugger, it's low-level work; I either debug the runtime or the compiler and I use assembly. Mdb/gdb/acid is perfectly adequate for that. A debugger with special Go support is of no use to me. That being said, a Go debugger is on the table. Yes, on the Internet everyone wants everything, generics, IDE, higher order metaprogramming, etc. In the end, people who actually implement any tool, feature, or process are doing it only because it helps their concrete work in a very practical way. Yes, a debugger would be useful, but almost anything is useful in isolation. So far, the people who do the work didn't write a debugger, because even if it might have been useful to some, it would have been a net loss for their particular problem they were solving at that particular time, because of the additional effort. I'm writing the arm64 compiler. I wrote a CPU simulator and a debugger. It's a very low-level tool and very useful to me at this particular stage in the port. Even though it took time to write it, it saves time overall. It's useless for 99.99% of other Go programmers.
- frobware 12y agoPlease could you elaborate on the arm64 compiler. Is there a repo somewhere, etc?
- 4ad 12y agoNo sorry, the work is relatively too early for that yet. Significant progress has been made, but a lot is still to be done. The Plan 9 C compiler included with Go works well but the Go compiler not yet. I'm pushing for inclusion in 1.4.
- enscr 12y agoProbably worth knowing that the author 'Brad Fitzpatrick' is part of the Go language team http://golang.org/CONTRIBUTORS http://golang.org/CONTRIBUTORS
- lazyjones 12y agoHe is also the author of memcached and Livejournal.
- diminish 12y ago> pure Go AES => slower, but safer Just curious, why Go AES is safer than OpenSSL or GnuTLS, anyone? Or safer here means something other than secure?
- 4ad 12y agoBecause Go is a memory-safe language (unlike C), therefore a large class of bugs that have plagued OpenSSL are avoided. That being said, the AES implementation uses fast assembly code, if possible, so some safety is lost. In any case, TLS would have provided a better example, AES is much easier to audit for correctness than TLS.
- drdaeman 12y agoI don't really understand crypto, but I suspect while adding memory safety high level primitives without any guarantees about their low-level behavior could lead to various side-channel attacks. When implementing AES some had to resort to SIMD assembly instructions[1] instead of plain C to avoid timing attacks. [1]: http://crypto.stanford.edu/vpaes/ http://crypto.stanford.edu/vpaes/
- 4ad 12y agoYes, and the Go implementation takes all this into consideration (whether it does a good enough job is not decided yet). The timing behaviour of the compiled Go code is very well understood, and it is (or can be made) very similar to the behaviour for C. When this is not enough, assembly is used. Please see http://golang.org/pkg/crypto/subtle http://golang.org/pkg/crypto/subtle.
- drdaeman 12y ago> all this It certainly does, but is it really all of this? For example, I had read that AES has a timing attack[1] due to non-constant time array access due to CPU caches being significantly faster that RAM. I don't see `ConstantTimeArrayAccess` there. And when you have to fall back to assembly (like Go does for x86_64[2]), grandparent posts' argument for high-level languages as a less error prone is getting weaker (although it still stands true, as attack surface is shallower) [1]: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf http://cr.yp.to/antiforgery/cachetiming-20050414.pdf [2]: http://golang.org/src/pkg/crypto/aes/asm_amd64.s http://golang.org/src/pkg/crypto/aes/asm_amd64.s
- signa11 12y agoit is kind of interesting to see godrone.io being mentioned here, where the f/w for the parrot drone is in go. for comparison with erlang, here it is being demoed with in-flight hot-code-reload :) http://www.erlang-embedded.com/2013/10/minimal-downtime-in-flight-drone-firmware-upgrade-in-erlang/ http://www.erlang-embedded.com/2013/10/minimal-downtime-in-f...
- kitsune_ 12y agoI've created a couple of projects in Go so far (a map server, similar to TileStache etc.) - Sure, the lack of generics is annoying, but I think the real elephant in the room is dependency and package management. The way Go expects you to organize your source code (the workspace concept, GOPATH, go get and github-repos as import paths) is a huge road block here. To this day the Go community hasn't settled on any kind of solution. If you bring any of this up on the mailing list you'll be crucified by the Go zealots who think Go's way of doing things is a thing of immaculate perfection. If you want to be safe you will have to version your dependencies with your project. So one way to achieve this is to put your entire GOPATH src folder into your project repository. Of course this defeats the purpose of resolving "github.com/myname/myproject" with "go get". Or, more annoying still, you'll put them into a /vendor/ folder inside your package folder and rewrite all the import paths. So "github.com/myname/myproject/vendor/somepackage". Of course, if you simply rely on "go get" then dependency hell is just around the corner when it comes to transient dependencies. A -> C-v1 and A -> B -> C-v1.1. In fact if the entire Go eco-system relied on "go get" there would be no guarantee that a library worked - upstream dependencies could change at any moment.
- matthewmacleod 12y agoThe way Go expects you to organize your source code (the workspace concept, GOPATH, go get and github-repos as import paths) is a huge road block here. To this day the Go community hasn't settled on any kind of solution. This has been a major roadblock for me. I've worked with a whole bunch of different languages, and this drives me completely nuts.
- nshepperd 12y agoAn alternative opinion: http://www.quora.com/Go-programming-language/Do-you-feel-that-golang-is-ugly?share=1 http://www.quora.com/Go-programming-language/Do-you-feel-tha... Go's lack of generics kills it for me, as I've learned trying to implement a persistent collection type recently. Without any concept of parameterised types (Foo<A>), programmer defined container types are second class citizens. Casting things to (interface{}) and back everywhere gets old quickly, and you get no static type safety. So in that domain it's essentially back to the C way of doing things, with (void*) everywhere.
- NateDad 12y agoSorry, I won't click on Quora links... post to a non-terrible Q&A site that doesn't hide stuff behind registration pages.
- spystath 12y agoIn slide #28 it is claimed that Go is as fast as Java. I don't use Java extensively but I always had the impression that was quite performant with the highly tuned HotSpot and all even more so than Go. Are there any comparative benchmarks between Go and Java for similar-ish tasks? I get it that Go probably handles concurrency in a more elegant way but I have some doubts regarding raw performance. I am talking about the standard compiler implementation, not gccgo.
- NateDad 12y agohttp://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=java&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... Go is pretty close to java's speed. Generally slower, but not by a lot.
- NateDad 12y agoOh yeah, Java's garbage collector is a lot better than Go's, though Go's is improving. That being said, it's way easier to simply not create garbage in Go than it is in Java, so you can avoid the garbage collector entirely.
- igouy 12y agoslide #6 "Fake, fun numbers"