Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Server APIs Project

swift.org

Post reply on HN
Print view View original

61–70 of 181 posts

Re: Server APIs Project

#61

Post by favorited »

grayrest wrote: post #52
octref wrote: post #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…

Last time I messed with Swift, I was using a vim plugin based on SourceKitten[1] but it was a couple months ago over a weekend and I honestly can't remember how well it worked. If you were inclined, it seems like it'd get you most of the way to a language server. [1] https://github.com/jpsim/SourceKitten

The SourceKit daemon is a language server. I wonder if anyone will adapt it to support the MS protocol.

Re: Server APIs Project

#62

Post by paulddraper »

Cyph0n wrote: post #42
sacheendra wrote: post #11

Earlier quoted context omitted.

I think most languages thatare popular today are 'best of most worlds' for their users. For example, Scala has all the features you specified and has an even larger ecosystem of libraries for the server side. I am still happy that this has been done as I know having a common API to program against does ease development and creates a great ecosystem as evidenced by node.JS.

One benefit Swift has over Scala is that it compiles down to LLVM and is statically linked. I still love Scala though, hands-down my favorite language to work with.

Scala compiles to LLVM too.

https://github.com/scala-native/scala-native

Though it's experimental (and will likely remain that way for a while).

Re: Server APIs Project

#63

Post by [deleted] »

adamnemecek wrote: post #47
duaneb wrote: post #38

Earlier quoted context omitted.

How is the memory management? That was always the downside of objective-c. Does it allow aliasing memory? If not, I don't see a huge amount that it actually improved over C++. Why should I use swift for server stuff over c++/go/rust?

> How is the memory management? Swift has both, reference types (heap allocated, refcounted) and value types (stack allocated (mostly)). Collections are copy on write which is actually really dank. You don't really think about memory management much (compared with Obj-C). And if you do, I usually wrap it in some sort of abstraction so that I can write it and forget it. The only modern language out of the three you me…

[deleted]

Re: Server APIs Project

#64

Post by erichocean »

paulddraper wrote: post #62
Cyph0n wrote: post #42

Earlier quoted context omitted.

One benefit Swift has over Scala is that it compiles down to LLVM and is statically linked. I still love Scala though, hands-down my favorite language to work with.

Scala compiles to LLVM too. https://github.com/scala-native/scala-native Though it's experimental (and will likely remain that way for a while).

Woah! That's badass. :)

Re: Server APIs Project

#65

Post by threeseed »

hota_mazi wrote: post #46
sacheendra wrote: post #11

Earlier quoted context omitted.

I think most languages thatare popular today are 'best of most worlds' for their users. For example, Scala has all the features you specified and has an even larger ecosystem of libraries for the server side. I am still happy that this has been done as I know having a common API to program against does ease development and creates a great ecosystem as evidenced by node.JS.

The problem with Scala is not that it has all the features of Swift, it's that it has way more. Scala developers see this as an advantage, everybody else sees that as a liability. Swift and Kotin manage to capture the perfect amount of "a few new features but not too many" of all languages I've played with these past ten years. They are both the perfect example of languages that hit the right compromise in many dimen…

I am terrified of working with experienced Scala developers.

The code they write is less about implementing some business functionality in the most elegant way possible. But rather it's an exercise in who can use the most obscure parts of the language.

And unfortunately there are far too many obscure parts.

Re: Server APIs Project

#66

Post by pjmlp »

Cyph0n wrote: post #42
sacheendra wrote: post #11

Earlier quoted context omitted.

I think most languages thatare popular today are 'best of most worlds' for their users. For example, Scala has all the features you specified and has an even larger ecosystem of libraries for the server side. I am still happy that this has been done as I know having a common API to program against does ease development and creates a great ecosystem as evidenced by node.JS.

One benefit Swift has over Scala is that it compiles down to LLVM and is statically linked. I still love Scala though, hands-down my favorite language to work with.

Any JVM based language can in theory be AOT compiled to native code.

