
Go and Swift take another step up the programming language ladder - steven
https://medium.com/backchannel/my-computer-language-is-better-than-yours-58d9c9523644
======
enneff
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
> > 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.

~~~
enneff
> But where did it wind up?

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

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

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

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

~~~
Someone
_" 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
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
_" 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.

~~~
putterson
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

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

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

[http://erlang.org/pipermail/erlang-
questions/2013-January/07...](http://erlang.org/pipermail/erlang-
questions/2013-January/071944.html)

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?

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

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

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

~~~
Dewie
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_
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
_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...](http://www.softwarepreservation.org/projects/ALGOL/report/Algol58_preliminary_report_CACM.pdf)

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...](https://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28syntax%29#Statements)

~~~
bjz_
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
        };

------
weinzierl

        > 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
Go has supported "true" concurrency (distributing goroutines across cores)
since at least version 1.0, and probably earlier.

~~~
enneff
At least since the public release in November 2009.

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

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

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

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

------
Dewie
This article seems to be written for non-programmers.

------
PoL0
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
> And Go is nice, but I rather use Rust a thousand times.

Two different languages for two different purposes

