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.
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…
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.
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…
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.
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 t…
> > 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…
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.
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…
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.
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
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.
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 t…
> > 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…
> But where did it wind up?
In most enterprise stacks, and powering all the apps on the majority of the world's smartphones (Android).
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.
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…
> It was not originally intended to be a widely-used general-purpose language
> 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 pro…
Go has supported "true" concurrency (distributing goroutines across cores) since at least version 1.0, and probably earlier.
At least since the public release in November 2009.
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…
> 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.