[bigdubs]

butwhy.gif

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?

[niklasrde]

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.

[echelon]

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.

[bigdubs]

You basically completed my original comment with much better clarity.

This is what I was driving at.

[shagie]

> 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.

See also: JVMLS 2015 - Java Goes AOT https://www.youtube.com/watch?v=Xybzyv8qbOc

[sdegutis]

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.

[ben_jones]

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.

[philippnagel]

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.

[melling]

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.

[optimuspaul]

Sometimes you do things just to do things. Are you never curious?

[chris_7]

The dream of a compiles-to-native-executable language with a strong compiler, probably. Rust would also apply.

[lassofreak]

One IDE, for all your code. (Especially useful for App projects)

Code sharing also equals error checking, across code.

One book/site/dictionary open at a time.

One style to remember, at a time.

What makes an ecosystem "proven"? Would you not buy an electric car, because the gas engine is proven?

[bigdubs]

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.

[matt4077]

Swift runs at the speed of C. It could be several orders of magnitude faster than ruby or python or node.

[eptcyka]

Not necessarily true https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

[lassofreak]

But it is true? https://medium.com/@rymcol/benchmarks-for-the-top-server-sid...

Perfect (Swift) kills Node.js - which means it kills other stuff (like Ruby) without question. Python would be hard tho...

[bigdubs]

Would be curious to see `perfect` on the techempower list.

[ralfd]

Interesting. Swift runs circles around Python, except Regex-DNA. Problems with string manipulations?

[smitherfield]

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.