> > For a large system where you simply can't spend all time tuning an inner > loop to oblivion, this may end up with the Go program being faster than the > C++ program.
Building C++ programs depends a lot on how the program is structured and how complex it is. I usually run a batch of tests for every piece of code I have, and building the binaries is usually very fast. Also, I think there is a lot of misconception on what C++ is today. Yes, it is a complicated language with lots of details, but that doesn't mean one has to know everything there is to know about the language. By today's standards, C++ code can be immensely simplified if a developer uses the STL and focus on developing standard code. Can someone learn to program in Go faster than C++? Sure, I believe that. Go has a great syntax from what I already seen and has a very complete set of tools by default. Does it take too long to optimise a C++ code in order to be faster than Go code? I doubt it. It's not that hard if the STL is used and if the developer knows what he is doing from the beginning. Still, Go uses Garbage Collecting for memory management, which is something I don't like from the Java world. For me, the idea of "leave it for tomorrow" when freeing memory, is I a lazy approach for memory management. On 24 October 2016 at 14:43, Jesper Louis Andersen < jesper.louis.ander...@gmail.com> wrote: > > On Mon, Oct 24, 2016 at 11:51 AM Haddock <ffm2...@web.de> wrote: > > >> Just to be precise: Go has currently performance near Java, see >> http://benchmarksgame.alioth.debian.org/u64q/go.html Nevertheless, that >> is still 3x-15x faster than Python ;-), see http://benchmarksgame.alioth. >> debian.org/u64q/python.html >> >> > Beware of putting too much into a benchmark suite where > > * There is no upper bound on implementation time > * The fastest solutions all look like C code > * The problems presented are synthetic > * The programs to implement are VERY amenable to a typical C solution > > The efficiency of a large system is a property of its architecture, not > its individual parts. And it is bounded by available time. It wouldn't > surprise me if typical Go programs can be written in a fraction of the time > it takes to build C++ programs and thus you have more time to actually tune > the result. For a large system where you simply can't spend all time tuning > an inner loop to oblivion, this may end up with the Go program being faster > than the C++ program. > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/golang-nuts/LpXoEAj1Jzs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
