5 ms·

Go and Swift take another step up the programming language ladder

70 points by steven 12y ago

bsg75 12y ago
This mistake happens a lot: Go is not a "Google" language in the sense of corporate ownership. Development is sponsored by Google, but control is left in the community. This is on the opposite end of the spectrum from Swift which is controlled by Apple, which is not necessarily a bad thing depending on your perspective.
- ChikkaChiChi 12y ago
  Absolutely spot on, but it's damn near impossible talking to a non-programmer about Go without biting your tongue every time you almost say 'Google'
- robert_tweed 12y ago
  The article doesn't say that. However, Go did originate at Google and the points the article makes about it having been designed to solve specific problems at Google are all true. It was not originally intended to be a widely-used general-purpose language: it just happened to catch on after it was released publicly. Furthermore, the most significant contributors to the language design and its evolution (Rob Pike, Russ Cox, Andrew Gerrand, Brad Fitzpatrick, etc.) are all employed by Google. It's not at all unfair or misleading to call it "Google's" in the way the article does.
  - exch 12y ago
    Not sure why you are getting down voted. These are all valid points.
  - Animats 12y ago
    Go, as it stands, is intended for getting good performance in server-side applications. There's good support for huge numbers of simultaneous network connections, and no standard GUI support. Google needed something; C++ has too many memory problems and Python is too slow. Facebook uses PHP for much of their server-side stuff. They did a PHP compiler to make that tolerably fast. Mozilla's Rust has potential, but I'm not convinced they have the "owning" logic right. Supposedly 10% of the code in Servo, their browser renderer, is "unsafe". That's far too high. They've had their first good big idea, but I think they're one or two key concepts short of definitively solving the problem of memory safety without garbage collection. Swift I don't know about. Interestingly, these are all hard-compiled languages. Most of the "flexibility" of scripting languages has been removed. It seems that the one scripting language feature programmers really wanted type inference for local variables. That's a feature of Go, Swift, Rust, and PHP. Even C++ has that now, with "auto". (Writing iterator type declarations in C++ FOR statements was a huge pain.) It's almost better if function parameters have hard types; you can look at the function definition and see what it wants. Python and JavaScript leave you wondering "what type is parameter 3 supposed to be, anyway?" There's some syntactic convergence, too. Go, Rust, and Swift all use C-type brackets. Python indentation style control structure didn't catch on. We're also converging on "name: type", instead of C's "type name" form. That was a design mistake in C; the language became context-sensitive when "typedef" was added and the compiler had to known which words were type names. Where to put semicolons, though, is not converging.
    - erickt 12y ago
      There are two things going on in Servo that are causing it to use a lot of unsafe { ... } blocks. First, it still depends on a large amount of large c libraries, like SpiderMonkey for JavaScript. We automatically treat c foreign functions as unsafe as we can't protect against them doing unsafe things. Second, the DOM is very much built on an object oriented class hierarchy, and we in rust have put off figuring out how we can support that until after 1.0. So Servo uses unsafe code to hack around our temporary lack of support for that feature. So while there may be a lot of unsafe blocks, it should only be for the short/medium term.
    - Someone 12y ago
      "It seems that the one scripting language feature programmers really wanted type inference for local variables." Other features that I would put in that category: - string interpolation - a repl-like environment (fast startup, interactive, not requiring one to define a function or class to get some output) - convenient syntax for initializing arrays and hashes - generics as a most-of-the-time substitute for weak typing
      - Animats 12y ago
        There is convergence on hashed dictionaries as a basic type, and syntax for subarrays. Generics are still up in the air. Templates got so complex in C++ that they ate the language. Go avoids generics, but that leads to over-use of the any type ("interface{}" in Go) and reflection. Rust is somewhere in between. A REPL environment is more of a tool chain issue than a language design issue.
        Someone 12y ago
        "A REPL environment is more of a tool chain issue than a language design issue." Moreof, maybe, but it is language design, too. If you had a Java REPL, you still would have to type quite a bit of stuff (a class and a function) before you would have your "Hello, world". Yes, you could add an implicit class named GLOBAL that magically gets a property named 'P' the moment you type P = "Hello, world"; but I would call that doing language redesign.
  - threeseed 12y ago
    Completely spot on. And we know how this works in other open source projects. When you have most of the committers from one company they do ultimately drive the direction in their favour. Go for all intents and purposes IS a Google project. At least for now.
  - enneff 12y ago
    > It was not originally intended to be a widely-used general-purpose language Yes, it was. That was always the intention.
    - robert_tweed 12y ago
      I stand corrected :) I'm sure I was paraphrasing Rob Pike from one of his talks describing the origins within Google.
