8 ms·

> The code you write with Go just seems to be correct. I can’t really put my finger on it, but somehow once the code compiled (and it compiles QUICKLY), you jus

by wting 13y ago

> The code you write with Go just seems to be correct. I can’t really put my finger on it, but somehow once the code compiled (and it compiles QUICKLY), you just get the feeling that it’ll work (not just run without error, but even logically be correct). I know, that sounds very wishy-washy, but it’s true. This statement needs to be qualified. Switching from an interpreted to a static language will catch a certain class of bugs upfront. I've rewritten some small programs from C to Go, and the same logic bugs are present in both. In this sense, switching to Go is no different than switching to Java/C in terms of the bugs it will catch. There's nothing in Go that sets it apart from other static languages in this respect (unlike Haskell). > It’s very similar to Python in terms of verbosity (or lack thereof) and it treats functions as first-class objects, so functional programming is easy to reason about. Where is map, reduce/fold, filter, scan? Go doesn't support functional programming primitives due to lack of generics. I may not have written enough Go programs, but I find Go marginally less verbose than C thus far (ignoring concurrency). Channels and goroutines and are its most interesting features.

jdiez17 13y ago
You can actually do functional programming in Go. Lack of generics just means you have to think harder. In fact, a friend of mine did a Go library to write functional-style code: https://github.com/tcard/functional https://github.com/tcard/functional
- wting 13y ago
  We have two differing definitions of functional programming. I would argue that your code represents functional style in an imperative language. If function pointers are sufficient to qualify a language as a functional, then that would include C/C++. In contrast, Rust has support for the standard functional language primitives.[0][1][2] [0]: http://static.rust-lang.org/doc/core/vec.html#function-map http://static.rust-lang.org/doc/core/vec.html#function-map [1]: http://static.rust-lang.org/doc/core/vec.html#function-foldl http://static.rust-lang.org/doc/core/vec.html#function-foldl [2]: http://static.rust-lang.org/doc/core/vec.html#function-filter http://static.rust-lang.org/doc/core/vec.html#function-filte...
  - rcfox 13y ago
    How about this for functional programming in C? https://github.com/cioc/functionalC https://github.com/cioc/functionalC It's got some of your primitives (map and filter but no fold, but I'm assuming that it's just a matter of getting bored before implementing it) and closures. It's not a serious project, but it serves as a counter-example.
    - jerf 13y ago
      I'm not sure what you're trying to say this is a counter-example to, exactly. wting said "represents functional style in an imperative language"; that's all this seems to be. And as the author of that code themselves all but says, you'd be crazy to use that in production code, so it's not a particularly "good" implementation either. Nobody's questioning that a map-like thingy can be implemented in any Turing-complete language you choose, the question is whether it's actually useful in the context of the rest of the language. I can in fact write a generic map function in Go, by using reflection, but it'll be very slow, and it will still absolutely require the user of the map function to cast the result into the proper type manually since the Go compiler can't do it for you. (You actually can do something like closures in C, though managing the lifetime of the closure data struct can be tricky. And that's actually the problem with functional programming in C; the functional style does not technically "require" GC to work properly, but it sure does encourage it awfully strongly. Or you need something like Rust, with strong support for explicit lifetime management. In C you're just begging for memory leaks with a functional style.)
      - kyllo 13y ago
        Is that because in C, you have to explicitly pass around your lexical scope as fields in a struct, and then you have to remember to explicitly deallocate the struct and null out any pointers to it later when it's no longer needed?
        hderms 13y ago
        Pretty much, yeah. Closures can actually be a problem for memory deallocation in garbage collected languages. Someone I know was working on a common lisp app and eventually found some of their performance problems to be related to the amount of data held onto by closures.
