Go and Swift take another step up the programming language ladder | Hacker News Reader

Go and Swift take another step up the programming language ladder

medium.com

70 pointssteven53 comments

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.

> > 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.

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.

> But where did it wind up?

In most enterprise stacks, and powering all the apps on the majority of the world's smartphones (Android).

"Syntax is by far the least interesting thing about any new programming language, but they spend paragraphs talking about braces and semicolons."

I can't seem to locate the quote for this, but I believe there is a famous witticism on programming languages, which more or less states that arguments about the trivial issues of a language generate the most heated discussion, with syntax being simultaneously the most contentious and the least important.

Wadler's Law: https://www.haskell.org/haskellwiki/Wadler%27s_Law

    In any language design, the total time spent discussing
    a feature in this list is proportional to two raised to
    the power of its position.

           0. Semantics
           1. Syntax
           2. Lexical syntax
           3. Lexical syntax of comments

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.

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'

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.

Not sure why you are getting down voted. These are all valid points.

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.

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.

"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

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.

"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.

Actually, I really enjoy using Groovy as a Java REPL, when having to use Java. Your code is run in a Script class

Most java code is valid Groovy code and it has some nice dynamic features, syntax sugar and has closures. I am currently using it to hack together a small DSL to easily configure a transformation from XML -> CSV

Here's an example of a Groovy session (From my instance of IntelliJ IDEA through Tools -> Groovy Console)

  > P = "Hello world!"
  Hello world!
  > sub = P.substring(5)
  world!
  > sub ==~ / wo.+/ ? println("World") : {}()
  World

> Most java code is valid Groovy code

Up to Java 7 you could say "most" but why not "all"? Was it too difficult to test full compatibility? Why is the == slightly different between Java and Groovy, and the rest of the little differences which only confuse? And as for your example it doesn't look in the slightest like Java...

    P = "Hello world!"
    sub = P.substring(5)
    sub ==~ / wo.+/ ? println("World") : {}()

Why wasn't Groovy updated so most java 8 code is also valid Groovy code? And why didn't you actually post some code to do something useful like "configure a transformation from XML -> CSV" instead of creating a HN login to post a meaningless syntax sample?

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.

> It was not originally intended to be a widely-used general-purpose language

Yes, it was. That was always the intention.

I stand corrected :)

I'm sure I was paraphrasing Rob Pike from one of his talks describing the origins within Google.

I see this and I just think of the Joe Armstrong post on education.

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?

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.

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.

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.

None of the languages you listed have Objective-C interoperability, which is pretty crucial for their purposes.

RubyMotion is compiled, benchmarks similarly to Objective-C, is interoperable and already running in production apps for both iOS and Mac OSX.

Laurent Sansonetti also has extensive history with Apple.

I get this argument for any other company.

But at this point Apple has gone to great lengths to control the entire toolchain from the OS to the compiler to the chips that run the instructions the compiler produces.

It’d seem odd if they didn’t go with something home-grown as their language of choice.

ObjC is about as homegrown as it gets. There are few major uses of ObjC outside of Apple/NextSteps's ecosystem.

But it would be better for a lot of developers who don't want to spend a lot of time learning ObjC just for iPhones. It might also have been a safer choice for Apple since they now are in a bit of a danger if iPhone and iPad sales goes down. Then the number of developer learning their languages might fall fast and then the app ecosystem might start to fall too.

None of the languages you listed are in the same space as Obj-C.

Compiled Ruby is not new to Apple. First there was RubyCocoa, then MacRuby and now RubyMotion. So I think RubyMotion fits into the same category.

I really wasn't trying to point to any particular language here though. As one commenter pointed out, maybe D would be a closer match up. I'm not trying to say any particular language is the right decision. I'm also not trying to point the finger at Apple.

I just wonder if some of this explosion of languages that is happening right now isn't harmful in the long run.

I'm not sure what exactly you mean by "compiled Ruby". AFAIK at no point is RubyCocoa, MacRuby or RubyMotion compiled, it's still an interpreter with the Cocoa APIs exposed to Ruby.

> I just wonder if some of this explosion of languages that is happening right now isn't harmful in the long run.

I'm not sure how that would happen. I'm also guessing that someone said something similar back when say COBOL was THE programming language.

> I'm not sure what exactly you mean by "compiled Ruby". AFAIK at no point is RubyCocoa, MacRuby or RubyMotion compiled, it's still an interpreter with the Cocoa APIs exposed to Ruby.

MacRuby and RubyMotion are absolutely compiled.

Seems like you are right. TIL I guess.

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

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.

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.

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.

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/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_lang...

Oh interesting, I didn't know that ALGOL had that. Looking through the Wikipedia pages, it seems that Rust most likely gained it via the ALGOL->ISWIM->ML->Ocaml->Rust route. I hope it catches on in more imperative languages in the future. After using it for a while, statement terminated syntax feels so clunky in comparison. I love being able to break out into a block like:

    let foo = {
        /* do stuff */;
        some_expression
    };

    > 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?

Go has supported "true" concurrency (distributing goroutines across cores) since at least version 1.0, and probably earlier.

You still need to touch GOMAXPROCS...

At least since the public release in November 2009.

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.

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.

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

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.

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.

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.

This article seems to be written for non-programmers.

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.

> And Go is nice, but I rather use Rust a thousand times.

Two different languages for two different purposes

Reply on news.ycombinator.com