Dewie 12y ago
This article seems to be written for non-programmers.
bigtunacan 12y ago
I see this and I just think of the Joe Armstrong post on education. http://erlang.org/pipermail/erlang-questions/2013-January/071944.html http://erlang.org/pipermail/erlang-questions/2013-January/07... So many languages to choose from; so much fragmentation while we are already experiencing a shortage of developers. I appreciate that Apple made something available other than Objective-C. I've done my share of it and personally I don't think it's a bad language, but the foreign syntax makes it less approachable to some. The sandbox mode in Xcode with Swift is great too. I just wish that instead of suffering from "Not Invented Here" syndrome that they would have chosen something that already exists. Ruby, Python, Lua, Scala, Clojure. There are so many choices, can't at least one fit the bill?
- sanderjd 12y ago
  I think Swift is a great language, and that creating something new that incorporates some very good ideas into a package that works well with their existing and extensive runtime made a lot of sense, but that tying it to their platform is a damn shame (though not unsurprising). I don't think the languages you list would have been a great fit, but D would have been a really good and interesting choice. Were it more mature, Rust could have also been a good fit.
  - bjz_ 12y ago
    One of the big things for Apple was Objective-C compatibility, which is surprisingly hard to get right. I know because I have been trying to wrap the APIs for Rust. Don't get me wrong: I still would prefer to use Rust on iOS, but Apple has too much invested in their Objective-C APIs to force a subpar experience and migration path onto their developers.
    - sanderjd 12y ago
      You certainly know more about this than me. Do you think Rust would have been fundamentally more difficult to make compatible with Objective-C than Swift was, assuming Apple had invested the same amount of time and effort? My sense is "no", but I really don't have any clue, and I'm genuinely curious.
bencollier49 12y ago
No mention of Rust, which I think ought to have been a natural addition to the article?
- sremani 12y ago
  Author wanted to prove that Big Institutions build PLs so he sought languages that came out of huge corps and universities and Rust would go counter to his theory. pythong, ruby, perl were also not discussed as much. It is not a great article, probably for main-street consumption.
- Dewie 12y ago
  It's hard to imagine how they would go from discussing the conundrums of whether-to-use-braces-or-indentation, to discussing the merits of efficiency + memory safety. Though I guess they could have chosen to bring up the peculiar meaning of the semicolon in Rust.
  - bjz_ 12y ago
    The semicolon as a statement separator is such a lovely thing that it would be hard to imagine Rust without it. It's sad to see that Swift and Go have gone with a statement based approach as opposed to emphasizing the composition of expressions. They feel very clunky in comparison.
    - Animats 12y ago
      The semicolon as a statement separator is such a lovely thing... That particular convention goes back to ALGOL-58. In ALGOL-58, semicolon is a statement separator. See page 14 of the ALGOL-58 report: http://www.softwarepreservation.org/projects/ALGOL/report/Algol58_preliminary_report_CACM.pdf http://www.softwarepreservation.org/projects/ALGOL/report/Al... C goes the other way, with semicolon as a statement terminator. 56 years after ALGOL-58, we still don't have convergence on this. Wikipedia has a table: https://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28syntax%29#Statements https://en.wikipedia.org/wiki/Comparison_of_programming_lang...