- pjmlp 13y ago
  > Lack of generics just means you have to think harder. Or use other languages that are more developer friendly.
  - dscrd 13y ago
    Name one that has generics and is developer friendly.
    - kevingadd 13y ago
      Well, you can start with all the functional languages that automatically are able to do these things you're talking about, like Haskell and so on. You can argue they aren't 'developer friendly' but you never defined that term to begin with, and people are certainly productive with those languages (developer friendly compared to what? Go is certainly not the most accessible language) But in terms of more 'mass market' languages, C++ and C# both have incredibly robust generics that can be used to do real, no-foolin' functional programming, though doing it in C++ certainly takes a lot more effort and leans on modern libraries - closures are a comparatively recent introduction to the language. You've also got 'mass market' functional languages like F# to have fun with. Then there are the more fun options, like writing your functional code in Lua or Python and running it in a high-performance runtime like LuaJIT/PyPy to get fairly competitive performance without even needing explicit typing or built-in 'generics'.
    - kvb 13y ago
      I think F# has aesthetics similar to Python, despite being a statically typed language in the ML family. It's open sourced, with great IDE support on Windows (via Visual Studio, including a free option) and good IDE support on other platforms via Xamarin's tooling. Does that count as "developer friendly"?
    - pjmlp 13y ago
      Developer friendly is a matter of taste. As for having some form of generics: - C++ - Haskell - Modula-3 - Ada - Java - OCaml - Delphi - F# - Virgil (from Google) - VB.Net - Eiffel - Sather - Zonnon - Scala Just a small list.
ihsw 13y ago
Personally I find its dependency resolution to be one of the highlights of Go, and furthermore since circular dependencies are disallowed then that eases maintaining much larger and more complex codebases.
pjmlp 13y ago
For me it is mainly a C successor that catches up with what the Pascal family of languages has been offering since the mid-80's, in terms of compilation speed, modules, concurrency and safety.
- wting 13y ago
  I know Go has been touted as a C successor since inception, but most new users seem to be coming from interpreted languages. Like this blogger, they attribute a lot static language advantages as unique to Go. I don't see a lot of C/C++ developers switching, probably because they have sunk costs with their respective languages and Go doesn't offer very much by comparison. I would definitely use Go where it seems appropriate, but I don't see it replacing C as a systems language.[0] Sometimes when I write something in Go, I look back and wonder why didn't I just do it in C. However, Go is great in a distributed systems / networking environment where most new code seems to be written.[1] In the words of a friend, "You can pry raw memory access from my cold, dead fingers." [0] systems == OS, drivers, etc. [1] Motivations summarized in the abstract: http://talks.golang.org/2012/splash.article#TOC_1 http://talks.golang.org/2012/splash.article#TOC_1.
  - wonderzombie 13y ago
    Like this blogger, they attribute a lot static language advantages as unique to Go. This is true, but there is one piece ~unique to Go: type inference. It doesn't exist in Java or C, and it's only just made it to C++. For an individual coming from an interpreted language, it makes an otherwise statically typed language feel a lot less unwieldy and bureaucratic.
  - pjmlp 13y ago
    This is one of the areas where I actually take Go's defence. Have a look at Native Oberon and AOS, both desktop operating systems developed at Zurich's technical university. They are done in GC enabled systems programming languages and were used both as desktop systems by the teachers, as well as to teach operating systems classes. Quite nice desktop environments using strong typed languages, but offering a Smalltalk like user experience. http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pdf http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pd... https://www.ics.uci.edu/~franz/Site/pubs-pdf/BC03.pdf https://www.ics.uci.edu/~franz/Site/pubs-pdf/BC03.pdf http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager The problem with any systems programming language is that it is only used as such, if an OS vendor makes it the only way to do OS programming. Like Microsoft does with C++ or Apple with Objective-C.
fixxer 13y ago
> This statement needs to be qualified. Yeah, "seems to be correct" is a little wishy washy... I'd argue that Go has enough syntactic sugar to be easy to learn from a Python background, but enough structure that it encourages good software engineering practices.
pbreit 13y ago
> This statement needs to be qualified. The whole paragraph is a qualification. How much more do you want??
hsitz 13y ago
"The code you write with Go just seems to be correct." Ironically, Eric Raymond made very similar statements _about Python_ in his 2000 article explaining why he had moved to Python from static languages and from his previous dynamic language of Perl: "When you're writing working code nearly as fast as you can type and your misstep rate is near zero, it generally means you've achieved mastery of the language. But that didn't make sense, because it was still day one and I was regularly pausing to look up new language and library features!" "This was my first clue that, in Python, I was actually dealing with an exceptionally good design. Most languages have so much friction and awkwardness built into their design that you learn most of their feature set long before your misstep rate drops anywhere near zero. Python was the first general-purpose language I'd ever used that reversed this process." ____and again, regarding a little program whose code he links in the article____. . .: "That doesn't look too bad for deep black magic, does it? Thirty-two lines, counting comments. Just from knowing what I've said about the class structure, the calling code is even readable. But the size of this code isn't the real shocker. Brace yourself: this code only took me about ninety minutes to write—and it worked correctly the first time I ran it." "To say I was astonished would have been positively wallowing in understatement. It's remarkable enough when implementations of simple techniques work exactly as expected the first time; but my first metaclass hack in a new language, six days from a cold standing start? Even if we stipulate that I am a fairly talented hacker, this is an amazing testament to Python's clarity and elegance of design." "There was simply no way I could have pulled off a coup like this in Perl, even with my vastly greater experience level in that language. It was at this point I realized I was probably leaving Perl behind." http://www.linuxjournal.com/article/3882 http://www.linuxjournal.com/article/3882
- CatMtKing 13y ago
  I don't think it's so ironic. He wasn't speaking in comparison to Python; Go does bring a lot of the feel of Python as far as its conciseness and regularity of syntax.
  - hsitz 13y ago
    Thanks, I had just skimmed the article. You're right that there is no irony. And it may not even be a coincidence, may just be that one of the reasons that a person attracted to Python may also be attracted to Go.
