> let data[String: Any]
So typesafe!
Building a Production Server Swift App
41–50 of 91 posts
Re: Building a Production Server Swift App
#42Earlier quoted context omitted.
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…
Interesting. Do you think Swift isn't as good a language as Objective-C? Or a headache in what way?
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....
Re: Building a Production Server Swift App
#43> "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.
Re: Building a Production Server Swift App
#44"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.
Am I missing a joke here? 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…
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.
Re: Building a Production Server Swift App
#45Sounds 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!
Re: Building a Production Server Swift App
#46Earlier quoted context omitted.
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.
I think he's talking about the proportion of swift that runs on the frontend vs. backend. The comparison is like JS in your browser vs. node
Re: Building a Production Server Swift App
#47Going 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.
Anyway, my 2c.
(Full disclosure, I work on the Perfect dev team)
Re: Building a Production Server Swift App
#48Reading 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.
Re: Building a Production Server Swift App
#49"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.
Am I missing a joke here? 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…
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.
Re: Building a Production Server Swift App
#50Reading 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…
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).