Server APIs Project
swift.org
swift.org
Swift is truly a 'best of most worlds' language. Typed, but without the boilerplate seen in a lot of typed languages. Syntax that makes sense and is consistent. Immutability strongly encouraged, but not required. OO if you want it. First class functions. Etc, etc, etc. It's truly a dream to work in, can't wait for server-side to get a little more mature.
I am still happy that this has been done as I know having a common API to program against does ease development and creates a great ecosystem as evidenced by node.JS.
http://glaforge.appspot.com/article/apple-s-swift-programmin...
No, it's a lot like C#:
Scala might have influenced Swift. Zip you go to the author's blog, he says lists those languages and says many more that he doesn't name:
The Swift function in the protocols example doesn't need to be generic, as the protocol doesn't have any associated types, and really ought to be a protocol extension regardless.
Example?
https://github.com/scala-native/scala-native
Though it's experimental (and will likely remain that way for a while).
Not so sure, the alt-Scala train is moving fast (i.e. Dotty, Scala Meta, and Scala Native).
Scala.js is already production ready; come 2019 I'd consider present day Scala deprecated, replaced by Dotty with Scala.js and Scala Native compile targets.
In fact, initial release of the Scala to Dotty Migration Tool[1] is now available
It's happening ;-)
Scala.js acquired significant community help because it has some very strong motivation: tons of software is written for browsers, and sans-plugins, browsers only run JS.
Is everything perfect? No! Can you write stuff with it and have it work? Absolutely!
There are quite a few commercial JDKs with option to AOT compile to native code.
Of course, if one wants to stay in the realm of free, the existing options aren't that great.
This could have made Java actually relevant on the desktop, ignoring for a second how clueless Sun was about doing good desktop libraries.
However with Java 9 you will be able to use the new Java linker and create you own little VM + AOT startup code.
So that coupled with the large Java eco-system is already good enough for many of us.
Swift does compile to AOT today, but the tooling and libraries outside Apple platforms is almost insignificant, and only good enough for startups willing to bet on it.
https://www.youtube.com/channel/UCdDhYMT2USoLdh4SZIsu_1g/sea...
So far I only seen the presentations.
But looking at Java 8 on this PC I would say:
jvm.dll (8 MB) + main.exe (200 KB) + trimmed down JRE
Also notice that from the presentations they have some experimental support for jlink plugins, which can further shrink down the size.
With compiled languages like Go or Swift, that same application now is 2 MB or so. On top this, the application runs natively on the OS since it is compiled to LLVM.
If not, please explain.
In Scala the language is stable, the std lib is stable and the runtime is being worked on, in Swift the language is changing heavily, the libraries are under development, but the runtime might be slightly ahead. (If one can describe reference counting as "ahead".)
Swift and Kotin manage to capture the perfect amount of "a few new features but not too many" of all languages I've played with these past ten years.
They are both the perfect example of languages that hit the right compromise in many dimensions.
The code they write is less about implementing some business functionality in the most elegant way possible. But rather it's an exercise in who can use the most obscure parts of the language.
And unfortunately there are far too many obscure parts.
Most Scala developers are in the A bracket. The experts are in the L. The code written by either is so different they could almost be different languages. You don't get this sort of split in Swift, Java etc.
All languages have this. You could write more or less the same list for Swift or Java with minimal changes.
Again, do you have any actual experience with this, or is this just your assumption? Because I have never seen this issue in the wild.
At the extreme of the first group you'd have people for whom it seemed like every problem was best solved with a higher-kinded-type. And while it might well have been technically (and mathematically) elegant, the rest of the team was left scratching their heads trying to understand it.
I think it's rather more likely that you simply don't understand why they're using the more obscure parts of the language on any given problem. They're probably trying to rule out certain invalid uses as type errors, which is typically encouraged in the more advanced typed languages.
Please have a serious look at Swift. I don't think this claim stands up to any kind of scrutiny.
Swift is more like C++ than anything else in terms of features, Kotlin has roughly the same amount of features as Scala but more special-cased ones. Kotlin solves one problem well, and only that one: If you want to write Java, but want it to be a bit less verbose, then Kotlin is perfect.
You almost never need to deal with Java except if you want to.
Plus, unlike C/Ruby/Python/.NET you get a JS backend that actually works¹ (unlike mess like GWT, or various other languages).
¹ In the sense of: Scala.js is stable, mature and production-ready. You can use it, save a lot of time, share a lot of code, use mny of the libraries you already know, enjoy great IDE and tooling support, use it in real projects and make money with it.
Deals with SDK dependencies automatically, typed resources and views, better Instant Run, ProGuard caching, extremely low overhead, fast compiles, ...
Very slow compiles (contrary to what you claim).
Language style encourages constructs that cause GC spikes, closures are not low overhead
SDK dependencies automatically meaning what? The thing AS does for imports from AppCompat and co?
Better instant run?
Method count forces multidex insanely early into
development and for people who want the best UX that
alone is a show stopper.
Here is a data point from a small example app written in multiple languages: https://github.com/SidneyXu/AndroidDemoIn4Languages
If you need multidex (you probably don't), it's a single setting away.
Very slow compiles (contrary to what you claim).
testQuick is also amazing as it runs only the tests that have failed, haven't run before or depended on code you just changed: http://www.scala-sbt.org/0.12.4/docs/Detailed-Topics/Testing...
Language style encourages constructs that cause GC
spikes, closures are not low overhead
SDK dependencies automatically meaning what? The thing AS
does for imports from AppCompat and co?
Better instant run?
...
And then you have goodies like typed resources: http://scala-android.org/tips_and_tricks-typed_resources/
Or the automated Gradle config import which means you don't need to do configure anything except adding the plugin: https://github.com/scala-android/sbt-android/blob/master/GRA...
Look at your own link: Java => 16,306 Scala => 67,608 (Already in multidex territory)
Proguard removes most of those methods, but you'll still need multidex for any non-proguard build like tests and debug builds.
And if you do grow an app past the point of being trivial as that example is Proguard gains will not be nearly as drastic
Multidex on pre-Lollipop ruins app start time, and only very specific types of apps can go to targeting minSdk 21
Predexing with Multidexing and Proguard are also slow for development for non-trivial apps. Your measure of "how long it takes to pick up a phone" is far from scientific", but to compare, not a single app non-trivial app I've worked on is so simple that installing a fully compiled APK over ADB would be less than a 5-10 second process.
That would leave 0-5 seconds for the entire app to build, proguard, and predex (with multidex). Not possible.
Gradle 2.2+ has the SDK download feature, and before that everyone I know was already using "sdk-manager-plugin", not even for convenience on dev machines (it's not that often that SDKs come out after all), but for CI builds.
Protify is not Scala exclusive if one really wants to use it, but JRebel also has a more mature Instant Run solution. Instant Run type features are useful for very specific types of changes that I don't find to be very common anyways. The layout editor + proper use of the edit mode flag and the tools namespace can already reliably replicate half of what I see instant run and co used for, with the added benefit of having even speedier development cycles.
Also: Typed resources are part of Google's databinding library, not that I know anyone who uses findViewById when we have libraries like Butterknife
To me using languages other than Java for Android dev is a risk about balancing mindshare, UX, and continued support for workflows in Android.
Kotlin has mind share, UX doesn't suffer, and it's gotten big enough that while Google has not come out officially and said it's supported, it's mindshare is large enough that Google knows that efforts like Jack and Jill cannot adversely affect workflows (The transformation API is great example, if projects like Realm, Dagger, and co didn't have so much mindshare I doubt it'd be much of a priority for the project).
Scala on Android has a much smaller mind share and is much less proven despite it's maturity, can kill UX a lot easier because of an insanely method-expensive core library which brings in thousands of methods once you use certain features, and is has not gained enough traction to to have to work around Google's plans than with them.
To me the proof is in the pudding, if there were real gains to be had with Scala it'd have more traction than it does.
Method count has nothing to do with size.
Look at your own link: Java => 16,306 Scala => 67,608 (Already in multidex territory)
And if you do grow an app past the point of being trivial as that example is Proguard
gains will not be nearly as drastic
You pay for exactly the stuff you are using, just like with every other library.
Your measure of "how long it takes to pick up a phone" is far from scientific", but
to compare, not a single app[sic] non-trivial app I've worked on is so simple that
installing a fully compiled APK over ADB would be less than a 5-10 second process.
That would leave 0-5 seconds for the entire app to build, proguard, and predex (with
multidex). Not possible.
To me the proof is in the pudding, if there were real gains to be had with Scala it'd
have more traction than it does.
Well for it's intended audience it's exactly what they want I guess, same could be said for Swift IMO. That said, Swift definitely has boarder appeal.
Maybe this is more of a case of an ideal feature set as envisioned by Odersky vs' Lattner, idk. Either way different people look for different things in a language and that's all I'm saying really.
I think there is large audience of people who want the best OOP tools, or the best FP tools or both.
The Scala community, on the other hand, got hijacked by a bunch of Haskell neckbeards who spew executable ASCII art over every codebase they get their hands on. The formation of the Scala Center feels like a response to this -- an effort to "retake" Scala.
The features are great for people writing libraries, but general purpose code should usually only need a subset.
Most reasonable people will agree on using a subset of the language but few will agree on what goes into that subset :)
Why is that a problem? Different people/teams will have different needs.
If I'm working on a problem where generics is a good fit and bob across the office is working on more business code where it isn't a good fit then it makes sense that we would both be using a different subset of the language.
In the case of Scala:
If you ever browse the standard collections library you'll run into a lot of different variance rules and implicit constraints. It is quite hard to really understand the collections library if you don't get your head around those.
If you want to use Spray for anything more complex than they spell out in their examples, then you need to understand their magnet pattern.
If you want to be able to debug a problem in Slick then you'll need to understand shapeless.
If you ever go anywhere near scalaz then you'll need to understand every esoteric symbol and operator in Scala, as well as be able to read and understand Haskell (because the patterns and types in Scalaz are often explained by reference to the Haskell equivalent)
Yes, I can set rules for my own team about what features we use internally, but I want my team to at least broadly understand the syntax and patterns used in the APIs that they interface with, which means you need to either read & understand most of the features that you aren't using internally, or avoid a very large percentage of the scala ecosystem.
if let string = thing as? String
https://spin.atomicobject.com/2016/04/26/swift-long-compile-...
https://thatthinginswift.com/debug-long-compile-times-swift/
It can definitely get faster than it is now, but it is always going to be doing much more work than an Objective-C compiler.
Compile speeds go into the seconds when you try simple things like append 10 array variables with a + operator because of type inference!!
Swift if a nice language otherwise. Most iOS devs & tooling are small teams creating projects that are around 30-50 kloc of code total. It works ok then, but when you get to 100kloc sizes, all of that fancy stuff is a relative waste in comparison to compile speed and xcode's indexer crashing and dying all the time.
Backend server projects usually have codebases that are far larger than clients after a while, so I worry about using it in the backend like that.
That said, I'm in love with the language and I'd rather wait for a compile to finish than have a server blow up because of a null pointer exception. After working on a large Python backend, it's been really nice having a compiler to watch my back.
If not, I don't see a huge amount that it actually improved over C++. Why should I use swift for server stuff over c++/go/rust?
Swift has both, reference types (heap allocated, refcounted) and value types (stack allocated (mostly)). Collections are copy on write which is actually really dank. You don't really think about memory management much (compared with Obj-C). And if you do, I usually wrap it in some sort of abstraction so that I can write it and forget it.
The only modern language out of the three you mention is Rust. Swift is very similar to Rust but a bit higher level (but it seems like the languages will converge, a lot of the planned feature are creeping into Rust space). Swift is also simpler, but this is due to the fact that it's for a somewhat different purpose. A lot of the concepts are the same modulo the syntax. Rust was a major source of inspiration after all.
Writing it feels like writing this C++, JS, Python, Haskell hybrid. It's like the first language I actually enjoy writing (Rust is a better language but I'm not quite fluent).
That being said Swift isn't perfect but I things are getting fixed really quickly.
Swift also has a lot of slightly more ergonomic but otherwise largely unnecessary features: initializers vs static funcs, guards vs ifs, throws vs returning an enum, fileprivate vs private.
Moving to working on Swift from Rust has led to me really appreciating how simple a lot of Rust really is. There's a lot of "oh it's literally just X".
But the lifetime thing is a huge empowerer of Rust being simpler everywhere else. It means a lot more stuff can be "just X", because X can be made safe.
Here I took it to mean "good."
"dank" as in "dank memes" as in "a word stoners use to describe good weed" is how I'm taking it to be used here.
One advantage, from the point of view of someone that likes using C++, is being a safer programming language.
C++ has several features that allow to write safe code, but they only work when working solo, or in a team that accepts and makes use of modern C++.
If you cannot control the team on how they write C++, or the libraries being used, than there is a high probability of the code base just look like "C compiled with C++".
Of course this also applies to Go and Rust vs C++.
How so? Last I checked swift doesn't have garbage collection (but does have refcounting, which is nearly as good, but still requires modifying algorithms with cycles), and only offer syntactic sugar over existing null pointer semantics (as opposed to the memory ownership guarantees provided by rust). Isn't this the exact same feature set offered by modern C++ with owned_ptr and shared_ptr?
Go + rust both have guaranteed memory safety unless you go out of your way to disable safeguards. How hard is it to shoot yourself in the foot with swift, memory wise? Do you still have to fall back on autorelease pools for tight inner loops, like in objective-c?
I personally cringe whenever I have to go back to a GC and relinquish all control over object lifecycle.
I think it is a matter of which language and which GC.
A few do offer the possibility to control allocation, and sadly a few others that were good at it died in the late 90's.
If you work in a team or use libraries, specially binary ones, you have zero guarantees that the code quality and how the memory is managed.
In Swift, RC is compulsory and manually managing memory requires asking the compiler for permission all the time, so there are minimal set of guarantees how the memory will be managed.
Modern C++ is great, and many in the community do push a lot for improving the quality, unfortunately I keep seeing the working enterprise developers just outputting C code compiled with a C++ compiler instead.
It seems there's a bit of a trend back toward compiled languages (Go, Rust, Swift) that don't rely on the JVM or .NET CLR to run. I think that these are all great languages, though I almost wish for something like a better, more modern, cross-platform COM to easily share libraries among the languages.
I've only had to work with COM very, very occasionally though. If I'd had to work with it for any extended period of time, I probably wouldn't be wishing for it, or anything like it. Perhaps sharing functionality between languages is better accomplished by separate services communicating via something like 0MQ.
Yeah, I think that people don't want to get back from these. The setup is more complex (as in you have to write a bunch of code) but the coupling is a lot looser.
Some open source implementations are incomplete, but work continues.
https://en.wikipedia.org/wiki/OPC_Unified_Architecture
https://github.com/open62541/open62541
https://github.com/OPCFoundation
You may also find Woopsa interesting, depending on your use cases.
I suppose it wouldn't be insanely difficult to use the C interop facilities in each language plus a bit of C as glue code to share things between them. But it would be interesting to be able to say "here's my library, and here's the interface it exports. Import it and have fun!". Though I'm sure there are lots of fun details and edge cases I'm completely failing to consider.
I'm looking forward to the .NET Core to C++ compilation! There are plenty of interesting things happening in the .NET world right now.
Or Mono.
But I am with you, when Java and .NET came out, in both cases I thought it was a missing opportunity not having a full set AOT/JIT options similar to other languages.
You could get them, but NGEN required the framework to be present anyway and on Java's case the only good AOT compilers have always been commercial.
So I would remember Turbo Pascal, Delphi, Eiffel and many others with some envy.
The best thing about it, was that it also supported metaclasses Smalltalk style. So one could go crazy with OO metaprogramming.
Sadly it died with OS/2.
Then there was the other multi-platform OO ABI project from Apple, Sun and IBM, Taligent. Also not that successful.
COM is ok to work with, when done from .NET or now UWP point of view. C++/CX and the recently announced C++/WinRT are still ok, even if a bit more wordy.
The real pain starts increasingly with C++ WTL, C++ ATL, C++ MFC or for the real masochists pure C with COM related macros and the COM IDL compiler.
Then there was that other thing called CORBA, which makes the initial versions of Java EE feel like being in heaven.
At one point, we were having issues with a COM DLL we were using from .NET, so I thought it might be fun and useful to dive in and learn more about COM. I bought Don Box's COM book, and tackled COM in Plain C: http://www.codeproject.com/Articles/13601/COM-in-plain-C
It was somewhat less fun than I'd hoped it would be.
XPCOM seems to be (somewhat) alive and kicking: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM ; Firefox and VirtualBox are the only apps I've seen that use it, though I imagine at least a few others do as well.
Another interesting book by Mr Box and co-authored by Chris Sells, purely from a historical perspective now as it's fairly ancient, is Essential .NET Vol. 1[0]. Sadly they never got around to writing a second volume.
As a humourous aside, who remembers Don's lecture he did from a bath tub?:
https://blog.mattmags.com/2011/05/19/don-box-the-bathtub-lec...
If you're interested, please email jaybuff@apple.com with [Swift Server] in the email subject line.
Last time I played with Swift I stopped after XCode crashed 2 times in an hour for me. It is also very slow. But none other editors seem to support auto completion which is a deal-breaker for me. Without it it's hard to consume all the APIs.
I hope Apple can follow Rust's path by making a language server[0] for Swift, if Apple is serious about providing cross-platform support for it. This will enable better support in editors such as find definition, refactor and auto completion.
[0]: https://internals.rust-lang.org/t/introducing-rust-language-...
It will be interesting to see where swift goes with all this. I know Rust has a lot of traction now with cross-platform support and language features, but I think swift is poised to offer a much different experience for server-side development.
I too am excited to see where this goes; Swift is a great language.
Pretty much every part of the entire toolchain has been a pain, from Xcode being Xcode, to compiler bugs and crashes, crappy package management and bad language design.
Having built servers in Java/C#/Scala/Haskell, I'd pick Haskell over those options and Swift every single time.
First thing is that with the build tool Stack and now with recent versions of Cabal the process of having a nice repeatable consistent build is pretty smooth. I also used a tool called ghcid to get sub-second feedback on my changes as I make them.
Haskell has started at the opposite end of the spectrum to most programming languages, as in "How do I represent functions mathematically?" rather than "How do I flip this bit in the accumulator register?". Which is probably somewhat to your point about oddities, for me coming from an OOP background there was a huge mental shift that had to happen to "get it". I've found that things tend to just slot together so much more easily as a result. Curried functions for example was a revelation for me, being able to pass (== 10) to a list filter isn't some special case syntactic sugar it just falls out by default.
Now much more people have gotten to grips with it there are amazing things like the servant libraries which allow you to define a HTTP service(url, query params, request method, etc.) with a type. You can implement a service against that type and get all the appropriate checks, which is great. But then the incredible part is that you can get it to create functions for each endpoint in that service totally automatically at compile time: https://hackage.haskell.org/package/servant-client#readme
Or does Cocoa work on Linux too(last time I checked this is highly not plausible)?
Also, are there any good tutorials/courses to get started with Swift & iOS development? (having programmed in other languages, I can pick up fast, and I've lost interest in tutorials that start out very slowly and take time to get to the point.)
[0] http://thenextweb.com/dd/2016/04/07/google-facebook-uber-swi...
I mean, it's useful if you absolutely have to use Java, but it's expensive and a pale imitation of Erlang/OTP. I'm confident that it will remain so until it dies.
Java EE has a much stronger success track record than Erlang/OTP does.
The trend has started moving away from it these past years but it's pretty clear that even the worst and early versions of Java EE (looking at you, EJB 2) have been used to power massive web sites and applications that are still in use today.
Erlang/OTP is nonexistent in comparison.
I could give you a hint: the whole standard library of Erlang is (including optional type declarations for each function)
schiptsov@Ideapad:~/Compile/otp/lib/stdlib/src$ du -sh .
2.6M .
Processed junk food is absolutely dominant form of human nutrition in the world. Does this fact makes junk food better than evolved (carefully selected) traditional dishes of rural communities, adapted to the local food sources and seasons?
What we know is that, like I said, the number of Java EE projects out there absolutely dwarfs the number of Erlang projects. That was my one and only point. I never compared the quality of these two platforms, I just offered a simple mind share fact.
I'm a Swift developer, I'm learning Elixir & I love OTP's model. In my opinion Apple or anyone else won't go in that direction is because it's way different & it's learning curve will push most developers away.
Standardize on these before everything gets out-of-hand.
Is like asking WSGI api in Python to handle all those things. It just handle raw connections and is an interface for web frameworks to worry about content and not low level stuff. Maybe database connectors would be a good inclusion as well, but in Python I believe it is not part of WSGI
On the other hand, Apple has libraries for handling image and video for macOS and iOS, are written in C but Swift interfaces so easily with C, but I don't see them releasing that stuff.