7 ms·

That's interesting. I had the opposite reaction regarding Golang capabilities while following this saga. Not sure how 'idiomatic' the Golang code is, at first g

by npalli 13y ago

That's interesting. I had the opposite reaction regarding Golang capabilities while following this saga. Not sure how 'idiomatic' the Golang code is, at first glance it just seems less expressive (more lines of code) than either c++ or java!. I didn't think that was possible. So whenever people talk about expressiveness of Golang it just seems like a design gone bad. The designers wanted a programming language with the expressiveness of python and the speed of C, they ended up with a language with the expressiveness of C and the speed of python.

pbsd 13y ago
I agree, I honestly don't see where the expressiveness claims of Go come from. I've always put it in the Java-like bin of languages (which is not necessarily a bad thing). I suppose the one thing that Go does well (compared to C++ or Java) is builtin concurrency and communication across tasks.
- RamiK 13y ago
  Brevity and expressiveness are not the same.
  - yohanatan 13y ago
    Are you sure about that? Given that any [Turing-complete] language feature can be implemented in any other [Turing-complete] language, the only conceivable difference is in fact length of implementation. In other words, it is possible to express anything in one Turing-complete language that is possible to express in another.
    - cgag 13y ago
      To me, expressiveness is about expressing an idea with as little incidental complexity as possible, which is definitely different from as in as few characters as possible.
      - yohanatan 13y ago
        I don't think it is different actually. 'Kolmogorov complexity' (which is essentially the global minimum 'essential complexity' of a particular algorithm) is specified in terms of length.
        fauigerzigerk 13y ago
        Applying Kolmogorov complexity in this context is a bit more tricky than you make it appear. Kolmogorov complexity measures the complexity of a string as the length of the shortest possible program that generates that string. So to measure the complexity of a program P we have to write another program G that generates P and then take G's length. It's not a given that a generator for a verbose language is necessarily longer than a generator for a terse language. But more importantly, what we want to measure is the mental effort required to write and understand code in different languages. To measure that effort in terms of Kolmogorov complexity, we'd have to write a program that generates our states of mind while programming. Good luck with that ;-)
        yohanatan 13y ago
        Actually, given a Turing Machine M which outputs x when given x, then we would have the description of program T0 (for terse language T) equal to the concatenation of the [specification of the] machine M with T0, M T0. Given program J1 (for verbose language J), its description equals M J1. Given sufficiently small M and large T0, the M factor's importance is quite reduced and we see that Kolmogorov complexity is roughly analogous to the respective sizes of T0 and J1 themselves (for this specific Turing Machine M).
        fauigerzigerk 13y ago
        You're forgetting that Kolmogorov complexity is the shortest possible description, not just any description of the desired output. The concatenation you're suggesting is highly unlikely to be the shortest possible one. You have to think of it in terms of compression, because that's what Kolmogorov complexity is really about. It is certainly possible that after compression J1 is shorter than T0.
    - hetman 13y ago
      Except my brain isn't a Turing machine. What expressiveness means then is how easily I can fit the concepts of the code in my head (not on my harddrive). This is not the same as how short the code is, though the two are often closely related.
      - yohanatan 13y ago
        Expressiveness is power and it applies to the act of writing code, not reading it. I agree that it is ideal if one's code can be read and comprehended easily by others although that has little to do with expressiveness. http://www.paulgraham.com/power.html http://www.paulgraham.com/power.html
    - cmccabe 13y ago
      Are you sure about that? Yes.
      - yohanatan 13y ago
        You can be sure if you want but unless you back up your claim with some reasoning, others will consider you wrong.
        cmccabe 13y ago
        "Brevity and expressiveness are not the same." "Are you sure about that?" "Yes." Do I need to explain?
        yohanatan 13y ago
        I think you're confusing expressiveness of the language with expressiveness of a particular text written in that language. English certainly affords you the opportunity to share more thoughts but given that you seemingly only wanted to express an affirmative, in English 'yes' is pretty much the minimum. You could have said 'Ya' but that is slang. If you open up the choice of language then you could have said 'si', or '#t' or even just '1'. But with such a short intended message, language choice hardly matters. Certainly if you intended to say more than 'yes' then you failed at adequately expressing the message to begin with so comparisons at that point are moot: i.e., two pieces of text must both express precisely the same ideas before comparisons of them make sense.
        CCs 13y ago
        A line from a real code (a library): "* ^^"._? #> (a.!?(1, Get())) must be_==(Full(Answer(1))) ?~! eventually It is very short, most of the people would implement the same thing using 5-10 lines of code. I prefer 5-10 lines of code over regex-like syntax.
        cmccabe 13y ago
        A more obvious example is minified JS versus regular JS. Briefer? Definitely. More expressive? Definitely not.
    - kvb 13y ago
      See Felleisen's "On the Expressive Power of Programming Languages"[1] for one formalization that differs from conciseness. Essentially, Turing complete languages can express the same programs at the very coarse "whole program" level, but the paper advocates taking a more local view to assess expressiveness (e.g. what programs in L1 can you write in L2 without having to do a whole program transformation). See also Neal Gafter's related commentary[2] (in the context of the various proposals for closures in Java). [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4656 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4... [2] http://gafter.blogspot.com/2007/03/on-expressive-power-of-programming.html http://gafter.blogspot.com/2007/03/on-expressive-power-of-pr...
      - yohanatan 13y ago
        One doesn't have to look far before he finds a fatal flaw in the commentary. Particularly this: "In my mind, a language construct is expressive if it enables you to write (and use) an API that can't be written (and used) without the construct." - Neil Gafter Once more, there is no such construct. All APIs can be written and consumed without language support. Otherwise, Boost would not have had all the new C++ goodies (as an add-on library) before they became part of the language itself. And, of course, one can always put the 'human compiler' to work to produce boilerplate that would be produced by the compiler if the language in question supported the feature in question (if there isn't an add-on library providing the feature in question). One can always do this but the discriminating one tries to avoid it and instead chooses 'expressive' (i.e., conciseness-facilitating) languages. [In the case of closures in Java, one [human-compiler] would merely use one-off interfaces or anonymous classes]. I will take a look at the other links but I gave up on the commentary after seeing such a blatant falsehood.
        kvb 13y ago
        C++ has features like operator overloading that make faking lambdas via Boost feasible. And even Java has anonymous inner classes that allow a rather ugly local transformation somewhat akin to closures. But if you removed that feature, then you'd need a non-local transformation to fake them.
- tptacek 13y ago
  My first impression of it was that it was like a cross between Java and Python. It is unmistakably similar to Java conceptually and syntactically; they are sibling languages, both designed to streamline, simplify, or modernize C. I'm a Java-literate C/C++ programmer. I would avoid writing straight Java code at all costs; I find it immiserating. Here are some reasons off the top of my head that Golang is more pleasant to work in: * The syntax is deliberately streamlined, including implicit declarations, semicolon insertion, lightweight expression syntax, the capital-letter-exports-a-symbol thing * It has fully functional idiomatic closures * Interfaces get rid of adapter class BS * The table type (maps, in Golang) is baked into the language, like Python, not a library, like C++ and Java * Clearer, more direct control over memory layout; data structures in Golang feel like C I don't know if Golang's standard library is that much better than Java's, but it was obviously designed carefully by and for systems programmers, so I find it remarkably easy to work with. It also feels like a much smaller system than Java. Almost every time I write a significant amount of Golang code, I find myself answering questions by just reading the standard library source code. It's easy to get your head around. I've written compiler/runtime-level code for the JVM and I still don't have a great grip on all of Java.
  - georgemcbay 13y ago
    I agree with all of the above and I write Java code for a living currently (Android/Dalvik though, not for the JVM). Another cool aspect of the last point (Go being small and lightweight) is that if you've got gcc and mercurial on a supported platform, building latest go from source is as easy as: hg clone http://code.google.com/p.go http://code.google.com/p.go cd go/src ./make.bash Got to build a local copy of the JVM and/or JDK for some reason? Good luck with that (even ignoring all the licensing, OpenJDK vs closed, etc)
  - lmm 13y ago
    Have you compared it with ML or Haskell?
myg204 13y ago
A lot of the verbosity in Go comes from error handling; the language forces you to deal with errors (I think it's a good thing, some may disagree). Expressiveness is real, 'duck typing' does give it a feel of scripting language like Python, and it is way less verbose than Java (apart from error handling). And to be fair, Go is faster than Python (the numbers tell you that), and (slightly?) more expressive than C --and just in a league of its own for concurrency.
- azth 13y ago
  > and just in a league of its own for concurrency. Not really. Other languages are far superior in this regard (see Scala or Rust for instance).
kkowalczyk 13y ago
You're empirically wrong. I actually did write a fair amount of Go code (my primary languages are C++ and Python). On real, non-toy programs it is significantly more concise than C++, in the ballpark of Python code. This isn't visible on code snippets (less than 500 loc) like the toy raytracer, but trust me: you'll see a big difference on 10k loc codebase.
- npalli 13y ago
  Without knowing what your program did, it is hard to see what language features caused the difference. In any case, why was Java not a better option than Golang?
  - TylerE 13y ago
    Go outputs a statically linked binary that just RUNS. Java needs a quite heavyweight runtime to be installed, that imposes quite a bit of startup overhead. That's just one reason - for short runtime CLI-type utilities it's not in the same ballpark.
    - npalli 13y ago
      Ok, so lets go with your use case. You can run basic java ("hello world") under 3MB with a startup time of about 0.1 second. So that is the true overhead if you really care about tight code. The default values are pretty large. Everything else (memory/startup) is added due to external libraries that are needed and additional memory as the program grows. Given that "kkowalczyk" talked about 10K line programs, what applications are you thinking of that are 10K lines and cannot tolerate a 0.1 second/3 MB overhead. Would you restart java everytime? Note that even a simple helloworld c program has about 0.01second/0.5MB overhead.
      - m0th87 13y ago
        I was going to say there's no way java programs boot in 0.1 seconds, but looked it up to be sure. Here's the results on my mac/i7, defaulted to server mode: $ time java HelloWorld Hello, world! real 0m0.101s Touche. 0.1 seconds is exactly right, at least on my setup. That said, javac is slow given the program is 5 lines of code: $ time javac HelloWorld.java real 0m0.511s user 0m0.833s sys 0m0.050s And I'd ventured to guess that there must be something to the JIT being pretty slow for real-world applications, otherwise people wouldn't complain so frequently about it. Maybe aspects of JIT optimizations increase linearly-ish with the amount/complexity of code? FWIW, we went with go at my work instead of java because our application is memory-intensive, and there's huge gains there in go over java.
nly 13y ago
I think the reason both versions lack conciseness is because they're faithful translations of one another. I wouldn't call either well structured, but maybe that's because I don't understand the problem domain well enough. T() in the C++ versions especially looks awful.
corresation 13y ago
To concur with what kkowalczyk, there is little expressiveness advantages to be gained for this specific example -- math is math, and outside of compressing it down to a couple of library calls, what could possibly be done better? "they ended up with a language with the expressiveness of C and the speed of python." This is just pure troll. Apparently you have a Python variant of this renderer that matches the already impressive Go performance? Please reveal it.
cgag 13y ago
I'm not sure if it's because the JVM has a bad rep or people like the familiar feeling of Go (smaller learning curve) or some other reason, but it surprises me so many people jump to Go for performance similar to what you'd get on a modern JVM language (Clojure, Scala), but with less expressiveness, fewer libraries, and (I believe) less tooling. Of course this only really applies to long running apps (web servers), if startup time matters then certainly Go wins. Perhaps I need to try Go out, but I just don't see what the selling point is.
- azth 13y ago
  > but it surprises me so many people jump to Go for performance similar to what you'd get on a modern JVM language In a word: hype. If Go did not have the Google brand name attached to it, it wouldn't have gone anywhere.
- fauigerzigerk 13y ago
  People are trying to get as much space as possible between themselves and the Java community's culture of complexity. I don't think it's a technology issue.
  - adamc 13y ago
    "the Java community's culture of complexity" -- great evocative phrase.
    - pjmlp 13y ago
      s/Java/Enterprise/g

by npalli 13y ago

pbsd 13y ago

I agree, I honestly don't see where the expressiveness claims of Go come from. I've always put it in the Java-like bin of languages (which is not necessarily a bad thing). I suppose the one thing that Go does well (compared to C++ or Java) is builtin concurrency and communication across tasks.

RamiK 13y ago
Brevity and expressiveness are not the same.
- yohanatan 13y ago
  Are you sure about that? Given that any [Turing-complete] language feature can be implemented in any other [Turing-complete] language, the only conceivable difference is in fact length of implementation. In other words, it is possible to express anything in one Turing-complete language that is possible to express in another.
  - cgag 13y ago
    To me, expressiveness is about expressing an idea with as little incidental complexity as possible, which is definitely different from as in as few characters as possible.
    - yohanatan 13y ago
      I don't think it is different actually. 'Kolmogorov complexity' (which is essentially the global minimum 'essential complexity' of a particular algorithm) is specified in terms of length.
      - fauigerzigerk 13y ago
        Applying Kolmogorov complexity in this context is a bit more tricky than you make it appear. Kolmogorov complexity measures the complexity of a string as the length of the shortest possible program that generates that string. So to measure the complexity of a program P we have to write another program G that generates P and then take G's length. It's not a given that a generator for a verbose language is necessarily longer than a generator for a terse language. But more importantly, what we want to measure is the mental effort required to write and understand code in different languages. To measure that effort in terms of Kolmogorov complexity, we'd have to write a program that generates our states of mind while programming. Good luck with that ;-)
        yohanatan 13y ago
        Actually, given a Turing Machine M which outputs x when given x, then we would have the description of program T0 (for terse language T) equal to the concatenation of the [specification of the] machine M with T0, M T0. Given program J1 (for verbose language J), its description equals M J1. Given sufficiently small M and large T0, the M factor's importance is quite reduced and we see that Kolmogorov complexity is roughly analogous to the respective sizes of T0 and J1 themselves (for this specific Turing Machine M).
        fauigerzigerk 13y ago
        You're forgetting that Kolmogorov complexity is the shortest possible description, not just any description of the desired output. The concatenation you're suggesting is highly unlikely to be the shortest possible one. You have to think of it in terms of compression, because that's what Kolmogorov complexity is really about. It is certainly possible that after compression J1 is shorter than T0.
  - hetman 13y ago
    Except my brain isn't a Turing machine. What expressiveness means then is how easily I can fit the concepts of the code in my head (not on my harddrive). This is not the same as how short the code is, though the two are often closely related.
    - yohanatan 13y ago
      Expressiveness is power and it applies to the act of writing code, not reading it. I agree that it is ideal if one's code can be read and comprehended easily by others although that has little to do with expressiveness. http://www.paulgraham.com/power.html http://www.paulgraham.com/power.html
  - cmccabe 13y ago
    Are you sure about that? Yes.
    - yohanatan 13y ago
      You can be sure if you want but unless you back up your claim with some reasoning, others will consider you wrong.
      - cmccabe 13y ago
        "Brevity and expressiveness are not the same." "Are you sure about that?" "Yes." Do I need to explain?
        yohanatan 13y ago
        I think you're confusing expressiveness of the language with expressiveness of a particular text written in that language. English certainly affords you the opportunity to share more thoughts but given that you seemingly only wanted to express an affirmative, in English 'yes' is pretty much the minimum. You could have said 'Ya' but that is slang. If you open up the choice of language then you could have said 'si', or '#t' or even just '1'. But with such a short intended message, language choice hardly matters. Certainly if you intended to say more than 'yes' then you failed at adequately expressing the message to begin with so comparisons at that point are moot: i.e., two pieces of text must both express precisely the same ideas before comparisons of them make sense.
      - CCs 13y ago
        A line from a real code (a library): "* ^^"._? #> (a.!?(1, Get())) must be_==(Full(Answer(1))) ?~! eventually It is very short, most of the people would implement the same thing using 5-10 lines of code. I prefer 5-10 lines of code over regex-like syntax.
        cmccabe 13y ago
        A more obvious example is minified JS versus regular JS. Briefer? Definitely. More expressive? Definitely not.
  - kvb 13y ago
    See Felleisen's "On the Expressive Power of Programming Languages"[1] for one formalization that differs from conciseness. Essentially, Turing complete languages can express the same programs at the very coarse "whole program" level, but the paper advocates taking a more local view to assess expressiveness (e.g. what programs in L1 can you write in L2 without having to do a whole program transformation). See also Neal Gafter's related commentary[2] (in the context of the various proposals for closures in Java). [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4656 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4... [2] http://gafter.blogspot.com/2007/03/on-expressive-power-of-programming.html http://gafter.blogspot.com/2007/03/on-expressive-power-of-pr...
    - yohanatan 13y ago
      One doesn't have to look far before he finds a fatal flaw in the commentary. Particularly this: "In my mind, a language construct is expressive if it enables you to write (and use) an API that can't be written (and used) without the construct." - Neil Gafter Once more, there is no such construct. All APIs can be written and consumed without language support. Otherwise, Boost would not have had all the new C++ goodies (as an add-on library) before they became part of the language itself. And, of course, one can always put the 'human compiler' to work to produce boilerplate that would be produced by the compiler if the language in question supported the feature in question (if there isn't an add-on library providing the feature in question). One can always do this but the discriminating one tries to avoid it and instead chooses 'expressive' (i.e., conciseness-facilitating) languages. [In the case of closures in Java, one [human-compiler] would merely use one-off interfaces or anonymous classes]. I will take a look at the other links but I gave up on the commentary after seeing such a blatant falsehood.
      - kvb 13y ago
        C++ has features like operator overloading that make faking lambdas via Boost feasible. And even Java has anonymous inner classes that allow a rather ugly local transformation somewhat akin to closures. But if you removed that feature, then you'd need a non-local transformation to fake them.
tptacek 13y ago
My first impression of it was that it was like a cross between Java and Python. It is unmistakably similar to Java conceptually and syntactically; they are sibling languages, both designed to streamline, simplify, or modernize C. I'm a Java-literate C/C++ programmer. I would avoid writing straight Java code at all costs; I find it immiserating. Here are some reasons off the top of my head that Golang is more pleasant to work in: * The syntax is deliberately streamlined, including implicit declarations, semicolon insertion, lightweight expression syntax, the capital-letter-exports-a-symbol thing * It has fully functional idiomatic closures * Interfaces get rid of adapter class BS * The table type (maps, in Golang) is baked into the language, like Python, not a library, like C++ and Java * Clearer, more direct control over memory layout; data structures in Golang feel like C I don't know if Golang's standard library is that much better than Java's, but it was obviously designed carefully by and for systems programmers, so I find it remarkably easy to work with. It also feels like a much smaller system than Java. Almost every time I write a significant amount of Golang code, I find myself answering questions by just reading the standard library source code. It's easy to get your head around. I've written compiler/runtime-level code for the JVM and I still don't have a great grip on all of Java.
- georgemcbay 13y ago
  I agree with all of the above and I write Java code for a living currently (Android/Dalvik though, not for the JVM). Another cool aspect of the last point (Go being small and lightweight) is that if you've got gcc and mercurial on a supported platform, building latest go from source is as easy as: hg clone http://code.google.com/p.go http://code.google.com/p.go cd go/src ./make.bash Got to build a local copy of the JVM and/or JDK for some reason? Good luck with that (even ignoring all the licensing, OpenJDK vs closed, etc)
- lmm 13y ago
  Have you compared it with ML or Haskell?

myg204 13y ago

A lot of the verbosity in Go comes from error handling; the language forces you to deal with errors (I think it's a good thing, some may disagree). Expressiveness is real, 'duck typing' does give it a feel of scripting language like Python, and it is way less verbose than Java (apart from error handling). And to be fair, Go is faster than Python (the numbers tell you that), and (slightly?) more expressive than C --and just in a league of its own for concurrency.

azth 13y ago
> and just in a league of its own for concurrency. Not really. Other languages are far superior in this regard (see Scala or Rust for instance).

kkowalczyk 13y ago

You're empirically wrong. I actually did write a fair amount of Go code (my primary languages are C++ and Python). On real, non-toy programs it is significantly more concise than C++, in the ballpark of Python code. This isn't visible on code snippets (less than 500 loc) like the toy raytracer, but trust me: you'll see a big difference on 10k loc codebase.

npalli 13y ago
Without knowing what your program did, it is hard to see what language features caused the difference. In any case, why was Java not a better option than Golang?
- TylerE 13y ago
  Go outputs a statically linked binary that just RUNS. Java needs a quite heavyweight runtime to be installed, that imposes quite a bit of startup overhead. That's just one reason - for short runtime CLI-type utilities it's not in the same ballpark.
  - npalli 13y ago
    Ok, so lets go with your use case. You can run basic java ("hello world") under 3MB with a startup time of about 0.1 second. So that is the true overhead if you really care about tight code. The default values are pretty large. Everything else (memory/startup) is added due to external libraries that are needed and additional memory as the program grows. Given that "kkowalczyk" talked about 10K line programs, what applications are you thinking of that are 10K lines and cannot tolerate a 0.1 second/3 MB overhead. Would you restart java everytime? Note that even a simple helloworld c program has about 0.01second/0.5MB overhead.
    - m0th87 13y ago
      I was going to say there's no way java programs boot in 0.1 seconds, but looked it up to be sure. Here's the results on my mac/i7, defaulted to server mode: $ time java HelloWorld Hello, world! real 0m0.101s Touche. 0.1 seconds is exactly right, at least on my setup. That said, javac is slow given the program is 5 lines of code: $ time javac HelloWorld.java real 0m0.511s user 0m0.833s sys 0m0.050s And I'd ventured to guess that there must be something to the JIT being pretty slow for real-world applications, otherwise people wouldn't complain so frequently about it. Maybe aspects of JIT optimizations increase linearly-ish with the amount/complexity of code? FWIW, we went with go at my work instead of java because our application is memory-intensive, and there's huge gains there in go over java.

nly 13y ago

I think the reason both versions lack conciseness is because they're faithful translations of one another. I wouldn't call either well structured, but maybe that's because I don't understand the problem domain well enough. T() in the C++ versions especially looks awful.

corresation 13y ago

To concur with what kkowalczyk, there is little expressiveness advantages to be gained for this specific example -- math is math, and outside of compressing it down to a couple of library calls, what could possibly be done better? "they ended up with a language with the expressiveness of C and the speed of python." This is just pure troll. Apparently you have a Python variant of this renderer that matches the already impressive Go performance? Please reveal it.

cgag 13y ago

I'm not sure if it's because the JVM has a bad rep or people like the familiar feeling of Go (smaller learning curve) or some other reason, but it surprises me so many people jump to Go for performance similar to what you'd get on a modern JVM language (Clojure, Scala), but with less expressiveness, fewer libraries, and (I believe) less tooling. Of course this only really applies to long running apps (web servers), if startup time matters then certainly Go wins. Perhaps I need to try Go out, but I just don't see what the selling point is.

azth 13y ago
> but it surprises me so many people jump to Go for performance similar to what you'd get on a modern JVM language In a word: hype. If Go did not have the Google brand name attached to it, it wouldn't have gone anywhere.
fauigerzigerk 13y ago
People are trying to get as much space as possible between themselves and the Java community's culture of complexity. I don't think it's a technology issue.
- adamc 13y ago
  "the Java community's culture of complexity" -- great evocative phrase.
  - pjmlp 13y ago
    s/Java/Enterprise/g