enneff 12y ago
Syntax is by far the least interesting thing about any new programming language, but they spend paragraphs talking about braces and semicolons. And the conclusions are bizarre and uninformed: > When Sun rolled out Java in 1995, everyone thought it would be a dandy tool for building browser applets that made images dance, yet its destiny was mostly server-side. Uhhh... what? Sun pushed for Java for _everything_, and they were hugely successful in doing so. > For developers, then, choosing a language is like choosing citizenship in a country. You’re not only buying into syntax and semantics. You’re buying into economics and culture, the rules that shape how you earn your livelihood and the forces that channel your hopes and dreams. Learning a language is nothing like choosing citizenship. You can learn and use many languages in parallel. Most programmers do. This article is not good.
- AnimalMuppet 12y ago
  > > When Sun rolled out Java in 1995, everyone thought it would be a dandy tool for building browser applets that made images dance, yet its destiny was mostly server-side. > Uhhh... what? Sun pushed for Java for _everything_, and they were hugely successful in doing so. IIRC, Sun initially was thinking of Java for embedded systems. But garbage-collected embedded systems weren't going to fly in 1995 - the GC latency would be too long. True, Sun tried to push Java everywhere. But where did it wind up? "Mostly server-side" seems like a valid statement. Yeah, it could run in the browser. Yeah, it could run on your desktop. But there weren't tons of Java desktop apps that I can recall, and it kind of lost out on the browser. So, mostly server-side.
  - seanalltogether 12y ago
    Which is a shame really. Java took a gamble on visual uniformity for cross platform interfaces and lost big time there. Not to mention that applets took ages to load compared to flash apps.
  - enneff 12y ago
    > But where did it wind up? In most enterprise stacks, and powering all the apps on the majority of the world's smartphones (Android).
weinzierl 12y ago
> Google’s Go is structured to simplify the work of making > code run “concurrently,” smoothing the way for > programmers to create and juggle portions of a program > that execute simultaneously — and thus take full > advantage of today’s multicore chips and multiprocessor > machines. It's a while since I last checked out Go but I thought Goroutines were coroutines and therefore confined to a single core. Does Go provide means for true concurrency nowadays?
- teraflop 12y ago
  Go has supported "true" concurrency (distributing goroutines across cores) since at least version 1.0, and probably earlier.
  - pjmlp 12y ago
    You still need to touch GOMAXPROCS...
  - enneff 12y ago
    At least since the public release in November 2009.
- cmelbye 12y ago
  Parallelism is determined by an environment variable called GOMAXPROCS (or, set at runtime), which is the number of threads executing user-level Go code simultaneously. This includes goroutines. By default, GOMAXPROCS=1.
fleitz 12y ago
I'm not sure why he thinks this is a new thing, most widely popular languages came out of big giant monopolies, like AT&T and C, not to mention UNIX.
- bjz_ 12y ago
  From the article: > There’s nothing terribly new about spawning programming languages at large technology businesses. The dominant languages of the mainframe computer era had similar origins [..] Please read the whole thing before you post critiques regarding omissions.
PoL0 12y ago
Swift is a bluff, come fucking on. The only real advantage: it's more pleasant to the eye than Obj-C (which wasn't hard) And Go is nice, but I rather use Rust a thousand times.
- landr0id 12y ago
  > And Go is nice, but I rather use Rust a thousand times. Two different languages for two different purposes
Derbasti 12y ago
Python, Ruby, and Perl were developed by individuals, not companies. I think the article's reasoning is flawed.
PoL0 12y ago
Swift is a bluff, come fucking on. They removed parenthesis from 'if' statement WOAH. The only real advantage: it's more pleasant to the eye than Obj-C (which wasn't hard to accomplish). But seeing Tim Cook calling it "revolutionary". Pffft. Marketing bs. Rust is way more revolutionary. Go, on the other side, seems nice. I still have to give it a go (pun intended)
clay_to_n 12y ago
I really enjoyed that he explained things like code compilation in a super simplified style, but assumes the reader is familiar with the poetic style of John Milton.
findjashua 12y ago
Swift is a much better language than PHP and Javascript, which the author compares it with. I don't think he's actually used any of the languages he's talking about.

