Chris Lattner on Swift
nondot.org
nondot.org
"I can build anything with Swift... from a social media application, all the way up to a high-performance, 3D game using Metal."
https://www.youtube.com/watch?v=nKMAV6owYh4#t=6436
He wrote this chapter (entitled LLVM) in the book, "The Architecture of Open Source Applications":
http://aosabook.org/en/llvm.html
* * *
On the general topic, I wrote this [1] a little earlier in another thread; I'm just impressed with how Apple is becoming a gaming powerhouse.
Apple is notoriously secretive. They hate saying anything ahead of time if they don't have to. They could have committed (internally) to open sourcing Swift when they started on it four years ago, but they still probably wouldn't say anything until they day it happens. If they thought they could get away with it, they'd have kept the very existence of Swift secret until the public release, but they need feedback from third-party developers at this point.
"@Ahti333 right now we are focused on finishing it up for the final release this fall."
e.g.
- Xamarin (multiplatform mobile apps)
- Unity3d (multiplatform games)
- Monogame (multiplatform games)
- Unreal Engine 4 (build system)
I guess Swift could fill the same gaps. I would especially love to be able to develop multiplatform mobile apps with swift since switching between ObjC and Java all the time is quite taxing.
There are several massive communities that use Monogame (even still use XNA) and Unity. It's huge in the indie community, and is basically how the XB1, PS4, and Vita expect you to make games for their systems. The Vita Tool Chain is mostly C#.
Sure, no one is writing AAA games that require maximum graphical capabilities in C#, those teams use C++ exclusively (often with a scripting language on top). At that point that is really the only language AAA games use if they are made from scratch, otherwise they are using an engine already made in C++.
Bastion, Magika, A.R.E.S., Dust, Fez, Rogue Legacy, Reus, and Terraria are just a few made in XNA/Mono. And looking at total sales amounts, some of those games definitely had revenues over a million dollars.
That's not including unity games like: Shadowrun Returns, Rust, Wasteland 2, and Hearth Stone. These games made very good amounts of money, again, not 100% AAA, but still industry veterans.
It feels like one of those big business vs small business issues. If you have the man power and the resources, you can go much farther much faster. But not every starting company can afford the overhead of going full C++ and Engine heavy.
So C# being 'really' popular in the AAA side of the industry is a tad misleading (though can be used as a language on top of the engine, for tools (where it is probably most used), and for tool-chain), to discount it only due to the top 33% of companies usage, is a bit unfair to the quite large and growing indie and AA crowd.
1) It did take off like wildfire on Linux as Mono
2) People claimed Mono was a trap and not to use it. Because you can never trust Micro$oft
3) personally sad this happened to an open standard language
I would be very interested if it was opened up and available for Linux.
They've also open sourced their server: https://github.com/okws/okws
If Ok-Cupid were started today I highly doubt they would do that the same way. But given when they did start it I figure they literally did not have a choice.
It's still got the same C warts that C++ does in a lot of place, but it is far simpler and less leaky than C++.
C++ is still faster and more cross platform, than objective-c
--Have done both professionallyThere's a reason why every single AAA studio uses C++ for their engines and titles. And that's the same reason why it is terrible for social media applications.
Then they put a sane, modern language on top of it many places, Actionscript at EA, Python at many other places, LUA at others, C# at others, and write in a high level language that doesn't leak abstractions like a nut milk bag.
What they mean is that the language works at high enough abstraction and feels appropriate for writing both kinds of apps.
I wouldn't want to do a social media app with Fortran, even if it's perfectly possible.
I don't know if that means "entirely written" or some parts, but they at least called attention to it.
He grew it specifically as a response to the "beard test" for programming languages.
Such is the way of Apple though.
“There is no limit to what a man can do so long as he does not care a straw who gets the credit for it.” Charles Edward Montague
An example of this is Go; they don't actually take input from outsiders (generics) and when they have had to give in to outside ideas they implement it poorly just to be different (exceptions as panic). They would rather people put in a no-op printf to avoid the unused package error rather than letting it be a warning because of their own self-righteousness.
Apple's secretive process may not be ideal, but there are far worse processes out there.
That is a non-sequitur.
The rest of your comment appears to be low-grade trolling.
Go has taken a lot of suggestions from the open source community. Check the Go 1 mailing list discussions for examples. But panic existed before the opensource release and is not a substitute for exceptions, and nobody has actually proposed a viable generics implementation. The unused variable/package thing is a fundamental to the project's goals of working well at scale, and tools like goimports alleviate the pain (sometimes the answer is tools, not language changes).
Overall I'm pretty dismayed by your characterisation of Go as an open source project. We have a lot of great contributors from outside Google and your ignorant comments do them a great disservice.
I've been programming for 30 years and have written code that is in every Linux distro, and yes I did read the Go mailing list occasionally in the early days. But if it makes you feel better to call my opinions ignorant then I hope that's working out for you.
A very strange argument from authority considering Ken Thompson is one of Go's designers...
Considering the fact that 700 people attended the inaugural Go conference, and the variety of speakers (http://gophercon.com/schedule/), I think it's safe to say that Go has gained traction far beyond the Google employee and HN "bubbles".
By keeping these discussions private, the Apple team did not need to protect their egos or their authority. We do not know who is responsible for which decisions at which points in the design, and they don't feel the need to defend their choices in public.
In fact, your premise is almost entirely incorrect. Probably 95% of Go's language design happened before it was open sourced, so it's in exactly the same situation as Swift. The Go language hasn't changed a lot since November 2009.
They keep saying they would add generics if they feel they could "do it right" but I'm starting to not believe that. I like that the language tooling is extremely disciplined and enforces even small things, like style, but this rankles a bit considering other parts of the language design seem a bit inconsistent or haphazard. Just IMO, of course.
Also I've gotta laugh at "lions den". I've been reading HNers (like yourself) broadly condemn Go for nearly five years.
And are you going to laugh all the way over to r/programming? There is some criticism on HN. Where there are no holds barred it's really brutal. I don't blame you as a Go developer for avoiding those forums.
> incorrect statements about the development timeline of go (dsymonds corrected you there).
Go authors retconned their decision making process in talks, lists, and on the web, which in terms of feeling defensive about it now is the same thing.
You said the Go team "[designed] the language in public". I pointed out that there's only a small amount of difference between the first public unveiling of Go and its current state, which you can verify for yourself.
You said the Go team "now don't want to admit their errors". I pointed out that we've admitted lots of errors, publicly, which you can verify for yourself.
Your criticisms seem scattershot and just don't make sense.
Your eagerness to bash on Go has managed to upend your grasp of logic.
If they take the Microsoft approach of being nice to schools that'd be awesome - much better to teach kids Swift than how to use Office. So if they're talking about schools, there's probably some private ones that would be interested but it'd take a crazy effort to crack teaching in schools on a wide scale.
Universities, not a chance. It might be great but it's not going to be an academic's choice of teaching language however good it might be for that.
But you're not focused on secrecy, so you can publish the lessons you've learned along the way publicly. That way, everyone, including Apple, can skip some of the mistakes. Wouldn't that be the case?
That's wrong, condescending and misses the point. Wrong because the developers were not cut off from learning what was learned by others. Condescending in the way it implies that there's a royal "we" of people that should be consulted whenever any programming language is conceived. And it misses the point because some types of learning are learned better by making the mistake yourself rather than accepting the wisdom of authorities.
Anyway, I don't see how Swift's life cycle is any different from other most other languages, except that its inevitable celebrity has been tempered by its parents' protectiveness. The number of people expressing interest in nurturing a language in its formative stages grows in proportion to its viability. Swift went from experiment to viable as soon as it got chosen as the path forward from ObjC.
> just an hour long conversation could've made a big difference
Apple has huge numbers of programmers on staff, including many compiler hackers, many kernel hackers, many with practical experience building and maintaining APIs and developer tools. They employ literally thousands of programmers who will be end users of Swift. To suggest that your opinion is more valid than theirs is hubris.
Let's say you take direct inspiration for something you're working on and you know someone's been there and thought a lot about it. Wouldn't it make sense to ask them about it? It's certainly true that some mistakes are better learned by making them yourself, but a whole lot aren't. Hell, half the time it's just stuff you're too close to see anymore.
The Swift playground is strikingly similar to many of the things we've done in Light Table. It's wonderful that Apple is taking that and running with it and I want these things to end up out there and make things better for devs. But I could've helped them skip some of the crap along the way and I've worked with other large organizations to help them do exactly that.
> To suggest that your opinion is more valid than theirs is hubris.
My opinion is no more valid, but given that their work looks fairly like our own, I certainly have the benefit of past experience. This isn't about hubris. I have a unique perspective in this particular case, one that no one else will have, as the creator of one of the things they were "heavily influenced" by. I'd rather they took advantage of that so that they can continue to push things even further and not fall into some traps that we did at Microsoft and with LT itself.
In any case, I'm sorry I seem to have offended you. My goal is not self aggrandizement, it's just to help do my part in making things better for us all.
Also with Javascript and browsers' built in consoles you can have good times developing interactively
Obviously there is a lot of feature influence between languages but it was interesting to see the ones he called out explicitly.
"Looking forward to next month: I'll be the first and only guy with 4 years of swift programming experience :-)"
https://mobile.twitter.com/clattner_llvm/status/473835365137...
I'll be cynical here: can this be done if the language ends up being restricted to apple devices?
Sure it can. Students and school-children have been taught (and inspired) with proprietary systems and languages for ages.
Sure, it might not get to Windows or Linux users, but it still can reach tens of millions of kids and even universities (e.g Stanford already offers a well known iOS course with Objective-C).
I have subsequently leveraged that ObjC experience to become somewhat proficient in plain C, a skill I appreciate today and something I might never have learned otherwise.
:)
I suggest going through some detailed tutorials on building an X, so you get the feel for how views, view controllers, objects and everything all interact.
The new playgrounds look EXCELLENT for doing that! Best of luck
/// Returns true if these arrays contain the same elements.
func ==<T : Equatable>(lhs: T[], rhs: T[]) -> Bool
Works alright for dictionaries. Is there a bug tracker for Swift anywhere to report this?
Edit:
Whoops, copied wrong declaration. ContiguousArrays actually work fine, but require an extra cast. e.g.
ContiguousArray([1, 2, 3]) == ContiguousArray([1, 2, 3])
var two = [1, 2, 3]
one == two
That's because Swift checks for safety first (variable declaration).
This issue only seems to affect arrays. Strings, numbers, and dictionaries are fine.
I guess my point being that there was likely some more specific reason for why it gained momentum later.
Given that almost all of them rely so heavily on Objective-C, I expect they've had a road map for that (and XCode and the whole tool chain) for a very long time.
Given the plan is now to phase out ObjC and replace it entirely with Swift, I think it's extremely unlikely Steve didn't know about it, and endorse it.
The vast majority of developers I know completely freak out at the idea. I might as well suggest that they deadlift a car.
A few take it calmly, but don't really grasp what the stuff does or what it means.
I can probably count on one hand (maybe two?) the number of developers I know who can actually do something useful in that situation.
And that's just assembly language. Not even machine code, let alone actual hardware.
Most developers don't understand what goes on below wherever they work, and that's how it's been for a very long time.
1. The layer below has a bug that manifests at the top layer. You're not sure if your code is broke or if the stuff your code is built on is broke. I see this a lot in the Java world where people use frameworks / libraries they're sometimes not even aware of they're using and it has a bug.
2. You run into performance problems because of the things you're using at the layer below you. C++ STL containers is a good example. It's pretty much black-magic, have you ever looked at the implementation? I also see this a lot in the Java enterprise world. One of the selling points of Java is that it's monkey-coder friendly. Except when it breaks and the monkey doesn't know how things work under the hood.
Other than that, you should be fine not knowing the layer below you.
playgrounds for iPad, interface builder for iPad and finally Xcode.
Does it compile to Object-C?
"It's interesting to compare Swift and Go. One has caught up to the 1990s in language design, with the other firmly in the 60s."
Swift includes many of the language features that have been touted by the academic functional programming community for years but which have not made a large impact in industry, like algebraic data types, pattern matching, and Optionals. The designers of Go apparently looked at the past few decades of language research and decided that none of it interested them. The only really innovative parts of Go are its concurrency support, which Swift seems to be completely lacking.
They see things like func, and think Go was the first language to come up with it, when many others already had it.
First thing I thought of when I saw all the func calls, curly braces and beaks (->) was "this looks like in between Lua and Go"
After starting to dig into the book, it's pretty apparent that isn't the case
It seems like half the comments about Swift have been comparing it to languages which it superficially resembles at the syntax level. And the other half of the comments are along the lines of, "I can't stand Objective-C's brackets, this looks much better."
It's like that scene from The Matrix: "I don't even see the code. All I see is blonde, brunette, red-head." I'd have expected experienced programmers to have reached that point long ago.
0. Semantics
1. Syntax
2. Lexical syntax
3. Lexical syntax of comments"The first thing you're exposed to is its sounds and symbols.
They look & sound strange and your brain instinctively tries to make sense of them by comparing it to something you are already familiar with.
Then when you dig into it you begin learning vocabulary and grammar. You focus on that for a long time until the sounds sound less like gibberish and resemble something like what you've been practicing putting on paper.
Once you get comfortable with the constructs and stop focusing on them you can start conversing - putting more effort into what you're trying to say then how you would go about saying it.
After that then you can start picking up all the idioms, colloquialisms, cliches, double entendres, etc
Finally you can start inventing your own.
Worth noting that one of the greatest problems in software development is concurrency support and its ease of use/robustness.
It is a critical and growing issue.
In contrast, having or not having generics, optionals (in C# these are nullable types), algebraic data types (which in Go is interface, albiet minus the type set checking) make a marginal, vanishingly small difference in programmer productivity or application performance/stability.
99% of the articles about the profound importance of generics are people building nothing of interest for anyone, and it is exactly that vaguery of design that makes generics seem so important.
Concurrency, however, is everyone's problem. It is the modern programming problem. Nothing is more important.
And FWIW, all languages draw from each other, and of course they should learn from each other. It is very likely that Go influenced Swift in subtle ways, but it is obvious why that wouldn't be referenced.
But I'm actually curious as well. Given that Objective-C (and now Swift) have GCD, what language features are needed to bring concurrency up to par with Go?
I'm sort of reminded of what Microsoft did after Task Parallel Library came out with C#. People didn't pay attention too much to what MS was building until async/await came out (along with tooling support). But async/await built upon TPL. So it's probably a matter of time for Apple to do something similar on top of GCD, if they're going to do something. But I doubt it's going to look something like Go.
I think it's quite a stretch to say that people who have written articles about generics are almost never building anything of importance. The browser you used to post this comment makes extensive use of generics via C++ templates, which were well documented by their authors in order to fill a very important role (smart pointers for reference counted objects, for one).
I said 99%. The vast majority of language observations online are language tourists, and the observations are seldom practical or rational, but instead are of the "in kicking the tires and making nothing in practical, here are my thoughts".
Those sorts of posts dominate.
Generics have a place, but their importance is...overstated. Though I would quite broadly disagree with the notion that auto_ptr -- a shim on C++ -- justifies the notion of generics.
I do not agree that the importance of generics is overrated and it's one of the primary reasons I won't be using Go. I need to know what type of object I'm working with to feel comfortable when programming, and I like the reassurance from the compiler that it agrees with me that that is actually what I'm working with. I would really like Go if it had generics, but it's just too unsafe for me to use in its current form.
Don't know where you got the arbitrary "99%" statistic from.
It's not like generics are some novel, marginal concept. It's 2014 already.
What really surprises me is that Apple didn't put any concurrency features into Swift. Having a language with better block/closure support will certainly help, but imagine what they could have done with some additional work. Would have loved to have seen some support for channels and tasks a la Rust/Go/etc.
Edit: personZ's comment above says what I wanted to say, much more clearly.
dispatch_apply(arr.length, queue) {index in
arr[index] = expensive_func(arr[index])
}
Almost all Go features exist in languages since the early 80's, outside the C family.
C/C++/Ruby/Javasscript/Python/Java/C# - all fail miserably, utterly and completely at concurrency. What Go accomplishes with channels, goroutines and the "select" statement has been an eye-opener for me.
Watching people struggle with threads/mutexes/shared memory in the 21st century, or with some half-baked library, is truly sad.
I'm really surprised that all Go features have been present since the 80's - It's strange I have utterly missed a feature as basic as concurrency in those! Very interesting.
Go's channels make use of CSP theory which had as first implementation Occam.
Occam? No comment. At least Ada is being actively used in something, but Modula-2 and Occam? Seriously?
You can find any idea currently in use that was probably first academically tested out and "proven" in "Obscure-language-nobody-ever-uses-anymore-on-any-real-projects".
The fact that Go, this supposedly boring, unoriginal language is actually taking off in popularity, is for some reason a huge pain point for certain people who refuse to acknowledge that the "plebs" who don't bow before Haskell or similar are allowed to program in something they enjoy and that brings something new to the table, for them. New for them. New for corporate America, new for real projects, new for actual people getting actual work done, on actual projects, in actual companies, getting paid actual money for it.
How did Go haters ever survive the rise of Ruby, for example? A language which brought absolutely nothing interesting to the table, yet after people experienced RoR became more popular, in one month, than Occam, CSP, Modula-2, Oberon, combined, times 1000? You guys must have been foaming at the mouth for years.
Occam? Modula-2? Jesus Christ.
You think Go's success is undeserved? I can't wait to see your reactions when Swift surpasses "My-favorite-obscure-language-X" in number of people/libraries/projects using it before the next WWDC.
Are you just trolling or simply act defensively?
Nobody said anything about it being found in languages that are in popular use today. What the parent said was that those features already existed in several languages.
That those languages also had to be "popular" is just a random restriction you added. In fact it has nothing to do with the origins of the features.
Oh, and Modula-2 and Occam are hardly some obscure, unknown languages (especially back in the day). In fact, they are some of the most well known and copied languages in PL history. Even Java copied a lot from Modula-2 itself, by its designers own admission. And Occam has inspired several modern lanaguages.
>How did Go haters ever survive the rise of Ruby, for example? A language which brought absolutely nothing interesting to the table, yet after people experienced RoR became more popular, in one month, than Occam, CSP, Modula-2, Oberon, combined, times 1000? You guys must have been foaming at the mouth for years.
Juvenile stuff. Moving along.
(Btw, CSP is not a language. It's a decades old mechanism for concurrency, the one Go itself uses -- and available in other modern languages too, including Clojure. Shows how much you know about those things).
You added "popular" now, to deflect from what he said: that those features already existed outside of Go. If a feature exists for 20+ years, having it in your language is not a sign that you "copied it" from a 5 year old language.
Not to mention that he also said "almost all" features, and was replying in the context that Swift copied Go. In that context Go's concurrency is irrelevant, since Swift doesn't have the same mechanisms.
>>The Swift language is the product of tireless effort from a team of language experts, documentation gurus, compiler optimization ninjas...
Seriously? What is a "documentation guru"? What is a "compiler optimization ninja"? I find language like this so distracting and asinine that I had to stop reading. Am I the only one?
edit: judging by the downvotes, he seems to have a lot of fans. :)
(Yes, I know. I could use some downvotes.)