Perfect – Server-Side Swift | Hacker News Reader

Perfect – Server-Side Swift

perfect.org

63 pointsclarle61 comments

Swift, especially with its recent developments, is a hugely promising language for building servers. Type safety? Check, with great type inference. Like functional programming? Functions are first class citizens. Immutable data structures? Available and always encouraged. OO? Classes are there. Structs, kickass enums and interfaces? Fine by Swift. Predictable memory management? Check, ARC rocks. Plus lots of nice language features like guard, do/try, optionals, etc.

Really the only thing that's missing as a language feature is some kind of concurrency support, though I'm hopeful future iterations will include this. In the mean time, it might be a bit of a blocker for serious server-side adoption.

Reflection sucks in swift which makes many web patterns tedious to implement.

Ya, I was just gonna post this. Scala has more powerful generics and an eco-system of, oh I don't know, every java library ever created. It's also got the Play framework and Akka. When it comes to rationally planned web development, Swift is very low on the totem pole and a bunch of cute language features aren't gonna change that.

Swift's biggest advantage over Scala is its tight coupling with a commendable IDE. Perfect doesn't seem to address how debugging a server-side app will work with Xcode…

I agree with you and that's a nice rebuttal. I use XCode daily since I code in Swift for an iOS project. Great tool. However, I really wouldn't trade so much away just to stay in the same IDE and I certainly wouldn't construct a plan to do so. All the people down-voting me are just Swift fanatics who probably haven't touched the language all that deep. Good language, love the replacement for Objective-C, and you could argue GCD makes Akka unnecessary (though I wouldn't go that far), but again not fit for web development in my humble opinion..

XCode (for ObjC) is very commendable for no longer crashing every 5 minutes, other than that its pretty crappy compared to other IDEs created by multi-billion dollar companies (even some open source IDEs are better)

When working in swift it's as if someone rewrote the thing in Java. As obnoxious as eclipse can be, it at least code completes in a reasonable time.

I don't know, most people I know use XCode only for drag and drop quick UI stuff and for actual development they use AppCode (also supports Swift 2).

Doesn't reflection make lots of things harder to debug and understand? Why should one need to take on the ugly patterns of other ecosystems? It also kills many of the good points of statically typed languages - ie. type safety, ease of optimization, and performance.

Calling "reflection" an ugly pattern is like calling onions a bad recipe. It's up to you how you intend to use it, but please, let's not be ridiculous and call it an "ugly pattern of other ecosystems."

Reflection doesn't get in the way of type safety (in fact, it's generally supported by it) and "ease of optimization" and "performance" is just BS. Ya, sure, sometimes reflection slows things down but web devs who use ruby for 90% of projects don't care about that. I'd love to hear you try and explain how reflection tarnishes "ease of optimization" and why it's so "ugly"

> Web devs who use ruby ...

Ruby is not a statically typed language and has nothing to do with type safety or ease of optimization. Reflection for a dynamic language is hardly the same as reflection for static language.

Good way to take a few words completely out of context. I said "web devs who use ruby for 90% of projects" as in "they obviously don't care much about performance in the first place"

If you had anything you wanted to offer, I'm all ears but you telling me dynamic vs static reflection have different implementation details (and necessarily different implications) is pretty obvious, wouldn't you agree?

I was wondering if you had more experience with Ruby than with a statically typed language like Java, and thus did not see the problem with reflection. Now, to answer your previous question, about how reflection is bad:

* Reflection allows one to dynamically add, remove and modify properties and methods, and that breaks type safety. Compilers are no longer able to prove deterministically that a certain object has certain properties or certain methods, or that certain methods have certain signatures because all those may change at runtime.

* That which can be dynamically changed must be dynamically resolved. And dynamic resolution is slower.

* It breaks encapsulation. It exposes private APIs and allows immutable objects to be modified. That is why its usage is ugly.

A dynamically typed language has much less problems with reflection, since in these languages, dynamic resolution is the norm, and they are not amenable to static analysis anyway.

It may not be statically typed, but it is strongly typed which is usually more useful than static typing.

For instance the type system in C is static but weak, creating entire classes of issues that are hard to debug that don't exist in ruby.

> but it is strongly typed which is usually more useful than static typing.

Strong typing is orthogonal to static typing and I do not believe one is more useful to another. The benefit of static typing is that you can catch many mistakes at compile time. Static typing also makes analysis and navigation of the code base easier.

