Live data from Hacker News

Server APIs Project

swift.org

21–30 of 181 posts

Re: Server APIs Project

#21
post #9

Great. Great great great. A thousand times great. We've been slowly converting our iOS projects over to Swift over the past year and the results have been tremendous (a ~40% drop in LOC from ObjC, among many other benefits). Really the only language-level feature that feels missing for server development is first-class support for asynchronous/concurrent operations, but that's coming. Swift is truly a 'best of most w…

Also a significant drop in null dereferencing issues. The `if-let` syntax is brilliant.

Re: Server APIs Project

#22
post #4

Some future server APIs should include database connectors, machine learning libraries, & image/video processing. Standardize on these before everything gets out-of-hand.

But maybe that is what they suggest should be handled by web frameworks.

Is like asking WSGI api in Python to handle all those things. It just handle raw connections and is an interface for web frameworks to worry about content and not low level stuff. Maybe database connectors would be a good inclusion as well, but in Python I believe it is not part of WSGI

On the other hand, Apple has libraries for handling image and video for macOS and iOS, are written in C but Swift interfaces so easily with C, but I don't see them releasing that stuff.

Re: Server APIs Project

#24
post #2

This looks like a very organized project with well defined goals, both of which are points that will help it succeed. It seems there's a bit of a trend back toward compiled languages (Go, Rust, Swift) that don't rely on the JVM or .NET CLR to run. I think that these are all great languages, though I almost wish for something like a better, more modern, cross-platform COM to easily share libraries among the languages.…

OS/2 had its own version of COM, called SOM.

The best thing about it, was that it also supported metaclasses Smalltalk style. So one could go crazy with OO metaprogramming.

Sadly it died with OS/2.

Then there was the other multi-platform OO ABI project from Apple, Sun and IBM, Taligent. Also not that successful.

COM is ok to work with, when done from .NET or now UWP point of view. C++/CX and the recently announced C++/WinRT are still ok, even if a bit more wordy.

The real pain starts increasingly with C++ WTL, C++ ATL, C++ MFC or for the real masochists pure C with COM related macros and the COM IDL compiler.

Then there was that other thing called CORBA, which makes the initial versions of Java EE feel like being in heaven.

Re: Server APIs Project

#25
post #10
post #8

Earlier quoted context omitted.

.NET is a modern, cross-platform com with excellent Multilanguage support. And if you really hate the idea of a VM, you can do dotnet native right now on Windows - there are strong indications that straight-to-c++ compilation will be here for .NET core (cross platform) very soon.

I don't hate the idea of a VM. :) Most of the work I do runs on the CLR or JVM. I just think that in some ways it would be helpful to be easily be able to write a library in Go, for example, and use it in Rust or Swift. Or FreePascal, or anything else. I suppose it wouldn't be insanely difficult to use the C interop facilities in each language plus a bit of C as glue code to share things between them. But it would be…

Well, you could already AOT compile with NGEN, even though it isn't an optimizing compiler and requires dynamic linking.

Or Mono.

But I am with you, when Java and .NET came out, in both cases I thought it was a missing opportunity not having a full set AOT/JIT options similar to other languages.

You could get them, but NGEN required the framework to be present anyway and on Java's case the only good AOT compilers have always been commercial.

So I would remember Turbo Pascal, Delphi, Eiffel and many others with some envy.

Re: Server APIs Project

#26
post #12

Nice, but I prefer a language which runs both on client and server, because that means I can share code, and e.g. I can do prerendering on the server and stuff like that.

For many people, client == native application.

Re: Server APIs Project

#27
I wonder what happened to the rumors that Google was planning on supporting Swift on Android officially [0].

Also, are there any good tutorials/courses to get started with Swift & iOS development? (having programmed in other languages, I can pick up fast, and I've lost interest in tutorials that start out very slowly and take time to get to the point.)

[0] http://thenextweb.com/dd/2016/04/07/google-facebook-uber-swi...

Re: Server APIs Project

#28
post #9

Great. Great great great. A thousand times great. We've been slowly converting our iOS projects over to Swift over the past year and the results have been tremendous (a ~40% drop in LOC from ObjC, among many other benefits). Really the only language-level feature that feels missing for server development is first-class support for asynchronous/concurrent operations, but that's coming. Swift is truly a 'best of most w…

Swift lines of code take about 10x more time to compile compared to obj-c too. I wished for obj-c when our project started passing the ~70 kloc mark.

Re: Server APIs Project

#29

I wonder what happened to the rumors that Google was planning on supporting Swift on Android officially [0]. Also, are there any good tutorials/courses to get started with Swift & iOS development? (having programmed in other languages, I can pick up fast, and I've lost interest in tutorials that start out very slowly and take time to get to the point.) [0] http://thenextweb.com/dd/2016/04/07/google-facebook-uber-swi.…

I guess it would make more sense to support Kotlin officially, but then again it already works fine on Android.

Re: Server APIs Project

#30
What editor is everyone using for Swift?

Last time I played with Swift I stopped after XCode crashed 2 times in an hour for me. It is also very slow. But none other editors seem to support auto completion which is a deal-breaker for me. Without it it's hard to consume all the APIs.

I hope Apple can follow Rust's path by making a language server[0] for Swift, if Apple is serious about providing cross-platform support for it. This will enable better support in editors such as find definition, refactor and auto completion.

[0]: https://internals.rust-lang.org/t/introducing-rust-language-...

Post reply on HN