70 points by steven 12y ago

bsg75 12y ago

This mistake happens a lot: Go is not a "Google" language in the sense of corporate ownership. Development is sponsored by Google, but control is left in the community. This is on the opposite end of the spectrum from Swift which is controlled by Apple, which is not necessarily a bad thing depending on your perspective.

ChikkaChiChi 12y ago
Absolutely spot on, but it's damn near impossible talking to a non-programmer about Go without biting your tongue every time you almost say 'Google'
robert_tweed 12y ago
The article doesn't say that. However, Go did originate at Google and the points the article makes about it having been designed to solve specific problems at Google are all true. It was not originally intended to be a widely-used general-purpose language: it just happened to catch on after it was released publicly. Furthermore, the most significant contributors to the language design and its evolution (Rob Pike, Russ Cox, Andrew Gerrand, Brad Fitzpatrick, etc.) are all employed by Google. It's not at all unfair or misleading to call it "Google's" in the way the article does.
- exch 12y ago
  Not sure why you are getting down voted. These are all valid points.
- Animats 12y ago
  Go, as it stands, is intended for getting good performance in server-side applications. There's good support for huge numbers of simultaneous network connections, and no standard GUI support. Google needed something; C++ has too many memory problems and Python is too slow. Facebook uses PHP for much of their server-side stuff. They did a PHP compiler to make that tolerably fast. Mozilla's Rust has potential, but I'm not convinced they have the "owning" logic right. Supposedly 10% of the code in Servo, their browser renderer, is "unsafe". That's far too high. They've had their first good big idea, but I think they're one or two key concepts short of definitively solving the problem of memory safety without garbage collection. Swift I don't know about. Interestingly, these are all hard-compiled languages. Most of the "flexibility" of scripting languages has been removed. It seems that the one scripting language feature programmers really wanted type inference for local variables. That's a feature of Go, Swift, Rust, and PHP. Even C++ has that now, with "auto". (Writing iterator type declarations in C++ FOR statements was a huge pain.) It's almost better if function parameters have hard types; you can look at the function definition and see what it wants. Python and JavaScript leave you wondering "what type is parameter 3 supposed to be, anyway?" There's some syntactic convergence, too. Go, Rust, and Swift all use C-type brackets. Python indentation style control structure didn't catch on. We're also converging on "name: type", instead of C's "type name" form. That was a design mistake in C; the language became context-sensitive when "typedef" was added and the compiler had to known which words were type names. Where to put semicolons, though, is not converging.
  - erickt 12y ago
    There are two things going on in Servo that are causing it to use a lot of unsafe { ... } blocks. First, it still depends on a large amount of large c libraries, like SpiderMonkey for JavaScript. We automatically treat c foreign functions as unsafe as we can't protect against them doing unsafe things. Second, the DOM is very much built on an object oriented class hierarchy, and we in rust have put off figuring out how we can support that until after 1.0. So Servo uses unsafe code to hack around our temporary lack of support for that feature. So while there may be a lot of unsafe blocks, it should only be for the short/medium term.
  - Someone 12y ago
    "It seems that the one scripting language feature programmers really wanted type inference for local variables." Other features that I would put in that category: - string interpolation - a repl-like environment (fast startup, interactive, not requiring one to define a function or class to get some output) - convenient syntax for initializing arrays and hashes - generics as a most-of-the-time substitute for weak typing
    - Animats 12y ago
      There is convergence on hashed dictionaries as a basic type, and syntax for subarrays. Generics are still up in the air. Templates got so complex in C++ that they ate the language. Go avoids generics, but that leads to over-use of the any type ("interface{}" in Go) and reflection. Rust is somewhere in between. A REPL environment is more of a tool chain issue than a language design issue.
      - Someone 12y ago
        "A REPL environment is more of a tool chain issue than a language design issue." Moreof, maybe, but it is language design, too. If you had a Java REPL, you still would have to type quite a bit of stuff (a class and a function) before you would have your "Hello, world". Yes, you could add an implicit class named GLOBAL that magically gets a property named 'P' the moment you type P = "Hello, world"; but I would call that doing language redesign.
