Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go and Swift take another step up the programming language ladder

medium.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Go and Swift take another step up the programming language ladder

#41

Post by mcphage »

adamnemecek wrote: post #32
bigtunacan wrote: post #28

Earlier quoted context omitted.

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…

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 progra…

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

Re: Go and Swift take another step up the programming language ladder

#42

Post by Someone »

Animats wrote: post #30
robert_tweed wrote: post #8

Earlier quoted context omitted.

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, Rus…

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…

"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

Re: Go and Swift take another step up the programming language ladder

#43

Post by adamnemecek »

mcphage wrote: post #41
adamnemecek wrote: post #32

Earlier quoted context omitted.

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 progra…

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

Re: Go and Swift take another step up the programming language ladder

#44

Post by jbergens »

joshstaiger wrote: post #13
bigtunacan wrote: post #5

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 m…

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.

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.

Re: Go and Swift take another step up the programming language ladder

#45

Post by bjz_ »

sanderjd wrote: post #11
bigtunacan wrote: post #5

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 m…

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 ma…

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.

Re: Go and Swift take another step up the programming language ladder

#46

Post by bjz_ »

Dewie wrote: post #18
bencollier49 wrote: post #6

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

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.

Re: Go and Swift take another step up the programming language ladder

#47

Post by bjz_ »

fleitz wrote: post #23

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.

Re: Go and Swift take another step up the programming language ladder

#48

Post by bigtunacan »

jeorgun wrote: post #12
bigtunacan wrote: post #5

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 m…

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.

Re: Go and Swift take another step up the programming language ladder

#49

Post by Animats »

Someone wrote: post #42
Animats wrote: post #30

Earlier quoted context omitted.

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…

"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 typi…

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.

Re: Go and Swift take another step up the programming language ladder

#50

Post by Animats »

bjz_ wrote: post #46
Dewie wrote: post #18

Earlier quoted context omitted.

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

Post reply on HN