> Reflection doesn't get in the way of type safety (in fact, it's generally supported by it)

Perhaps my terminology was incorrect there. It's more that it gets in the way of static verification, and makes it much harder to refactor code with confidence.

For example, I am working on a Java project at the moment, for which many constructors and methods are apparently (to the IDE's static analysis) unused. I could quite merrily delete them or change their signatures, only to have the program it break unexpectedly at runtime due to reflection expecting them to exist at the opposite end of the codebase. That is the power of static types - and reflection breaks those guarantees.

Not really, you're just operating on a higher dimension.

It's like saying multiplication makes things hard to understand...

You could write things 15 x 3 or 15 + 15 + 15, I dislike having programmers who like to do the latter on my team, or languages that make you do things like: Integer(15).multiply(Integer(3))

I'm sure that using reflection or higher order programming does cut out some people that you probably don't want anyway.

It's a higher dimension of RUNTIME fuck ups.

Leveraging the type system for COMPILE TIME dynamic programming is not only safer, but more runtime-efficient. Wanna be clever? Here you go, be type-safely clever:

https://vimeo.com/channels/flatmap2015/128466887

http://www.haskellforall.com/2012/06/you-could-have-invented...

With a good type system, you won't need reflection. If it compiles, it will work.

And give me a break on the "cut out the dumb people" part, I heard it many times from people right before they shoot themselves on a foot. Repeatedly.

As engineers, it's our job to solve problem and reduce complexity. Fail at either of the two, you have been a shit engineer.

Agreed server side swift will be awesome. My only complaint is that JSON parsing is kind of a major pain. Libraries like Argo and SwiftyJSON help, but code can still get really verbose.

Isn't that a problem with most typed languages? You're bringing in untyped data, so native types need to be spelled-out somewhere.

There's a line somewhere between excessive verbosity and dumb trust (like the YAML snafu). I haven't seen great syntax yet, though.

Agreed, it would be cool if we could specify untyped zones within a function e.g.

@untyped func parse(json: AnyObject) -> String? { /* code here is not type checked, if returned value is not type String then value will become nil */ }

Newtonsoft.Json with dynamics is really good at it in the .NET world. I usually use actual typed objects, but the DLR has enabled some cool stuff concerning dynamic input type things.

Argo is great and applicative functors are a great way of parsing in a type safe way

I think the problem is JSON. Because JSON is tied so strongly to Javascript it tends to be very ugly in any other language. I think we need a simplified (and more concise) alternative to JSON that more closely matches the way languages that aren't Javascript work.

E.g. most JSON APIs don't send arrays of primitive types (numbers, strings) around, but allowing for them makes implementing JSON nicely in non-JS languages decidedly uglier. JSON's quoting of symbols is just inefficient (it's not any other language's fault that Javascript's set of reserved words is bizarre, and in any case no-one should be "eval"ing JSON these days.)

JSON isn't ugly in languages that aren't JavaScript. It's ugly in languages which aren't dynamically typed and have poor type systems.

So it's not ugly in...?

Python, Ruby, etc

I ported Haskell's [Aeson](http://hackage.haskell.org/package/aeson-0.10.0.0/docs/Data-...) library to [Swift](https://github.com/PKAuth/SwiftAeson). You might find it helpful with verbosity and better type checking. Note that there is some hackery to satisfy Swift's type checker (and its type inference usually doesn't help too much).

Swift's concurrency story is pretty much handled by GCD. IMO a fantastic set of APIs that make it pretty easy to deal with worker threads and queueing tasks and such.

The interesting part about Swift being open sourced for linux is what API's will come with it. I would not be surprised if GCD doesn't come along.

libdispatch is Apache licensed.

Ahh nice - I didn't know that. It'll still be interesting to see what happens to the rest of the libraries and API's that are common place in Swift development

> Websites need servers to harness and share data. The languages that were developed to do this (PHP, Python, Rails, etc.)

Common misconception perhaps, but the _language_ is called Ruby, not Rails...

> What is Perfect?

> [Hype] [Hype] [Hype] [Hype] [Hype]

> Features

> - JSON encoding and decoding

Okay! Well, moving on.

I'm excited about the idea of server-side Swift and this seems to be the most ambitious implementation of it so far, but who is this awful web site targeted to? Developers? With its fading and sliding? Really?

Just give us the information without all the wank, please.

I'm intensely looking forward to Swift for Linux. I'd love to contribute more to open source iOS targeted project but I'm really unwilling to learn languages that I can't use on Linux at all because I don't want to make a Mac my daily driver.

I would of done Swift with Sails. It would of been a great pun on Ruby on Rails.

Sails is a library already for Node. (that doesn't invalidate your name, I just thought I would let you know if you didn't already).

I think Swift Aviator is a better name.

I'd like to hear from Swift Devs who also need to support Android. What does the landscape for cross development look like today, and what is the prognosis? Is open source Swift going to lead to a truly cross-platform tool set any time soon?

You don't have many choices for cross-platform tools. You can either use C++ that is quite hard for a lot of people but I would say most popular and most stable. You can use C# or Java with Xamarin but it is very expensive, unstable and it is kind vendor lock-in. You can also use JavaScript but you will lose a lot of performance that is very important on mobile. There are other options like using Lua, RubyMotion but they suffer same problems as JavaScript

Bottom line: There isn't convenient, modern, fast, open-source method for cross-platform development.

Swift bridges nicely with C and it is built on LLVM so you will be able to use it on Android with Android NDK and bridge it through JNI and Microsoft recently also adopted LLVM so you will be also able to use it there.

> Bottom line: There isn't convenient, modern, fast, open-source method for cross-platform development.

React Native

It is far from perfect, maybe one day. Currently it still suffers a lot of problems. Try to write a big application in it and you will soon discover it.

Care to elaborate?

You can use Go with gomobile https://github.com/golang/go/wiki/Mobile#sdk-applications-an... . It works okay but the lack of support for exporting slices really limits things.

> You can also use JavaScript but you will lose a lot of performance that is very important on mobile.

I've used Appcelerator Titanium fairly extensively. The performance difference vs. native code is undiscernible. Unfortunately, JavaScript is an awful language to use, so there are tradeoffs. Maybe Titanium + TypeScript would be the sweet spot.

It depends what you do but once you have a complex application you will see problems with JavaScript.

I've had the complete opposite experience with Titanium, to the point where it was completely unusable.

I found some things about it to be frustrating and buggy, but it was still less work than writing two different apps. My code was about 90% shared between devices.

How does RubyMotion suffer the same (performance) problems as JavaScript? Doesn't it compile to C# bytecode?

It actually uses the MacRuby stuff to compile to native. But the compiler can't optimize nearly as well as it can for statically typed languages, so there's a pretty significant performance hit on the ruby code itself, though once you've called a native library there won't be any difference.

> Bottom line: There isn't convenient, modern, fast, open-source method for cross-platform development.

There is ActionScript 3

even if you think that "flash is dead" in the browser, for mobile and Desktop you can use Adobe AIR

for server-side, command-line and shell scripts you use Redtamarin https://github.com/Corsaair/redtamarin

I'm the dev behind redtamarin but I welcome other projects like perfect.

Even if the tech and language are different, different pros and cons, a lot of ideas and features are shared.

You're never going to have a truly cross platform tool set. The UI/UX paradigms are just too different.

There are already several solutions for sharing library code for business logic between the platforms, either using C++, or compiling Java to Objective-C, and that's about as good as you're gonna get.

It's pretty easy, on iOS we use swift, my Android team uses java, my web team uses ruby.

I switch fluidly between rails and swift, and I leave the java dev to those who enjoy it.

I haven't really used it myself, but there is RemObjects Elements (http://www.elementscompiler.com/elements/silver/).

Maybe Apportable will eventually have Swift support.

An obnoxious name but nice work securing the domain.

Meanwhile, I'm still waiting on Apple to keep their promise of open sourcing Swift "by the end of the year"

Chris Lattner did comment less than a month ago they were still on track: https://www.reddit.com/r/swift/comments/3q2zqa/when_is_swift...

  > We are still on track to open source Swift (including Linux support)
  > "by the end of 2015" as promised, more details will come
  > out when they can.
  > -Chris

In Apple-speak "by the end of x" means "just before the end of x".

One language to rule them all. One language to find them. One language to bring them all, and in the darkness bind them?

I'm questioning their marketing message of "one language to rule them all".

This is how I complete it. I'm surprised other people don't and that I'm getting downvoted.

Reply on news.ycombinator.com