- threeseed 12y ago
  Completely spot on. And we know how this works in other open source projects. When you have most of the committers from one company they do ultimately drive the direction in their favour. Go for all intents and purposes IS a Google project. At least for now.
- enneff 12y ago
  > It was not originally intended to be a widely-used general-purpose language Yes, it was. That was always the intention.
  - robert_tweed 12y ago
    I stand corrected :) I'm sure I was paraphrasing Rob Pike from one of his talks describing the origins within Google.

Dewie 12y ago

This article seems to be written for non-programmers.

bigtunacan 12y ago

I see this and I just think of the Joe Armstrong post on education. http://erlang.org/pipermail/erlang-questions/2013-January/071944.html http://erlang.org/pipermail/erlang-questions/2013-January/07... So many languages to choose from; so much fragmentation while we are already experiencing a shortage of developers. I appreciate that Apple made something available other than Objective-C. I've done my share of it and personally I don't think it's a bad language, but the foreign syntax makes it less approachable to some. The sandbox mode in Xcode with Swift is great too. I just wish that instead of suffering from "Not Invented Here" syndrome that they would have chosen something that already exists. Ruby, Python, Lua, Scala, Clojure. There are so many choices, can't at least one fit the bill?

sanderjd 12y ago
I think Swift is a great language, and that creating something new that incorporates some very good ideas into a package that works well with their existing and extensive runtime made a lot of sense, but that tying it to their platform is a damn shame (though not unsurprising). I don't think the languages you list would have been a great fit, but D would have been a really good and interesting choice. Were it more mature, Rust could have also been a good fit.
- bjz_ 12y ago
  One of the big things for Apple was Objective-C compatibility, which is surprisingly hard to get right. I know because I have been trying to wrap the APIs for Rust. Don't get me wrong: I still would prefer to use Rust on iOS, but Apple has too much invested in their Objective-C APIs to force a subpar experience and migration path onto their developers.
  - sanderjd 12y ago
    You certainly know more about this than me. Do you think Rust would have been fundamentally more difficult to make compatible with Objective-C than Swift was, assuming Apple had invested the same amount of time and effort? My sense is "no", but I really don't have any clue, and I'm genuinely curious.

bencollier49 12y ago

No mention of Rust, which I think ought to have been a natural addition to the article?

sremani 12y ago
Author wanted to prove that Big Institutions build PLs so he sought languages that came out of huge corps and universities and Rust would go counter to his theory. pythong, ruby, perl were also not discussed as much. It is not a great article, probably for main-street consumption.
Dewie 12y ago
It's hard to imagine how they would go from discussing the conundrums of whether-to-use-braces-or-indentation, to discussing the merits of efficiency + memory safety. Though I guess they could have chosen to bring up the peculiar meaning of the semicolon in Rust.
- bjz_ 12y ago
  The semicolon as a statement separator is such a lovely thing that it would be hard to imagine Rust without it. It's sad to see that Swift and Go have gone with a statement based approach as opposed to emphasizing the composition of expressions. They feel very clunky in comparison.
  - Animats 12y ago
    The semicolon as a statement separator is such a lovely thing... That particular convention goes back to ALGOL-58. In ALGOL-58, semicolon is a statement separator. See page 14 of the ALGOL-58 report: http://www.softwarepreservation.org/projects/ALGOL/report/Algol58_preliminary_report_CACM.pdf http://www.softwarepreservation.org/projects/ALGOL/report/Al... C goes the other way, with semicolon as a statement terminator. 56 years after ALGOL-58, we still don't have convergence on this. Wikipedia has a table: https://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28syntax%29#Statements https://en.wikipedia.org/wiki/Comparison_of_programming_lang...

enneff 12y ago

