10 ms·

Go vs. Swift [pdf]

166 points by jakerockland 10y ago

zatkin 10y ago
I'm confused as to why this piece was written using LaTeX.
- tnecniv 10y ago
  Why? The LaTeX required to produce a PDF like that is no more complicated than your favorite format.
  - omeid2 10y ago
    Compared to Markdown, LaTeX is extremly complex, in fact, isn't LaTeX is turning complete.
    - detaro 10y ago
      It is (some fun examples here: https://stackoverflow.com/questions/2968411/ive-heard-that-latex-is-turing-complete-are-there-any-programs-written-in-late https://stackoverflow.com/questions/2968411/ive-heard-that-l... ), but that's completely irrelevant to how complicated or not it was to create this document.
- robert_foss 10y ago
  It's soo pretty.
- panzagl 10y ago
  I'm sure we'll see a 'Go vs LaTeX' post before the day is done...
  - thewhitetulip 10y ago
    And I feel that it would also reach the front page :D
- jakerockland 10y ago
  Because it's nice to learn how to use new tools? Hadn't used LaTeX before and saw this as a good learning opportunity for getting started. I'm confused as to what is wrong with writing this piece with LaTeX?
  - anonfunction 10y ago
    I'm not who you're replying to but I was looking for some way to convert it to an html page. It's unfortunate that the only readable copy is the pdf since it cuts the code examples and renders poorly on my laptop.
    - tnecniv 10y ago
      Interesting, it renders fine on mine (not OP).
yvsong 10y ago
Swift: better OO, syntax, IDE; Go: built-in concurrency; Swift is a great joy for iOS development, where compatibility with Objective C makes things smooth, and operation queues are good enough for concurrency. Xcode is a big productivity booster. Good to break Swift's own backward compatibility with new releases to keep innovation, while providing a quick fix tool. Hope it will become a great server language too.
- ajmurmann 10y ago
  I never understand the praise for XCode. I love the iOS specific features like GUI creator out property explorer. But the text editor part is just awful compared to anything else I've used (primarily JetBrains IDEs, but also vim, sublime and some atom). On top of that it also has comparatively poor git integration. Edit: one thing I forgot is the very slow feedback at least when editing Swift. For syntax error notifications to get updated sometimes takes tens of second which can be very confusing.
  - untog 10y ago
    Agreed. I don't use the GUI tools much (I prefer to manually construct stuff, I know, I know...) and XCode has been just awful to work with. Random crashes, freezing while debugging... in the most recent version I can't view log outputs of a process I attach to, and if I try to take a screenshot from the iOS Simulator it immediately crashes.
  - jksmith 10y ago
    Yeah agree. While I've moved on, IMHO xcode was generally crap compared to dev envs I used back in the friggin 90's, like Delphi or Topspeed. Not many on HN know much about Delphi, but it set the gold standard for the desktop IDE. Great thing about Go is you don't need much of an IDE because it's best to just keep Go in its sweet spot, which is services. LiteIDE works great for Go- small footprint,debugging, enough project management to get by. Just like with everything else about Go, you can get a newbie dev going with the Go toolchain actually producing something that works in hardly any time.
    - 10y ago
seanalltogether 10y ago
The more I use swift, the more I've grown to appreciate the concept of Optionals and how the compiler enforces it's usage. I have found that my swift code is more robust and explicit than my ObjC or Android java code is, as well as the team members around me.
- burntcookie90 10y ago
  make sure you check out kotlin then, for Android
- wyager 10y ago
  > the more I've grown to appreciate the concept of Optionals You may also enjoy a language that supports the generalization of Optionals, which are Algebraic Data Types (ADTs). Optionals are a single, limited application of ADTs. Optionals allow you to shift null pointers (and null pointer exceptions) to the type level. So instead of having to worry about a function returning null, you just deal with Optionals whenever a function returns one. There's another ADT, usually called "Either" or "Result", that allows you to shift exceptions to the type level. You can see from the type of the function what kind of exception it might return, and you deal with exceptions like any other value instead of via a special exception handling mechanism.
  - austinz 10y ago
    Swift supports ADTs and implements its Optional type as an ADT.
    - wyager 10y ago
      > Swift supports ADTs True, but perhaps not practically relevant. The pattern matching in Swift isn't much better than what you would get with a tagged C union, which is why no one really uses it very heavily. The Optional type in Swift gets a lot of special compiler support, which is indicative of the fact that the broader language isn't very friendly towards using ADTs to structure data. But you're right, I should have clarified in my comment that Swift does have a basic degree of support for ADTs.
blario 10y ago
Very basic comparison. Doesn't go into the quality of the generated code, compiler speed or efficiency, etc.
- melling 10y ago
  I would hope that Go is better in all of the above. It has been available for much longer, and it's supported by a great team. I want to know how the languages compare for writing code. Dos one make it easier to write more succinct and correct code? Swift is missing concurrency support until at least the next version, for example.
  - ridiculous_fish 10y ago
    Go's compiler emits naive code quickly. For example, parameters are always passed on the stack. Swift is built atop LLVM, and it emits code more slowly, but supports many optimizations like hoisting, vectorization, etc. that Go does not currently perform.
  - kazagistar 10y ago
    I'm not sure, Go code isn't all that fast.
- jakerockland 10y ago
  This definitely is a basic comparison. If you didn't see in the readme, this was a paper for a course I took and definitely has a lot of areas that could use more elaboration or detail. There are some open issues for things I'd like to add at some point when I have the time, feel free to open new issues if there are other things you think are missing!
waynecochran 10y ago
No mention of functional programming and the idiomatic async calls using closures made popular as of late by JS?
- jaekwon 10y ago
  That's nice, but in JS it's a necessary evil. Callback hell is not a desirable feature.
- jakerockland 10y ago
  This paper definitely has a lot of room for elaboration and improvement. There are some open issues in the repo for things I'd like to add at some point when I have the time, feel free to open new issues if there are other things you think are missing--I'm also welcome to contributions if you'd like to make a PR.
c0ffe 10y ago
I favored Swift over Go in a small project (developed in my freetime) because it has template / metaprogramming support, and it calls destructors inmediately on unreferenced objects. Some things that can be improved: * It needs more support / packages for Linux (and Windows maybe?). I was using Manjaro Linux, and around November 2016 (dont remember exactly), the existing packages in the AUR didnt work anymore. * No built-in weak collections. * No source subfolders for the same project when using the buit-in package manager (I dont know about Go in this matter).
solidsnack9000 10y ago
> Because concurrency is supported through an Apple API rather than being explicit in the language’s design, using it is currently very much coupled to iOS or macOS development. I am not sure this is accurate, because libdispatch has been ported to Linux: https://github.com/apple/swift-corelibs-libdispatch https://github.com/apple/swift-corelibs-libdispatch They are "...early in the development of this project..." but server-side frameworks use it.
- jakerockland 10y ago
  This is one of the things I have marked as an issue to elaborate a bit more on. https://github.com/jakerockland/go-vs-swift/issues/8 https://github.com/jakerockland/go-vs-swift/issues/8 Thanks for the link! :)
  - solidsnack9000 10y ago
    The two differences that I wonder about: * What is the cost profile of Dispatch relative to the Go scheduler? It seems that Go programs suffer a slow down just to enable multi-threading, for example -- which is not unlike other systems (GHC at some time in the past) that have a similar model. * Is Dispatch suitable for "millions of threads" ala Erlang? Hundreds of thousands of threads? Dispatch allows you to decide which queue to put things on; but also kind of requires it of you.
    - eridius 10y ago
      AIUI Dispatch is suitable for potentially hundreds of thousands of queues. It doesn't spin up thousands of actual OS threads, instead it intelligently manages a pool of OS threads and multiplexes the queues onto them. IIRC each dispatch queue is around 100-200 bytes in size (while empty).
      - solidsnack9000 10y ago
        Yeah but I wonder about is, is the concurrency truly fine-grained and scalable? For example, you want to do a map over an array of 1 million elements. Can you dump a million blocks on a queue for a linear speed-up?
danielparks 10y ago
Go feels like a beefed up version of C. Swift feels like a high level language with static typing. Interestingly, Swift doesn't feel much like Obj-C.
- rimantas 10y ago
  > Interestingly, Swift doesn't feel much like Obj-C. Not necesarrily a bad thing. However I am the one who does like Obj-C. That said after some time with Swift you do not really want to go back to Ojbective C any more.
- SomeHacker44 10y ago
  With C you almost always know what you have, and can always cast it to anything else you want (safely or otherwise). With Go, I'm never sure what I have (pointer? reference? something other and weird?), and can't cast things that should be castable. Either way, I'd still rather take Haskell or Common Lisp, but I'd gladly take C over Go after having used Go for a highly multithreaded communications server.
alvil 10y ago
It's not true that Go requires import "fmt" to print something.
- jakerockland 10y ago
  I have a note about that: > Note that Go does support a ‘println’ function that does not require import- ing from the standard library; however, this function reports to ‘stderr’, rather than ‘stdout’, and is not guaranteed to stay in the language 19.
pawadu 10y ago
I found the study very shallow and superficial. For example, who cares how many people have starred a project on github? And why should I care how many lines "hello world" is in a language [1]? I would rather see a discussion about performance, platform support, maintainability, governance and do on. --- [1] someone please create a new programming language where the empty file means "print hello world". Since you can't do any better than that it would once and for all put an end to this stupid benchmark.
- hardwaresofton 10y ago
  The author notes here (in the HN thread) that it's a very very cursory overview and there are plans to add more later given time. This could have been a blog post (or series of blog posts), so maybe the academic-paper feel was misleading. While I'm not sure this content should be on the front page, it never was represented as a very deep comparison. I do admit that when I read it through I expected much more. Also, how do you determine what libraries to use and what projects to invest in these days? Do you always do a full audit of every project? I know I don't have the time, so I use stars on a Github project just like one might use word-of-mouth. If a ton of people think a thing is useful, it's probably at least a little useful. Of course, that kind of thinking can be dangerous (see: javascript ecosystem), but a lot of the time, it's "good enough". BTW, the paper does cover a tiny bit of information regarding differences in platform support when it covers how Swift deals with concurrency.
  - pawadu 10y ago
    > I know I don't have the time, so I use stars on a Github project just like one might use word-of-mouth. Up to a certain point, stars can be useful as it helps you discover projects other people have found of use. But saying project X is better than project Y because it has more stars? What does it show other than more people using X are on github or people using X a more prone to push the star button? For reference, bootstrap has 100K stars, Linux has 40K...
    - hardwaresofton 10y ago
chmike 10y ago
I don't see any "strength" in the classical object oriented programming model as found in C++ or Java. Actually, in modern programming composition is considered superior to inheritance. The interface concept of Go makes programming with composition much more flexible and powerful than with the class model. The author skips this Go specific and original interface typing. This provides a multiple inheritance equivalent without all the complications on C++ and that most OO oriented languages forbid because of that complication. Go is a very original language in this aspect as well as with concurrency. Understanding and mastering these properties goes beyond simple syntax analysis. To me the most remarkable property of Go is its simplicity. As I explained to a friend who is a strong advocate of D, the difference with other programming language is the same as dealing with a spoken language of 1000 words instead of 10,000 words. It's true that the language with 10,000 words is more expressive and richer. But the effort required to learn, read and write a language of 1000 words is much lower than a with a language of 10000 words. I'm beyond 50 years old, and too me this makes a huge difference. The best way to express it is that with Go programming is fun again. I hope that Go will preserve this simplicity. At the beginning Java was simple too. They later killed it to the point I don't want to deal with Java code anymore.
- claudiug 10y ago
  `Go programming is fun again` I found this expression really difficult to accept it :) Ruby, Python are languages that are quite fun for me. Also, `Go is a very original language in this aspect as well as with concurrency` CSP is quite old also. Dlang, is quite a nice and easy to start language, If I will compare d vs go, I will say that you can see that golang has a lot of money and people behind. And, after I wrote more than a simple library, I tend to be tired of some parts of the language decision, and is not about interface, is just the small stuff. But again, I tend to write code that is more OOP :) Please excuse me if my reply offend you, that is just my personal opinion after work with golang few years ago
