Going to chime in a bit here...
"Avoid #if os(Linux)… When you do this, you lose all help from Xcode. It can’t do syntax checking” ... That’s not correct. Jeff was seeing the effect of something else blocking this from happening.
arc4random, yeah, it doesn't exist on Linux currently, but there are other options that are better anyway, like using TurnstleCrypto.
For Perfect, there's also a macOS app that aside from helping the process of starting projects, dependencies, building etc - it also integrates a standardized Docker Ubuntu 16 image which also hooks into Xcode so when you build it's also building in Ubuntu and therefore catches linux-specific build issues immediately.
Its cool that you can run Swift on the server, but that sure does seem like a lot of hoops to jump through, coupled with equally many gotchas. No threading on Linux, NSUnimplemented all the time, no built in random, poorly implemented foundation types, etc. seem like a lot to deal with.
It seems a more developed language/runtime (e.g. C#/F#/VB .NET or Java 8) would do a lot better with these specific requirements (typesafe, well-tooled, x-plat, server-side app) than Swift. Especially if you're going to be writing the UI in html/js/css and are thus not anchored to the Apple ecosystem anyway, Swift seems like a bizarre choice.
The author seems to like xcode quite a bit, but I don't see it as more competitive or better than any other IDE. Not to mention it does window management and the like differently from everyone else, so when you're getting into it, it feels like you have to learn IDEs, and then you need to learn xcode. I also don't understand why people are so complacent about xcode crashing all the time - if VS Code or VS or Eclipse or IntelliJ ever crashed on me I'd be pretty darn upset.
I am iOS developer and I really wanted to say swift is headache and not a good language for Server development. I want to see how it goes but as far I know it is not flexible enough. I mean if you are building a production server you really do not want to think about language issues. Like dictionary is taking 4000ms to compile (yes it is true 4s) and compilation error message which has no link with what actual error or language syntax totally changed now you need to change million of lines of code to new syntax. It might be improved in future but for now I do not think it is time to swift as server language.
I really like the language but for using it on server development nah.
I need to wait for 10 minutes or more to compile my code. I am really frustated. I am solving for 2 days Xcode 8 issues beacause it compile slow and it is really frustating as a developer. It does not matter how I write code
in a language but in swift 3 dictionaries are really mess and slow to compile and it's long way to go for swift.
Set your optimization level to -Onone & then manually set SWIFT_WHOLE_MODULE_OPTIMIZATION in user defined variables to YES. Your build times will improve greatly.
Xcode only lets you do WMO & optimizations on in the normal UX. Really bad that they don't expose this :/
Also to other people thinking about swift: don't. 200-100kloc and your build times become 5-20+ minutes. The conditional compiler is not very good either. And once your at that level of code, xcode spins it's indexer for a long time, autocomplete fails a lot and the debugger just doesn't work that well. Printing an object just spins for over a minute, and often it fails to even print the variable. Also configuring your project into many modules become painful with all the targets you have to manage.
Maybe in 4+ years when the language has matured enough and these issues start going away? And you have a build system that doesn't depend on large multimegabyte xml files that can't be written by a human. But for now, no.
It's good enough for a couple of developers doing contract apps although!
I don't think that's how whole module optimization works. From what I understand it slightly slows down compilation, but you end up with more performant apps. For this reason I think it's only used for Release builds (that's how I have it setup).
Thanks!! Done already all this. On developer forums apple developers said they messed with the Xcode so wating for next Xcode release. That's what I am talking about :(
https://forums.developer.apple.com/thread/62737
> I really wanted to say swift is headache and not a good language for Server development.
Followed by a long description about how the ecosystem is young, and not mature enough for server production dev. I don't see how it justify that the language is not good for Server development (it may or may not be, I don't know, but I don't see any point about this in your comment).
But as author is also talking about the environment and I know it will improve but if you in to this and you have large codebase than waiting 10 minutes (some times it take 20 minutes thanks to Xcode 8.2) for build compilation and with every new Xcode release and swift release things are getting change so fast that most of time it is very hard for production app quality. Also not all dependencies keeping up at that rate.
That said I really love the language but it's my opinion by looking other languages swift is not for server development and will not be successful. But that's my opinion.
How large is the codebase? I think this is usually due to type inference on dictionaries in some cases. Usually explicitly specifying the type fixes the build times.
There's a tool that will tell you how long each part of your program is taking to compile so you can find the source.
No Swift is great language and I did not like Objective-C. The headache in the sense compilation time and also shitty errors come and you do not know what that means.
It's type safe language but all the type safety comes with price and some time the code written is just sucks. Json parsing is one example of this. All the casting and all that really make code horrible.
In swift 3 they made all value types to Any and in iOS communicating between Cocoa frameworks become a really mess as all expect some objc type etc. Implicit conversion is also removed and now you have to cast String to NSString and I really mad about this my code now looks horrible huh....
I recently tried my hand in the macOS ecosystem and I must say I was positively surprised by XCode. It's "intellisence" is incredibly fast compared to VSCode.
One argument for Swift is also that Swift is used on the client almost as often as Javascript is.
> One argument for Swift is also that Swift is used on the client almost as often as Javascript is.
That can't be even slightly close to true. The amount of web code out there already dwarfs native iOS, and the majority of native iOS code out there is probably still in Objective C.
Using C#, F# or any .NET language for cross-platform server software would also be a bizarre choice when there's Java or Go which are mature and simply work.
If people like the Swift or Objective-C philosophy that's a good reason to use Swift on the server source.
The author of the article appears to know how to use a hammer so he views anything as a nail though. From his statements he comes across as a beginner in programming websites.
> "Python works okay, but I think Xcode is great because of autocomplete and syntax checks."
Well, just say that you wanted to try something new. That's a much better excuse to pick a technology.
I think that there are some great tools around for Python, and picking a language because of XCode... I think that one of the major selling point of Xamarin is that you can avoid it altogether :-)
So you speak for the author, or what? Tooling is and always has been dire for Python developers, and the productivity that comes from good tooling is absolutely a valid reason for considering a different ecosystem.
I think his point was that if you're looking for great tooling, you're not going to find it with Swift/Xcode. Right now it doesn't support automatic refactoring, has limited support for inspecting variables while debugging, and suffers from frequent partial crashes and other bugs.
If you want to find great tooling, look at Java or C#, which are both excellent languages for servers.
Sounds like it's got a bit of development to go before the language is suitable for this use case, but I must admit I'm quite excited about it.
Having recently been experimenting with Go and Rust in the same sort of space, my impression is that Go is a bit too verbose and lacking in features - definitely works and lots of people like that, but I don't find it particularly powerful. Rust is great, but I've found that web backends end up with too much code - and it's still quite a challenging language to use, though that may be my inexperience. Building iOS apps in Swift recently, I've really started to get enjoy using the language. Once the various issues are worked out, I'm optimistic about its suitability for things like that - and it's great to have more language options to play with!
I still wonder why i would use Swift in the backend.
- elixir/erlang: fault tolerance, scalability, high complexity web apps
- Node: npm already has what you need, SSR for SPAs, JS is accessible for frontend guys (sort of)
- Golang: dead-easy microservices with CLI support, single file deployments, good performance, beginner level language makes Training/hiring easy
- Rust: excellent performance and great typesystem, ideal for writing Heavy core algorithms of products and use them as libs from other languages. Also all benefits of Go (except ease-of-learning).
- ...
- swift? Given that learning languages is not an issue, why should I prefer swift over other stuff? Are there real selling points?
Reading about Swift on server side and looking at Swift server dev mailing list. It appears to me that most appropriate use case of Swift on server side is Apple platform where client side is already written in Swift.
The server side group at Apple/IBM seems mostly looking for Swift wrappers around C/C++ core technology for sockets/http/ssl related work. This might be amply sufficient for Apple or IBM developing LOB apps in Swift but I do not see how it is very convenient for generic server side applications.
I don't see how you can conclude from any of that what the most appropriate use case for Swift on the server side is. It's just what a couple of early adopters are talking about today.
For me, the case for Swift is that it is a modern language that doesn't waste half of the available memory on a tracing garbage collector.
The same goes for Rust, which has even more opportunities for low level optimization where necessary (and way superior string handling on top of it).
I can conclude that by looking at for example Go offers today vs effort of setting Swift web framework like Kitura. IMO it is far away from general purpose server side usage.
As far as memory usage goes Swift does not color me impressed when compared to GC'd language:
Adoption is not the same as appropriateness at all.
As far as memory usage goes these benchmarks are completely irrelevant. They use very little memory and they measure it in a way that is unsuitable for a memory benchmark in the first place.
The problem with tracing garbage collection is that it requires a lot (~50%) of spare memory at all times to give the GC time to catch up without slowing the program down too much.
> I can conclude that by looking at for example Go offers today...
This is the kind of argument that used to be trotted out all the time for Java and Perl before it. If we always went by what was offered today, we'd never use anything new.
I use Swift professionally and have written some Rust for fun, and like both languages a lot. I find Swift to be faster to write, not least because it's easier to manually prevent retain cycles than to write borrow-checker approved code. It's also much easier to leak memory and write unsafe threaded code in Swift, so there's a trade-off there.
I'm sure if I wrote more Rust I'd get faster at it, though I do think it has a fundamentally more complicated programming model.
For the use-case here, on a server, I think the answer is currently no. We're writing our back-end in Rust, but tried Swift first (fewer languages in the stack!), but there were just too many gotchas.
Personally, given the option, I prefer Rust over Swift. I've written a decent, if not huge, amount of both (notable, I wrote an Avro-to-Swift code generator in Rust), but written more Rust, so take this with a grain of salt.
I've found that Swift's generics have some edge cases that cause problems; there's some rough edges around build that are better in Rust; dependencies are much easier in Rust; and I like Rust's traits over Swift's protocols. That said, protocols in Swift are very cool and flexible, and I think Swift-the-language is very well designed. And of course, for macOS UI or iOS development, I'd go with Swift for the obvious reasons.
The xi editor is mostly written in Rust, but wants native UI on each platform, and therefore uses Swift for the UI on macOS. This contains an answer to your question, but also, something more subtle: that it doesn't have to be either/or.
"In server-side Swift, you don’t use interface builder, so that reduces most of your crashes to none."
You don't use that in iOS app development either unless you are completely insane or are just beginning iOS development and don't know how to make UI properly.
Interface builder, xibs and storyboards are very useful tools for even extremely large projects. Makes building and maintaining the UI extremely easy.
The idea that because a tool is easy to use is somehow indicative of the skill of the person using the tool, is completely bogus. Interface builder has a lot of advanced features for setting up complicated UI.
You could quite easily argue the opposite for someone who needlessly creates all of their UI in code rather then in interface builder.
Storyboards are wonderful if you're a lone iOS dev with little need to collaborate and great for prototyping new designs. However on large projects with plenty of git merges between multiple users I think theres a good case for avoiding.
It's definitely not a good idea to have a single or few storyboards but you can even link storyboards. In my personal opinion splitting into a storyboard per main feature/area is a good balance.
I'll chime in, having done IOS apps for many years now...I have fully given up on Interface Builder and Storyboards. I build all my UI in code and find it works MUCH better and I spend much less time fighting with the UI. I used to spend half my time fighting with interface builder to get the layout right. Move one element that something else is constrained too...f' your everything. Oh, and setting up constraints in InterfaceBuilder...don't even. Such an amateur implementation I can't even believe they shipped it. (The code implementation isn't that bad tho)
Then wire up my events, if you refactor anything...boom -- but only at runtime. Because the compiler is wired into the process, so if a method/property doesn't exist in the ViewController that InterfaceBuilder is expecting, the compiler doesn't break, your app does.
Also add in how often Interface Builder crashes XCode.
Your inability to set up constraints in IB is just that: your inability. I get very complex things done including animations in IB.
The time gained by not having to restart the app every time you tweak the UI is immense.
I generally use storyboards to set up navigation, but depending on the project I'll do the majority in code (lots of similar screens) or do every screen by hand with some common controls in code that render in IB when every screen is really different.
I am no too dogmatic about it, I will touch the subject when interviewing people but I am more interested in a balanced view than rabid hatred for either method.
When I was beginning iOS development I tried to learn it as well as I could because I though that everybody uses them because it's the "Apple way of doing things."
However just like you...when I had to start implementing constraints with it, it was the last time I ever touched that horror.
I was rejected in a job interview quite some time ago, probably because I defended encoding UI in code, instead of using Storyboard. Sometimes destiny saves you from trouble.
Most big companies (Google, Facebook, Adobe, etc.) have internal UI frameworks that you share amongst 100s of developers and dozens of projects. Your interviewer should not ding you using code to build your UI. If anything, that's a plus as it should help you have a deeper understanding of how UIKit pieces things together.
2) If you are collaborating with anyone ie. using git you can forget about them anyway unless you wanna face merge hell.
3) Interface builder is difficult to use, is definitely lacking advanced features so you'll end up putting some UI logic in the code anyway => more complexity, more error/mistake prone etc.
I have to say I'm a bit surprised to see this kind of reaction here on HN. I never thought anyone real developer would use them for anything else than just quick prototyping maybe.
I'm not insane, and was doing Cocoa programming years before iOS existed. To each his own, but I'm not willing to work on codebases that are dogmatic about _not_ using IB. Use IB where it makes sense (most places), do what needs to be done in code in code. Interface Builder was one of the selling points of development on NeXTStep...
For the first several releases of OS X, you actually couldn't build a Cocoa application without the corresponding Nibs to go with it. Apple's frameworks didn't expose all the hooks necessary to write your UI entirely in code, nor would you even want to. It's cumbersome to create a cell and then attach that cell to a NSView and then bind it to a NSWindow.
Not close to true. If you don't like using IB, that's fine and your choice. But many of us prefer using visual tools to lay out our UIs, so that we can see how it's going to look without having to compile and run the app every time and then navigate to the screen.
i get that isomorphism is very helpful long term for larger code bases, and being able to share libraries between your ios and server/backend would be very awesome, but at what cost?
there are proven server ecosystems that are going to be much less "innovation token" laiden than swift, surely?
He seems to be a pretty happy iOS developer. He likes Swift as a language (and I must say having used it in frontend dev it does have some very nice things many other languages often used for server-side development don't come with), and he loves XCode as an IDE. If for their personal use-case it does the job and isn't missing major libraries or so, I don't think why such an endeavour shouldn't be supported?
I don't think it's so much about sharing libraries - consuming and creating data is quite different, and backend and frontend work probably shouldn't be duplicated.
NB: Some of those 'features' I mean are:
- Strongly typed (compared to JS, Python, Ruby..)
- Compiles to binary which could bring benefits depending on your needs (compared to JS, Java, Scala..)
- Being very new, there's little 'legacy sillyness' in Swift 3. Comparing some PHP sites to Swift projects (Frontend, we don't use it in any backend applications yet) I can tell you which one I'd rather work with.
Both Go and Rust fit into the same niche you mentioned (statically typed, single binary, no "legacy silliness"). Both currently support the server use case better as they have more libraries and stronger concurrency primitives available. Neither has the disadvantage of poor Linux support.
While I can understand why an iOS developer might spring for using Swift for server development, I'm not sure why any backend engineer would choose Swift. There are a myriad of better choices, including those that you ruled out.
> Compiles to binary which could bring benefits depending on your needs (compared to JS, Java, Scala..)
While its not there _yet_, JEP 295: Ahead-of-Time Compilation ( http://openjdk.java.net/jeps/295 ) is active, it was just updated last week, is targeted and a priority 1 item. I have reasonable confidence that it will get there in the near future.
Programmers in general today have significant amounts of freedom to choose the toolchain, languages, libraries, and frameworks they use. That wasn't historically always true, especially because the available choices have been growing exponentially for the past 50 years. Many of us are using that freedom to put our efforts into innovating and pioneering this field to make programming easier, safer, quicker, more reliable, and in general trying to improve every possible aspect of it. I suspect the main motivation is that we just love solving problems, which is why we're still programmers to this day, but another and probably less publicly acceptable motivation is that it helps us get our job done quicker, which in turn theoretically allows us to make more money in the same amount of time, which is a no-brainer.
Honestly I feel like the big interoperability pitch that was put on NodeJS / javascript was just smoke and mirrors to sell various educational, PaaS, SaaS, consulting, etc. products. I see much the same for Swift.
Just an anecdote of mine: I am currently building deep learning software that can run in the browser and nodejs - using the same codebase. While I am sacrificing performance compared to Python, CPP, etc., the ease of setting it up and distributing the computation are worth it for me.
Well, maybe it isn't for you. I've had this conversation a few times a year for decades. I don't think there's a need to convince anyone that something new is for them. There are always early adopters for any new technology. It will mature. Feel free to jump in at any time where the cost meets your needs, or never.
The reason the first people jump in is because "they can". Then others follow for various reason.
An ecosystem is proven if there is good library support for common items, the libraries themselves are well thought out and battle tested, and if there is a good distributed knowledge base for common gotchas and issues.
These things take time and lots of people using a platform, and obviously that usage has to start somewhere, but part of being an engineer is balancing novelty with genuine improvement.
Python and the other scripting languages' regex engine is PCRE (Perl-Compatible Regular Expressions, a very mature and highly-optimized C library), while Swift's is presumably written in Swift.
arc4random, yeah, it doesn't exist on Linux currently, but there are other options that are better anyway, like using TurnstleCrypto.
For Perfect, there's also a macOS app that aside from helping the process of starting projects, dependencies, building etc - it also integrates a standardized Docker Ubuntu 16 image which also hooks into Xcode so when you build it's also building in Ubuntu and therefore catches linux-specific build issues immediately.
Anyway, my 2c.
(Full disclosure, I work on the Perfect dev team)