luiscubal
|
|
Posted on: September 11, 2010, 10:20:45 am |
|
|
Joined: Jun 2009
Posts: 452
|
Interesting: http://blog.mozilla.com/nnethercote/2010/09/10/another-go-at-language-design/Compile times of Go programs are small. This is because the compiler doesn’t need to know about transitive dependencies between packages (their name for modules). (...) He said with a completely straight face that their goal was to have a 1,000,000x speed-up over C++ for the compilation time of large programs, though they’d probably be satisfied with 100,000x. I'd say that's a pretty ambitious goal for Go engineers... It also makes the advantage of scripting languages(just run instead of first compile then run) much smaller.
|
|
|
Logged
|
|
|
|
|
Josh @ Dreamland
|
|
Reply #2 Posted on: September 12, 2010, 10:22:08 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Wow! Better compile AND load time?! Still, they can't compete with C++'s sourceless residuum of grandeur.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
luiscubal
|
|
Reply #4 Posted on: September 12, 2010, 11:20:10 am |
|
|
Joined: Jun 2009
Posts: 452
|
@RetroX Lol. @Josh Not sure where they claimed better load time, but it is, in theory, actually possible. C++ has lots of features and edge cases which make it hard to optimize(which is why C++ has volatile, const, mutable, alignof, novtable, nothrow, etc. - note that some of these are non-standard). That said, it's possible to make a very efficient language, but I can not assure you that Go is that language.
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #5 Posted on: September 12, 2010, 11:43:10 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Oh, there's definitely room to be improved upon from C++. The language would be ten times better if they dumped most of the old, unneeded parts of the C spec. But to claim that a group of languages sharing on common trait is, in general, faster at compile, load, and run than languages of other groups, is asinine.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
luiscubal
|
|
Reply #6 Posted on: September 12, 2010, 04:19:42 pm |
|
|
Joined: Jun 2009
Posts: 452
|
@Josh If they dropped backwards compatibility, I have absolutely no doubt C++ designers could come up with something better. Unfortunately for newer C++ programmers, backwards compatibility is a critical part of C++'s success. Which is why I think the solution is having languages for older projects be backwards compatible and have incremental updates - like C++ - while investigating for the future.
Even if Java, C#, D, etc. fail(at this point, C# seems to be the one that's doing best, specially considering Oracle vs. Google), they meanwhile provided incredible feedback for the designers of new languages. The future of programming languages looks very interesting, and definitively more interesting than C++.
As an example of Go's simplifications, Go has pointers - but no pointer arithmetic at all! Not only this improves the safety of Go(harder to get segfaults), but it apparently simplifies other parts. On one hand, I have no doubt a C++-like language with this detail would enable the compiler to enable severe optimizations that would otherwise be unreliable. For Go this appears to simplify the GC's design, which in turn I have no doubt will allow the GC to be more efficient than it would otherwise be(and considering the problems of inefficient and buggy GC's...)
|
|
« Last Edit: September 12, 2010, 04:25:14 pm by luiscubal »
|
Logged
|
|
|
|
|
Rusky
|
|
Reply #8 Posted on: September 12, 2010, 05:40:32 pm |
|
|
Joined: Feb 2008
Posts: 954
|
But to claim that a group of languages sharing on common trait is, in general, faster at compile, load, and run than languages of other groups, is asinine. Of course. What I meant, more specifically, was: Better compile time than a C/++-style system with header files, better load time than a scripting language without pre-load processing and better run time than a language with only static optimization. Not better at all three than any one language or group.
|
|
|
Logged
|
|
|
|
luiscubal
|
|
Reply #9 Posted on: September 12, 2010, 05:58:53 pm |
|
|
Joined: Jun 2009
Posts: 452
|
But to claim that a group of languages sharing on common trait is, in general, faster at compile, load, and run than languages of other groups, is asinine. Do note that, when it comes to compile-time paradigm, Go is much closer to C++ than it is to Java or PHP. It is, therefore, fully fair to compare Go to C++, while it would not be fair to compare PHP to C++ (at least when it comes to compilation speed). Go is *NOT* a interpreted, not even JIT compiled. It is AOT, just like C++.
|
|
|
Logged
|
|
|
|
|
|