viraptor 13y ago
> you just get the feeling that it’ll work (not just run without error, but even logically be correct) This is the feeling I get from good strongly/statically typed languages too. My best example is a ray tracer written from scratch in haskell. It took a good couple of hours, but then once it actually compiled it run the first time without error (but rendered everything behind the camera) and exactly as it was supposed to work on the second try. I really like languages which give me that kind of feeling.
georgemcbay 13y ago
There are, in fact, many small features of Go that make it more safe than C in terms of runtime correctness. eg. it has much stricter rules about automatic type conversion (you can't assign one int/char type to another differently sized int/char type without an explicit cast), it has sane built-in string handling much less likely to result in buffer overflow style issues, you have to go way out of your way with the unsafe package to blow your foot off by doing pointer arithmetic, etc, etc. None of these small things by itself adds a lot over C or C++, but combined they really add up. I did C/C++ programming professionally for more than 10 years (and come from a static language background) and I share the OP's view that compilable Go code is much more likely to be correct than code in other languages I've used, even static ones... the fact that the Go code compiled is of course no guarantee it'll be correct, but the Go compiler enforcing the rules of the Go spec does eliminate whole classes of common gotchas even ones that bite you in C/C++ and other compiled languages.
- DocSavage 13y ago
  I agree. To be more specific, I occasionally use the strict typing to guarantee my units are correct. I can define two float types and know that I won't mix up a variable with nanometers with one using microns. The lack of exceptions and forced handling of errors means you have to think of error handling immediately. It adds verbosity to code but also means most potentially failing calls have been explicitly handled, even if it's causing a fatal error and printing a message. Go considers unused variables an error, and while that can be a pain sometimes, it's also caught a few bugs where I've used an initialize and set operator (":=") in an inner scope, which didn't set the same variable in an outer scope. The main thing I wish Go had is generics.

by wting 13y ago

jdiez17 13y ago

You can actually do functional programming in Go. Lack of generics just means you have to think harder. In fact, a friend of mine did a Go library to write functional-style code: https://github.com/tcard/functional https://github.com/tcard/functional

wting 13y ago
We have two differing definitions of functional programming. I would argue that your code represents functional style in an imperative language. If function pointers are sufficient to qualify a language as a functional, then that would include C/C++. In contrast, Rust has support for the standard functional language primitives.[0][1][2] [0]: http://static.rust-lang.org/doc/core/vec.html#function-map http://static.rust-lang.org/doc/core/vec.html#function-map [1]: http://static.rust-lang.org/doc/core/vec.html#function-foldl http://static.rust-lang.org/doc/core/vec.html#function-foldl [2]: http://static.rust-lang.org/doc/core/vec.html#function-filter http://static.rust-lang.org/doc/core/vec.html#function-filte...
- rcfox 13y ago
  How about this for functional programming in C? https://github.com/cioc/functionalC https://github.com/cioc/functionalC It's got some of your primitives (map and filter but no fold, but I'm assuming that it's just a matter of getting bored before implementing it) and closures. It's not a serious project, but it serves as a counter-example.
  - jerf 13y ago
    I'm not sure what you're trying to say this is a counter-example to, exactly. wting said "represents functional style in an imperative language"; that's all this seems to be. And as the author of that code themselves all but says, you'd be crazy to use that in production code, so it's not a particularly "good" implementation either. Nobody's questioning that a map-like thingy can be implemented in any Turing-complete language you choose, the question is whether it's actually useful in the context of the rest of the language. I can in fact write a generic map function in Go, by using reflection, but it'll be very slow, and it will still absolutely require the user of the map function to cast the result into the proper type manually since the Go compiler can't do it for you. (You actually can do something like closures in C, though managing the lifetime of the closure data struct can be tricky. And that's actually the problem with functional programming in C; the functional style does not technically "require" GC to work properly, but it sure does encourage it awfully strongly. Or you need something like Rust, with strong support for explicit lifetime management. In C you're just begging for memory leaks with a functional style.)
    - kyllo 13y ago
      Is that because in C, you have to explicitly pass around your lexical scope as fields in a struct, and then you have to remember to explicitly deallocate the struct and null out any pointers to it later when it's no longer needed?
      - hderms 13y ago
        Pretty much, yeah. Closures can actually be a problem for memory deallocation in garbage collected languages. Someone I know was working on a common lisp app and eventually found some of their performance problems to be related to the amount of data held onto by closures.
pjmlp 13y ago
> Lack of generics just means you have to think harder. Or use other languages that are more developer friendly.
- dscrd 13y ago
  Name one that has generics and is developer friendly.
  - kevingadd 13y ago
    Well, you can start with all the functional languages that automatically are able to do these things you're talking about, like Haskell and so on. You can argue they aren't 'developer friendly' but you never defined that term to begin with, and people are certainly productive with those languages (developer friendly compared to what? Go is certainly not the most accessible language) But in terms of more 'mass market' languages, C++ and C# both have incredibly robust generics that can be used to do real, no-foolin' functional programming, though doing it in C++ certainly takes a lot more effort and leans on modern libraries - closures are a comparatively recent introduction to the language. You've also got 'mass market' functional languages like F# to have fun with. Then there are the more fun options, like writing your functional code in Lua or Python and running it in a high-performance runtime like LuaJIT/PyPy to get fairly competitive performance without even needing explicit typing or built-in 'generics'.
  - kvb 13y ago
    I think F# has aesthetics similar to Python, despite being a statically typed language in the ML family. It's open sourced, with great IDE support on Windows (via Visual Studio, including a free option) and good IDE support on other platforms via Xamarin's tooling. Does that count as "developer friendly"?
  - pjmlp 13y ago
    Developer friendly is a matter of taste. As for having some form of generics: - C++ - Haskell - Modula-3 - Ada - Java - OCaml - Delphi - F# - Virgil (from Google) - VB.Net - Eiffel - Sather - Zonnon - Scala Just a small list.

ihsw 13y ago

Personally I find its dependency resolution to be one of the highlights of Go, and furthermore since circular dependencies are disallowed then that eases maintaining much larger and more complex codebases.

pjmlp 13y ago

For me it is mainly a C successor that catches up with what the Pascal family of languages has been offering since the mid-80's, in terms of compilation speed, modules, concurrency and safety.

wting 13y ago
I know Go has been touted as a C successor since inception, but most new users seem to be coming from interpreted languages. Like this blogger, they attribute a lot static language advantages as unique to Go. I don't see a lot of C/C++ developers switching, probably because they have sunk costs with their respective languages and Go doesn't offer very much by comparison. I would definitely use Go where it seems appropriate, but I don't see it replacing C as a systems language.[0] Sometimes when I write something in Go, I look back and wonder why didn't I just do it in C. However, Go is great in a distributed systems / networking environment where most new code seems to be written.[1] In the words of a friend, "You can pry raw memory access from my cold, dead fingers." [0] systems == OS, drivers, etc. [1] Motivations summarized in the abstract: http://talks.golang.org/2012/splash.article#TOC_1 http://talks.golang.org/2012/splash.article#TOC_1.
- wonderzombie 13y ago
  Like this blogger, they attribute a lot static language advantages as unique to Go. This is true, but there is one piece ~unique to Go: type inference. It doesn't exist in Java or C, and it's only just made it to C++. For an individual coming from an interpreted language, it makes an otherwise statically typed language feel a lot less unwieldy and bureaucratic.
- pjmlp 13y ago
  This is one of the areas where I actually take Go's defence. Have a look at Native Oberon and AOS, both desktop operating systems developed at Zurich's technical university. They are done in GC enabled systems programming languages and were used both as desktop systems by the teachers, as well as to teach operating systems classes. Quite nice desktop environments using strong typed languages, but offering a Smalltalk like user experience. http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pdf http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pd... https://www.ics.uci.edu/~franz/Site/pubs-pdf/BC03.pdf https://www.ics.uci.edu/~franz/Site/pubs-pdf/BC03.pdf http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager The problem with any systems programming language is that it is only used as such, if an OS vendor makes it the only way to do OS programming. Like Microsoft does with C++ or Apple with Objective-C.

fixxer 13y ago

> This statement needs to be qualified. Yeah, "seems to be correct" is a little wishy washy... I'd argue that Go has enough syntactic sugar to be easy to learn from a Python background, but enough structure that it encourages good software engineering practices.

pbreit 13y ago

> This statement needs to be qualified. The whole paragraph is a qualification. How much more do you want??

hsitz 13y ago

"The code you write with Go just seems to be correct." Ironically, Eric Raymond made very similar statements _about Python_ in his 2000 article explaining why he had moved to Python from static languages and from his previous dynamic language of Perl: "When you're writing working code nearly as fast as you can type and your misstep rate is near zero, it generally means you've achieved mastery of the language. But that didn't make sense, because it was still day one and I was regularly pausing to look up new language and library features!" "This was my first clue that, in Python, I was actually dealing with an exceptionally good design. Most languages have so much friction and awkwardness built into their design that you learn most of their feature set long before your misstep rate drops anywhere near zero. Python was the first general-purpose language I'd ever used that reversed this process." ____and again, regarding a little program whose code he links in the article____. . .: "That doesn't look too bad for deep black magic, does it? Thirty-two lines, counting comments. Just from knowing what I've said about the class structure, the calling code is even readable. But the size of this code isn't the real shocker. Brace yourself: this code only took me about ninety minutes to write—and it worked correctly the first time I ran it." "To say I was astonished would have been positively wallowing in understatement. It's remarkable enough when implementations of simple techniques work exactly as expected the first time; but my first metaclass hack in a new language, six days from a cold standing start? Even if we stipulate that I am a fairly talented hacker, this is an amazing testament to Python's clarity and elegance of design." "There was simply no way I could have pulled off a coup like this in Perl, even with my vastly greater experience level in that language. It was at this point I realized I was probably leaving Perl behind." http://www.linuxjournal.com/article/3882 http://www.linuxjournal.com/article/3882

CatMtKing 13y ago
I don't think it's so ironic. He wasn't speaking in comparison to Python; Go does bring a lot of the feel of Python as far as its conciseness and regularity of syntax.
- hsitz 13y ago
  Thanks, I had just skimmed the article. You're right that there is no irony. And it may not even be a coincidence, may just be that one of the reasons that a person attracted to Python may also be attracted to Go.

viraptor 13y ago

> you just get the feeling that it’ll work (not just run without error, but even logically be correct) This is the feeling I get from good strongly/statically typed languages too. My best example is a ray tracer written from scratch in haskell. It took a good couple of hours, but then once it actually compiled it run the first time without error (but rendered everything behind the camera) and exactly as it was supposed to work on the second try. I really like languages which give me that kind of feeling.

georgemcbay 13y ago

There are, in fact, many small features of Go that make it more safe than C in terms of runtime correctness. eg. it has much stricter rules about automatic type conversion (you can't assign one int/char type to another differently sized int/char type without an explicit cast), it has sane built-in string handling much less likely to result in buffer overflow style issues, you have to go way out of your way with the unsafe package to blow your foot off by doing pointer arithmetic, etc, etc. None of these small things by itself adds a lot over C or C++, but combined they really add up. I did C/C++ programming professionally for more than 10 years (and come from a static language background) and I share the OP's view that compilable Go code is much more likely to be correct than code in other languages I've used, even static ones... the fact that the Go code compiled is of course no guarantee it'll be correct, but the Go compiler enforcing the rules of the Go spec does eliminate whole classes of common gotchas even ones that bite you in C/C++ and other compiled languages.

DocSavage 13y ago
I agree. To be more specific, I occasionally use the strict typing to guarantee my units are correct. I can define two float types and know that I won't mix up a variable with nanometers with one using microns. The lack of exceptions and forced handling of errors means you have to think of error handling immediately. It adds verbosity to code but also means most potentially failing calls have been explicitly handled, even if it's causing a fatal error and printing a message. Go considers unused variables an error, and while that can be a pain sometimes, it's also caught a few bugs where I've used an initialize and set operator (":=") in an inner scope, which didn't set the same variable in an outer scope. The main thing I wish Go had is generics.