- bad_user 10y ago
  OOP is primarily about polymorphism (subtyping) and encapsulation, code reuse by means of inheritance is just a nice to have, so that comparison doesn't make sense. You can compare OOP with parametric polymorphism, you can compare it with type-classes. Heck, OOP isn't necessarily about subtyping and we could be talking about row polymorphism (e.g. OCaml) which has some really nice properties. > This provides a multiple inheritance equivalent without all the complications on C++ and that most OO oriented languages forbid because of that complication. Except that it doesn't solve the fundamental problems with OOP, because it's still essentially OOP with subtyping ... and lots of marketing. So coming from Go you can be excused for thinking that the last 30 years of research have been for nothing.
scotty79 10y ago
Semi-related, side-by-side comparison of how common things are done in swift and go: http://rosetta.alhur.es/compare/swift/go/# http://rosetta.alhur.es/compare/swift/go/#
coldcode 10y ago
I use Swift every day and appreciate it a lot, while I have only cursory experience in Go, mostly because it didn't have any real debugger support in the past. But any comparison is rather shallow because at the moment they don't really address the same target usage, and Swift is only minimally supported on the server side where Go is generally used. Give it a couple years and the comparison might be more meaningful. Once Jetbrains Gogland is up and running I will be playing more with Go.
tonyedgecombe 10y ago
I can't believe many people are making that choice, it strikes me the domains of the two languages don't intersect very much.
twoquestions 10y ago
The analysis looked good to me, but I was only able to read it after I downloaded it. I hate to be "that guy", but the Github pdf viewer brought Chrome to its knees.

