Great. Great great great. A thousand times great. We've been slowly converting our iOS projects over to Swift over the past year and the results have been tremendous (a ~40% drop in LOC from ObjC, among many other benefits). Really the only language-level feature that feels missing for server development is first-class support for asynchronous/concurrent operations, but that's coming.
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 think most languages thatare popular today are 'best of most worlds' for their users. For example, Scala has all the features you specified and has an even larger ecosystem of libraries for the server side.
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.
The problem with Scala is not that it has all the features of Swift, it's that it has way more. Scala developers see this as an advantage, everybody else sees that as a liability.
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.
I am terrified of working with experienced Scala developers.
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.
> 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.
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.
I work with a team of 8 scala developers of varied experience. We try to set the bar at the sweet spot of power and readability. If someone's code becomes super dense because they've gone crazy with scalaz constructs then we ask at review stage to simplify, to comment and/or educate the rest of the team. I don't think experienced coders should be irresponsibly using Scala at a level that is inappropriate for the team.
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.
I have absolutely seen it in the wild, but at least in my case it seemed to be more a case of "People who wish they were writing Haskell, but found more commercial opportunities with Scala" compared with "People who found Scala to be an improvement over Java".
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.
It's only a disadvantage if you work with people that try to use every feature for every job. Admittedly some people do this, but you'll get the same problem in many languages like c++, ruby and c# as well.
The features are great for people writing libraries, but general purpose code should usually only need a subset.
I hear that argument a lot, but it only seems to be true if you never need to look at code from outside your immediate team/project (either because you don't use it, or you use it without ever understanding it)
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.
The problem with gargantuan languages like Scala and C++ is not that some people will try to use every feature, but that everybody will use a slightly different subset.
Most reasonable people will agree on using a subset of the language but few will agree on what goes into that 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.
I need to understand all of the features to understand both your code and Bob's, especially when they interact. The point of "using a subset of a language" is having less feature interactions to understand.
Flip side is languages with such a small intellectual footprint that the moment that the problem domain / workloads shift a bit you are forced to switch to a different language.
> The problem with Scala is not that it has all the features of Swift, it's that it has way more.
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.
> The problem with Scala is not that it has all the features of Swift, it's that it has way more. Scala developers see this as an advantage, everybody else sees that as a liability.
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.
I was saying Scala was designed for a certain audience in mind, probably Haskell/OCaml devs forced to develop for Java or something like that. Similarly Swift was designed for an intended audience in mind, iOS developers, and so certain programming features would not mesh well like higher kind types.
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.
Seeing Odersky's talks, that is a gross mischaracterization of what he has said on the topic. There's a certain readable, elegant, concise style of code that is expressed very naturally in Scala, and if you take Odersky's courseras, it's very clear that it's something that was a preeminent design goal of the language.
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 real problem with Scala is Java. Most of us over here in C / Ruby / Python land or .NET land have been bitten by dipping our toe into Java and now avoid it like the plague.
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.
Method count forces multidex insanely early into
development and for people who want the best UX that
alone is a show stopper.
That's a complete non-problem. Minimal overhead of Scala is 30kB (see http://scala-android.org/) and it doesn't grow much larger even after dragging in the collections API. Every single of Google's Android compat shims is way larger.
If you need multidex (you probably don't), it's a single setting away.
Very slow compiles (contrary to what you claim).
After saving in my IDE, the plugin has incrementally compiled, ProGuarded, dexed and deployed the app to my phone before I can even grab it. That's pretty fast in my book.
Language style encourages constructs that cause GC
spikes, closures are not low overhead
Google has official recommendations on what to avoid in Java. You can follow the same rules and be fine. Closures have the same overhead as if they were written in Java.
SDK dependencies automatically meaning what? The thing AS
does for imports from AppCompat and co?
No. SDKs (and NDKs) are treated like every other dependency, which means the plugin resolves, downloads, installs and manages them automatically (see https://github.com/scala-android/sbt-android#usage). This is especially useful if you work for multiple clients that have different SDK requirements.
No need to write wrappers around Gradle scripts to run https://developer.android.com/studio/intro/update.html.
No need for setup instructions if you hand the project to a colleague.
Better instant run?
Protify existed before Google released Instant Run and is therefore more stable and mature: https://www.youtube.com/watch?v=LJLLyua0bYA
It's so seamless that people use it for live-coding Android apps.
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.
Nobody ever said that. It should still be obvious though that 30kB can't even remotely fit the method overhead you are claiming.
Look at your own link: Java => 16,306 Scala => 67,608 (Already in multidex territory)
I even read it! I suggest you do the same.
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
They are. Been there, done that.
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.
Well, it works without issues here. How many apps did you develop with the SBT-Android plugin to be so damn sure about its capabilities?
That would leave 0-5 seconds for the entire app to build, proguard, and predex (with
multidex). Not possible.
Perfectly possible. Used that for a while now.
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.
That only seems to be a proof that good marketing is more important than good technology.
One benefit Swift has over Scala is that it compiles down to LLVM and is statically linked. I still love Scala though, hands-down my favorite language to work with.
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
I base my statement on that fact that it's basically just a student working on it.
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.
I don't know a whole lot about any of this, but isn't Swift's library bundled with iOS apps? Or is that for a different purpose, such as iOS being able to run apps that target different versions of Swift?
In theory. I've never actually tried Excelsior or any other AOT Java compiler, so I can't comment on that. What I do know is that Swift is free and has first-class support for AOT compilation.
I think it was an error from Sun not to offer AOT in addition to JIT, but apparently they were religious against the idea, only offering it on the embedded JDKs.
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.
With Scala, if I want to build a distributable application, I need to bundle a JRE and the Scala library, which means that a "Hello World" installer would be around 30 MB in size. It's bad practice to assume that your user has Java installed.
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 you're talking about the currently very experimental Scala Native, my response is that comparing such a fledgling implementation to languages built from the ground up for AOT compilation and static linking is just silly.
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".)
The comparison should be updated to Swift 3. Swift syntax is more intuitive and readable than Scala. A common mistake in language design is to depart from C syntax, without substantial gain. For example, replacing {}, &&, || with other things. Swift strikes a great balance between intuition and innovation.
Some of these comparisons aren't great. The "Variable Number Of Arguments" example is better expressed in Swift with "reduce", and it's really comparing "summing an array", the varargs aspect is a minor detail of the example. The "Idiomatic Scala" example doesn't even declare a function with varargs! (yes, it uses one, but that's not really the point)
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.
Wow. They're basically identical. Scala has a bit less boilerplate sometimes, but it's also older, so I guess Swift will get syntactical sugar to catch up in time.
Neither Scala nor Apache Groovy are listed in the 8 languages Swift was influenced by on its Wikipedia page. That Groovy link was written by the Apache's Groovy PMC chairperson, and is more wishful thinking that fact.
Not as general or useful as Rust's "if let", though. Rust's "if let" affords fallible pattern matching on arbitrary types, not just on "nullable pointer types" (in Safe Rust, a "nullable pointer" is simply a regular reference wrapped in Option<>).
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.
I wouldn't say Swift is simpler than Rust. The complexity is just in different places. For instance, Swift leans on OO quite heavily (as it has to for compatibility with Objective-C), and as a result its typechecker is quite a bit more complex: it's a full constraint solver as opposed to Rust's typechecker, which has a much simpler "expansion/contraction" heuristic. Of course, on the other hand, Rust has the whole lifetime system that complicates things.
Yeah totally agreed. Swift is rife with way more special behaviours/magic to try to smooth over sloppy programming and just make stuff work. There's even a standard term for pushing a problem into the compiler: compiler heroics. Where heroics fall down, the language needs extra annotations to help the compiler out (@escaping closures is the most obvious).
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.
It usually means "good", though some people use it in an ironic sense to imply something is bad. Kinda like how "bad" can also mean "good" in the right context, but in reverse.
> If not, I don't see a huge amount that it actually improved over C++.
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++.
> One advantage, from the point of view of someone that likes using C++, is being a safer programming language.
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?
It sounds like you're used to manual reference counting in ObjC, which genuinely is a pain. Swift (and modern ObjC) use automatic reference counting, which is much more robust and less dependent on autorelease pools. For one thing, class instances get released when they no longer have a strong reference -- so to answer your specific question, you can totally instantiate a class for just one iteration of a loop. Plus, Swift makes much better use of value types, so you're less reliant on heap allocations in the first place.
I personally cringe whenever I have to go back to a GC and relinquish all control over object lifecycle.
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.
Remember that the Swift compiler is way smarter than Objective-C's. Given how dynamic the language is compared to Swift, Objective-C can make very few decisions at compile-time (inlining, static binding, de-virtualization, strict type checking, etc.).
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.
Most of the compile time issues comes from type inference (exponential algo!), a really simple file based incremental compilation logic system and generic / struct specialization. If you could make a version of swift that turns off those two features and improves incremental compilation then it would probably be pretty good.
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.
Some anecdata: I'm working on a 100k+ LOC Swift project and I can confirm, compilation is a dog and much of my day is spent getting myself back on track after waiting for compiles to finish.
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.
This looks like a very organized project with well defined goals, both of which are points that will help it succeed.
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.
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.
I've mostly used COM from .NET, and as you said, it's fairly painless.
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.
I still go back and dip into Essential COM now and again. I bought my copy because I was involved with a project to build a COM/CORBA bridge and needed to get my head around COM's infrastructure. Also back in the day I used to write a lot of code that ran under Microsoft Transaction Server (MTS) and COM+.
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?:
OPC UA (IEC 62541) provides a robust platform-neutral information model, and multiple options for transport. Similarly, it specifies events, subscriptions, discovery and several higher-level abstractions (e.g. alarms and programs). In some sense, it's a cross-platform successor to COM/DCOM.
Some open source implementations are incomplete, but work continues.
.NET is a modern, cross-platform com with excellent Multilanguage support. And if you really hate the idea of a VM, you can do dotnet native right now on Windows - there are strong indications that straight-to-c++ compilation will be here for .NET core (cross platform) very soon.
I don't hate the idea of a VM. :) Most of the work I do runs on the CLR or JVM. I just think that in some ways it would be helpful to be easily be able to write a library in Go, for example, and use it in Rust or Swift. Or FreePascal, or anything else.
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.
Well, you could already AOT compile with NGEN, even though it isn't an optimizing compiler and requires dynamic linking.
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.
> 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.
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.
Last time I messed with Swift, I was using a vim plugin based on SourceKitten[1] but it was a couple months ago over a weekend and I honestly can't remember how well it worked. If you were inclined, it seems like it'd get you most of the way to a language server.
I'm an XCode user myself, but I know people who swear by AppCode by Jetbrains. I tried it in the past for Objective-C and if their support for Swift is as good, it should be a decent alternative.
Great question, I'm interested in the responses as well. I'm using XVim with Xcode, but it's horrendously unstable and much slower than it needs to be.
I have been following Rust's push into server-side development and can tell it is still green. There is a great foundation with the hyper library but quite a bit of fragmentation with frameworks and the async side of things.
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 like that they are taking the same sort of mantra as Node.js by providing the core building blocks and letting the community develop web frameworks. This was something that Ryan Dahl got absolutely right with Node, minimal functionality, sugar on top of system calls.
Having spent 10 months working in Swift, this is probably the last thing on earth I want to see right now.
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.
What is it about Haskell? I'm currently heavily invested in Rust and have very briefly looked at Haskell, but find it to have some oddities that I can wrap my head around.
So I only know a minimal amount about Rust, so if there's things which are the same there, then I'll probably be blindly ignorant about them.
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
Without parentheses, == is infix. (== 10) is an "operator section", and applies 10 to the second parameter of ==. (10 ==) would be the first parameter.
I usually start learning a new programming language making various GUI programs, maybe using a library like SDL if needed.
But I can't seem to find anything like SDL for swift on linux! Most beginner resources assume you're using XCode on a Mac.
Or does Cocoa work on Linux too(last time I checked this is highly not plausible)?
I wonder what happened to the rumors that Google was planning on supporting Swift on Android officially [0].
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.)
As far as I understand Kotlin is reliant on Java Standard Library and is dependent on Java infrastructure(maven, jvm, xml and friends), which makes no sense for me as an iOS developer and can only benefit Java developers as it was mentioned earlier.
Just not with Xcode projects? I was looking for something like xcodebuild that I could run in a docker container and never found anything. Can you point me in the right direction?
Has anyone here made a living/killing selling compiler modification services? I want to contribute to Rust/Swift/Some other language with a view of selling consulting services. Can anyone here comment about their success in this regard?
So what makes Swift better than Java/C# for server-side development? I'm getting tired with some languages and I'm looking for (fun) replacements. Yesterday I was reading about Elixir. Why and when should I adopt Swift?
What is your opinion on Elixir as a next generation with the OTP approach?
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.
I've seen people try to recreate Erlang/OTP in Java. See OpenCloud Rhino. They never really get there. It's kind of sad to watch.
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.
There are millions of lines of enterprise Java code running these days and a good chunk of these are using Java EE.
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.
Now, please, try to think about to what degree (how many orders of magnitude) the Whatsapp ecosystem, which has been build on top of OTP, are more efficient in terms of data throughput, resource usage (both memory and CPU cycles wasted on thread scheduling and looking and busy waiting) and reliability (think of Facebook Messanger too), how many times less lines of code it has, to what degree the code is less verbose, less repetitive and hence more readable and maintainable.
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 .
I do not have Java sources.
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?
Yes, WhatsApp. Of course. The only successful platform using Erlang (although to what extent, not quite clear). What's also not clear is whether that platform would have been more successful or easier to design with another technology. We'll never know.
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.
But maybe that is what they suggest should be handled by web frameworks.
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.
Nice, but I prefer a language which runs both on client and server, because that means I can share code, and e.g. I can do prerendering on the server and stuff like that.
That depends a bit on what you define as prerendering. Facebook, Google and many others render client views server side (or as much as possible). See Spotify's recently open sourced HubFramework for example for how they do that with iOS. Having multiple languages doesn't preclude you from doing clever things like that and having a single language doesn't necessarily allow you to do it either.
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.