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)
My handle on that channel is, surprisingly, the same as here, @iamjono.
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 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.
It's just my personal opinion.
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!
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).
Environments improve over time.
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.
In fact, it looks like a lot more gotchas than, for example, GNUStep...
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."
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 :-)
If you want to find great tooling, look at Java or C#, which are both excellent languages for servers.
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!
- 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?
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.
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).
As far as memory usage goes Swift does not color me impressed when compared to GC'd language:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
lol excuse me? Actually now I'm thinking, what does he mean by "Linux?" Like, Ubuntu server? Is the UI for that considered bad?
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.
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.
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.
We can start with what the author just said.
1) It saves you from crashes and other crap
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.
So typesafe!
Perfect (Swift) won, on the server side...
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?
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.
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.
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
The reason the first people jump in is because "they can". Then others follow for various reason.
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?
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.