Go vs. Swift [pdf]

166 points by jakerockland 10y ago

zatkin 10y ago

I'm confused as to why this piece was written using LaTeX.

tnecniv 10y ago
Why? The LaTeX required to produce a PDF like that is no more complicated than your favorite format.
- omeid2 10y ago
  Compared to Markdown, LaTeX is extremly complex, in fact, isn't LaTeX is turning complete.
  - detaro 10y ago
    It is (some fun examples here: https://stackoverflow.com/questions/2968411/ive-heard-that-latex-is-turing-complete-are-there-any-programs-written-in-late https://stackoverflow.com/questions/2968411/ive-heard-that-l... ), but that's completely irrelevant to how complicated or not it was to create this document.
robert_foss 10y ago
It's soo pretty.
panzagl 10y ago
I'm sure we'll see a 'Go vs LaTeX' post before the day is done...
- thewhitetulip 10y ago
  And I feel that it would also reach the front page :D
jakerockland 10y ago
Because it's nice to learn how to use new tools? Hadn't used LaTeX before and saw this as a good learning opportunity for getting started. I'm confused as to what is wrong with writing this piece with LaTeX?
- anonfunction 10y ago
  I'm not who you're replying to but I was looking for some way to convert it to an html page. It's unfortunate that the only readable copy is the pdf since it cuts the code examples and renders poorly on my laptop.
  - tnecniv 10y ago
    Interesting, it renders fine on mine (not OP).

yvsong 10y ago

Swift: better OO, syntax, IDE; Go: built-in concurrency; Swift is a great joy for iOS development, where compatibility with Objective C makes things smooth, and operation queues are good enough for concurrency. Xcode is a big productivity booster. Good to break Swift's own backward compatibility with new releases to keep innovation, while providing a quick fix tool. Hope it will become a great server language too.

ajmurmann 10y ago
I never understand the praise for XCode. I love the iOS specific features like GUI creator out property explorer. But the text editor part is just awful compared to anything else I've used (primarily JetBrains IDEs, but also vim, sublime and some atom). On top of that it also has comparatively poor git integration. Edit: one thing I forgot is the very slow feedback at least when editing Swift. For syntax error notifications to get updated sometimes takes tens of second which can be very confusing.
- untog 10y ago
  Agreed. I don't use the GUI tools much (I prefer to manually construct stuff, I know, I know...) and XCode has been just awful to work with. Random crashes, freezing while debugging... in the most recent version I can't view log outputs of a process I attach to, and if I try to take a screenshot from the iOS Simulator it immediately crashes.
- jksmith 10y ago
  Yeah agree. While I've moved on, IMHO xcode was generally crap compared to dev envs I used back in the friggin 90's, like Delphi or Topspeed. Not many on HN know much about Delphi, but it set the gold standard for the desktop IDE. Great thing about Go is you don't need much of an IDE because it's best to just keep Go in its sweet spot, which is services. LiteIDE works great for Go- small footprint,debugging, enough project management to get by. Just like with everything else about Go, you can get a newbie dev going with the Go toolchain actually producing something that works in hardly any time.
  - 10y ago

seanalltogether 10y ago

The more I use swift, the more I've grown to appreciate the concept of Optionals and how the compiler enforces it's usage. I have found that my swift code is more robust and explicit than my ObjC or Android java code is, as well as the team members around me.

burntcookie90 10y ago
make sure you check out kotlin then, for Android
wyager 10y ago
> the more I've grown to appreciate the concept of Optionals You may also enjoy a language that supports the generalization of Optionals, which are Algebraic Data Types (ADTs). Optionals are a single, limited application of ADTs. Optionals allow you to shift null pointers (and null pointer exceptions) to the type level. So instead of having to worry about a function returning null, you just deal with Optionals whenever a function returns one. There's another ADT, usually called "Either" or "Result", that allows you to shift exceptions to the type level. You can see from the type of the function what kind of exception it might return, and you deal with exceptions like any other value instead of via a special exception handling mechanism.
- austinz 10y ago
  Swift supports ADTs and implements its Optional type as an ADT.
  - wyager 10y ago
    > Swift supports ADTs True, but perhaps not practically relevant. The pattern matching in Swift isn't much better than what you would get with a tagged C union, which is why no one really uses it very heavily. The Optional type in Swift gets a lot of special compiler support, which is indicative of the fact that the broader language isn't very friendly towards using ADTs to structure data. But you're right, I should have clarified in my comment that Swift does have a basic degree of support for ADTs.

blario 10y ago

Very basic comparison. Doesn't go into the quality of the generated code, compiler speed or efficiency, etc.

melling 10y ago
I would hope that Go is better in all of the above. It has been available for much longer, and it's supported by a great team. I want to know how the languages compare for writing code. Dos one make it easier to write more succinct and correct code? Swift is missing concurrency support until at least the next version, for example.
- ridiculous_fish 10y ago
  Go's compiler emits naive code quickly. For example, parameters are always passed on the stack. Swift is built atop LLVM, and it emits code more slowly, but supports many optimizations like hoisting, vectorization, etc. that Go does not currently perform.
- kazagistar 10y ago
  I'm not sure, Go code isn't all that fast.
jakerockland 10y ago
This definitely is a basic comparison. If you didn't see in the readme, this was a paper for a course I took and definitely has a lot of areas that could use more elaboration or detail. There are some open issues for things I'd like to add at some point when I have the time, feel free to open new issues if there are other things you think are missing!

waynecochran 10y ago

No mention of functional programming and the idiomatic async calls using closures made popular as of late by JS?

jaekwon 10y ago
That's nice, but in JS it's a necessary evil. Callback hell is not a desirable feature.
jakerockland 10y ago
This paper definitely has a lot of room for elaboration and improvement. There are some open issues in the repo for things I'd like to add at some point when I have the time, feel free to open new issues if there are other things you think are missing--I'm also welcome to contributions if you'd like to make a PR.

c0ffe 10y ago

I favored Swift over Go in a small project (developed in my freetime) because it has template / metaprogramming support, and it calls destructors inmediately on unreferenced objects. Some things that can be improved: * It needs more support / packages for Linux (and Windows maybe?). I was using Manjaro Linux, and around November 2016 (dont remember exactly), the existing packages in the AUR didnt work anymore. * No built-in weak collections. * No source subfolders for the same project when using the buit-in package manager (I dont know about Go in this matter).

solidsnack9000 10y ago

> Because concurrency is supported through an Apple API rather than being explicit in the language’s design, using it is currently very much coupled to iOS or macOS development. I am not sure this is accurate, because libdispatch has been ported to Linux: https://github.com/apple/swift-corelibs-libdispatch https://github.com/apple/swift-corelibs-libdispatch They are "...early in the development of this project..." but server-side frameworks use it.

jakerockland 10y ago
This is one of the things I have marked as an issue to elaborate a bit more on. https://github.com/jakerockland/go-vs-swift/issues/8 https://github.com/jakerockland/go-vs-swift/issues/8 Thanks for the link! :)
- solidsnack9000 10y ago
  The two differences that I wonder about: * What is the cost profile of Dispatch relative to the Go scheduler? It seems that Go programs suffer a slow down just to enable multi-threading, for example -- which is not unlike other systems (GHC at some time in the past) that have a similar model. * Is Dispatch suitable for "millions of threads" ala Erlang? Hundreds of thousands of threads? Dispatch allows you to decide which queue to put things on; but also kind of requires it of you.
  - eridius 10y ago
    AIUI Dispatch is suitable for potentially hundreds of thousands of queues. It doesn't spin up thousands of actual OS threads, instead it intelligently manages a pool of OS threads and multiplexes the queues onto them. IIRC each dispatch queue is around 100-200 bytes in size (while empty).
    - solidsnack9000 10y ago
      Yeah but I wonder about is, is the concurrency truly fine-grained and scalable? For example, you want to do a map over an array of 1 million elements. Can you dump a million blocks on a queue for a linear speed-up?

danielparks 10y ago

Go feels like a beefed up version of C. Swift feels like a high level language with static typing. Interestingly, Swift doesn't feel much like Obj-C.

rimantas 10y ago
> Interestingly, Swift doesn't feel much like Obj-C. Not necesarrily a bad thing. However I am the one who does like Obj-C. That said after some time with Swift you do not really want to go back to Ojbective C any more.
SomeHacker44 10y ago
With C you almost always know what you have, and can always cast it to anything else you want (safely or otherwise). With Go, I'm never sure what I have (pointer? reference? something other and weird?), and can't cast things that should be castable. Either way, I'd still rather take Haskell or Common Lisp, but I'd gladly take C over Go after having used Go for a highly multithreaded communications server.

alvil 10y ago

It's not true that Go requires import "fmt" to print something.

jakerockland 10y ago
I have a note about that: > Note that Go does support a ‘println’ function that does not require import- ing from the standard library; however, this function reports to ‘stderr’, rather than ‘stdout’, and is not guaranteed to stay in the language 19.

pawadu 10y ago

I found the study very shallow and superficial. For example, who cares how many people have starred a project on github? And why should I care how many lines "hello world" is in a language [1]? I would rather see a discussion about performance, platform support, maintainability, governance and do on. --- [1] someone please create a new programming language where the empty file means "print hello world". Since you can't do any better than that it would once and for all put an end to this stupid benchmark.

hardwaresofton 10y ago
The author notes here (in the HN thread) that it's a very very cursory overview and there are plans to add more later given time. This could have been a blog post (or series of blog posts), so maybe the academic-paper feel was misleading. While I'm not sure this content should be on the front page, it never was represented as a very deep comparison. I do admit that when I read it through I expected much more. Also, how do you determine what libraries to use and what projects to invest in these days? Do you always do a full audit of every project? I know I don't have the time, so I use stars on a Github project just like one might use word-of-mouth. If a ton of people think a thing is useful, it's probably at least a little useful. Of course, that kind of thinking can be dangerous (see: javascript ecosystem), but a lot of the time, it's "good enough". BTW, the paper does cover a tiny bit of information regarding differences in platform support when it covers how Swift deals with concurrency.
- pawadu 10y ago
  > I know I don't have the time, so I use stars on a Github project just like one might use word-of-mouth. Up to a certain point, stars can be useful as it helps you discover projects other people have found of use. But saying project X is better than project Y because it has more stars? What does it show other than more people using X are on github or people using X a more prone to push the star button? For reference, bootstrap has 100K stars, Linux has 40K...
  - hardwaresofton 10y ago

chmike 10y ago

I don't see any "strength" in the classical object oriented programming model as found in C++ or Java. Actually, in modern programming composition is considered superior to inheritance. The interface concept of Go makes programming with composition much more flexible and powerful than with the class model. The author skips this Go specific and original interface typing. This provides a multiple inheritance equivalent without all the complications on C++ and that most OO oriented languages forbid because of that complication. Go is a very original language in this aspect as well as with concurrency. Understanding and mastering these properties goes beyond simple syntax analysis. To me the most remarkable property of Go is its simplicity. As I explained to a friend who is a strong advocate of D, the difference with other programming language is the same as dealing with a spoken language of 1000 words instead of 10,000 words. It's true that the language with 10,000 words is more expressive and richer. But the effort required to learn, read and write a language of 1000 words is much lower than a with a language of 10000 words. I'm beyond 50 years old, and too me this makes a huge difference. The best way to express it is that with Go programming is fun again. I hope that Go will preserve this simplicity. At the beginning Java was simple too. They later killed it to the point I don't want to deal with Java code anymore.

claudiug 10y ago
`Go programming is fun again` I found this expression really difficult to accept it :) Ruby, Python are languages that are quite fun for me. Also, `Go is a very original language in this aspect as well as with concurrency` CSP is quite old also. Dlang, is quite a nice and easy to start language, If I will compare d vs go, I will say that you can see that golang has a lot of money and people behind. And, after I wrote more than a simple library, I tend to be tired of some parts of the language decision, and is not about interface, is just the small stuff. But again, I tend to write code that is more OOP :) Please excuse me if my reply offend you, that is just my personal opinion after work with golang few years ago
bad_user 10y ago
OOP is primarily about polymorphism (subtyping) and encapsulation, code reuse by means of inheritance is just a nice to have, so that comparison doesn't make sense. You can compare OOP with parametric polymorphism, you can compare it with type-classes. Heck, OOP isn't necessarily about subtyping and we could be talking about row polymorphism (e.g. OCaml) which has some really nice properties. > This provides a multiple inheritance equivalent without all the complications on C++ and that most OO oriented languages forbid because of that complication. Except that it doesn't solve the fundamental problems with OOP, because it's still essentially OOP with subtyping ... and lots of marketing. So coming from Go you can be excused for thinking that the last 30 years of research have been for nothing.

scotty79 10y ago

Semi-related, side-by-side comparison of how common things are done in swift and go: http://rosetta.alhur.es/compare/swift/go/# http://rosetta.alhur.es/compare/swift/go/#

coldcode 10y ago

I use Swift every day and appreciate it a lot, while I have only cursory experience in Go, mostly because it didn't have any real debugger support in the past. But any comparison is rather shallow because at the moment they don't really address the same target usage, and Swift is only minimally supported on the server side where Go is generally used. Give it a couple years and the comparison might be more meaningful. Once Jetbrains Gogland is up and running I will be playing more with Go.

tonyedgecombe 10y ago

I can't believe many people are making that choice, it strikes me the domains of the two languages don't intersect very much.

twoquestions 10y ago

The analysis looked good to me, but I was only able to read it after I downloaded it. I hate to be "that guy", but the Github pdf viewer brought Chrome to its knees.