There are quite a few commercial JDKs with option to AOT compile to native code.

Of course, if one wants to stay in the realm of free, the existing options aren't that great.

Re: Server APIs Project

#67

Post by vorg »

melling wrote: post #54
tormeh wrote: post #51

Earlier quoted context omitted.

Wow. They're basically identical. Scala has a bit less boilerplate sometimes, but it's also older, so I guess Swift will get syntactical sugar to catch up in time.

No, it's a lot like Groovy: http://glaforge.appspot.com/article/apple-s-swift-programmin... No, it's a lot like C#: http://swiftcomparsion.qiniudn.com

Neither Scala nor Apache Groovy are listed in the 8 languages Swift was influenced by on its Wikipedia page. That Groovy link was written by the Apache's Groovy PMC chairperson, and is more wishful thinking that fact.

Re: Server APIs Project

#68

Post by pjmlp »

duaneb wrote: post #38
ruddct wrote: 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…

How is the memory management? That was always the downside of objective-c. Does it allow aliasing memory? If not, I don't see a huge amount that it actually improved over C++. Why should I use swift for server stuff over c++/go/rust?

> If not, I don't see a huge amount that it actually improved over C++.

One advantage, from the point of view of someone that likes using C++, is being a safer programming language.

C++ has several features that allow to write safe code, but they only work when working solo, or in a team that accepts and makes use of modern C++.

If you cannot control the team on how they write C++, or the libraries being used, than there is a high probability of the code base just look like "C compiled with C++".

Of course this also applies to Go and Rust vs C++.

Re: Server APIs Project

#69

Post by pcwalton »

adamnemecek wrote: post #47
duaneb wrote: post #38

Earlier quoted context omitted.

How is the memory management? That was always the downside of objective-c. Does it allow aliasing memory? If not, I don't see a huge amount that it actually improved over C++. Why should I use swift for server stuff over c++/go/rust?

> How is the memory management? Swift has both, reference types (heap allocated, refcounted) and value types (stack allocated (mostly)). Collections are copy on write which is actually really dank. You don't really think about memory management much (compared with Obj-C). And if you do, I usually wrap it in some sort of abstraction so that I can write it and forget it. The only modern language out of the three you me…

I wouldn't say Swift is simpler than Rust. The complexity is just in different places. For instance, Swift leans on OO quite heavily (as it has to for compatibility with Objective-C), and as a result its typechecker is quite a bit more complex: it's a full constraint solver as opposed to Rust's typechecker, which has a much simpler "expansion/contraction" heuristic. Of course, on the other hand, Rust has the whole lifetime system that complicates things.

Re: Server APIs Project

#70

Post by duaneb »

pjmlp wrote: post #68
duaneb wrote: post #38

Earlier quoted context omitted.

How is the memory management? That was always the downside of objective-c. Does it allow aliasing memory? If not, I don't see a huge amount that it actually improved over C++. Why should I use swift for server stuff over c++/go/rust?

> If not, I don't see a huge amount that it actually improved over C++. One advantage, from the point of view of someone that likes using C++, is being a safer programming language. C++ has several features that allow to write safe code, but they only work when working solo, or in a team that accepts and makes use of modern C++. If you cannot control the team on how they write C++, or the libraries being used, than t…

> One advantage, from the point of view of someone that likes using C++, is being a safer programming language.

How so? Last I checked swift doesn't have garbage collection (but does have refcounting, which is nearly as good, but still requires modifying algorithms with cycles), and only offer syntactic sugar over existing null pointer semantics (as opposed to the memory ownership guarantees provided by rust). Isn't this the exact same feature set offered by modern C++ with owned_ptr and shared_ptr?

Go + rust both have guaranteed memory safety unless you go out of your way to disable safeguards. How hard is it to shoot yourself in the foot with swift, memory wise? Do you still have to fall back on autorelease pools for tight inner loops, like in objective-c?

Post reply on HN