Syntax is by far the least interesting thing about any new programming language, but they spend paragraphs talking about braces and semicolons. And the conclusions are bizarre and uninformed: > When Sun rolled out Java in 1995, everyone thought it would be a dandy tool for building browser applets that made images dance, yet its destiny was mostly server-side. Uhhh... what? Sun pushed for Java for _everything_, and they were hugely successful in doing so. > For developers, then, choosing a language is like choosing citizenship in a country. You’re not only buying into syntax and semantics. You’re buying into economics and culture, the rules that shape how you earn your livelihood and the forces that channel your hopes and dreams. Learning a language is nothing like choosing citizenship. You can learn and use many languages in parallel. Most programmers do. This article is not good.

AnimalMuppet 12y ago
> > When Sun rolled out Java in 1995, everyone thought it would be a dandy tool for building browser applets that made images dance, yet its destiny was mostly server-side. > Uhhh... what? Sun pushed for Java for _everything_, and they were hugely successful in doing so. IIRC, Sun initially was thinking of Java for embedded systems. But garbage-collected embedded systems weren't going to fly in 1995 - the GC latency would be too long. True, Sun tried to push Java everywhere. But where did it wind up? "Mostly server-side" seems like a valid statement. Yeah, it could run in the browser. Yeah, it could run on your desktop. But there weren't tons of Java desktop apps that I can recall, and it kind of lost out on the browser. So, mostly server-side.
- seanalltogether 12y ago
  Which is a shame really. Java took a gamble on visual uniformity for cross platform interfaces and lost big time there. Not to mention that applets took ages to load compared to flash apps.
- enneff 12y ago
  > But where did it wind up? In most enterprise stacks, and powering all the apps on the majority of the world's smartphones (Android).

weinzierl 12y ago

> Google’s Go is structured to simplify the work of making > code run “concurrently,” smoothing the way for > programmers to create and juggle portions of a program > that execute simultaneously — and thus take full > advantage of today’s multicore chips and multiprocessor > machines. It's a while since I last checked out Go but I thought Goroutines were coroutines and therefore confined to a single core. Does Go provide means for true concurrency nowadays?

teraflop 12y ago
Go has supported "true" concurrency (distributing goroutines across cores) since at least version 1.0, and probably earlier.
- pjmlp 12y ago
  You still need to touch GOMAXPROCS...
- enneff 12y ago
  At least since the public release in November 2009.
cmelbye 12y ago
Parallelism is determined by an environment variable called GOMAXPROCS (or, set at runtime), which is the number of threads executing user-level Go code simultaneously. This includes goroutines. By default, GOMAXPROCS=1.

fleitz 12y ago

I'm not sure why he thinks this is a new thing, most widely popular languages came out of big giant monopolies, like AT&T and C, not to mention UNIX.

bjz_ 12y ago
From the article: > There’s nothing terribly new about spawning programming languages at large technology businesses. The dominant languages of the mainframe computer era had similar origins [..] Please read the whole thing before you post critiques regarding omissions.

PoL0 12y ago

Swift is a bluff, come fucking on. The only real advantage: it's more pleasant to the eye than Obj-C (which wasn't hard) And Go is nice, but I rather use Rust a thousand times.

landr0id 12y ago
> And Go is nice, but I rather use Rust a thousand times. Two different languages for two different purposes

Derbasti 12y ago

Python, Ruby, and Perl were developed by individuals, not companies. I think the article's reasoning is flawed.

PoL0 12y ago

Swift is a bluff, come fucking on. They removed parenthesis from 'if' statement WOAH. The only real advantage: it's more pleasant to the eye than Obj-C (which wasn't hard to accomplish). But seeing Tim Cook calling it "revolutionary". Pffft. Marketing bs. Rust is way more revolutionary. Go, on the other side, seems nice. I still have to give it a go (pun intended)

clay_to_n 12y ago

I really enjoyed that he explained things like code compilation in a super simplified style, but assumes the reader is familiar with the poetic style of John Milton.

findjashua 12y ago

Swift is a much better language than PHP and Javascript, which the author compares it with. I don't think he's actually used any of the languages he's talking about.