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

121–130 of 181 posts

Re: Server APIs Project

#121

Post by flukus »

karim wrote: post #111
flukus wrote: post #109

Earlier quoted context omitted.

It's only a disadvantage if you work with people that try to use every feature for every job. Admittedly some people do this, but you'll get the same problem in many languages like c++, ruby and c# as well. The features are great for people writing libraries, but general purpose code should usually only need a subset.

The problem with gargantuan languages like Scala and C++ is not that some people will try to use every feature, but that everybody will use a slightly different subset. Most reasonable people will agree on using a subset of the language but few will agree on what goes into that subset :)

> Most reasonable people will agree on using a subset of the language but few will agree on what goes into that subset :)

Why is that a problem? Different people/teams will have different needs.

If I'm working on a problem where generics is a good fit and bob across the office is working on more business code where it isn't a good fit then it makes sense that we would both be using a different subset of the language.

Re: Server APIs Project

#122

Post by pjmlp »

duaneb wrote: post #70
pjmlp wrote: post #68

Earlier quoted context omitted.

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

No, because in C++ they are optional.

If you work in a team or use libraries, specially binary ones, you have zero guarantees that the code quality and how the memory is managed.

In Swift, RC is compulsory and manually managing memory requires asking the compiler for permission all the time, so there are minimal set of guarantees how the memory will be managed.

Modern C++ is great, and many in the community do push a lot for improving the quality, unfortunately I keep seeing the working enterprise developers just outputting C code compiled with a C++ compiler instead.

Re: Server APIs Project

#123

Post by panic »

K0nserv wrote: post #13
amelius wrote: 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.

But Swift does run on both the client and the server. Not when the client is web, but when the client is an iOS or macOS app.

Good luck pre-rendering a UIKit app on your server, though.

Re: Server APIs Project

#124

Post by tatterdemalion »

flukus wrote: post #121
karim wrote: post #111

Earlier quoted context omitted.

The problem with gargantuan languages like Scala and C++ is not that some people will try to use every feature, but that everybody will use a slightly different subset. Most reasonable people will agree on using a subset of the language but few will agree on what goes into that subset :)

> Most reasonable people will agree on using a subset of the language but few will agree on what goes into that subset :) Why is that a problem? Different people/teams will have different needs. If I'm working on a problem where generics is a good fit and bob across the office is working on more business code where it isn't a good fit then it makes sense that we would both be using a different subset of the language.

I need to understand all of the features to understand both your code and Bob's, especially when they interact. The point of "using a subset of a language" is having less feature interactions to understand.

Re: Server APIs Project

#125

Post by dman »

karim wrote: post #111
flukus wrote: post #109

Earlier quoted context omitted.

It's only a disadvantage if you work with people that try to use every feature for every job. Admittedly some people do this, but you'll get the same problem in many languages like c++, ruby and c# as well. The features are great for people writing libraries, but general purpose code should usually only need a subset.

The problem with gargantuan languages like Scala and C++ is not that some people will try to use every feature, but that everybody will use a slightly different subset. Most reasonable people will agree on using a subset of the language but few will agree on what goes into that subset :)

Flip side is languages with such a small intellectual footprint that the moment that the problem domain / workloads shift a bit you are forced to switch to a different language.

Re: Server APIs Project

#126

Post by [deleted] »

karim wrote: post #111
flukus wrote: post #109

Earlier quoted context omitted.

It's only a disadvantage if you work with people that try to use every feature for every job. Admittedly some people do this, but you'll get the same problem in many languages like c++, ruby and c# as well. The features are great for people writing libraries, but general purpose code should usually only need a subset.

The problem with gargantuan languages like Scala and C++ is not that some people will try to use every feature, but that everybody will use a slightly different subset. Most reasonable people will agree on using a subset of the language but few will agree on what goes into that subset :)

[deleted]

Re: Server APIs Project

#127

Post by rayshan »

jaybuff wrote: post #104

My team at Apple is hiring in San Francisco. https://jobs.apple.com/us/search?#location&ss=47424189&t=0&s... If you're interested, please email jaybuff@apple.com with [Swift Server] in the email subject line.

FYI the job description says Seattle, Washington

Re: Server APIs Project

#128

Post by tspike »

mahyarm wrote: post #73
favorited wrote: post #60

Earlier quoted context omitted.

Remember that the Swift compiler is way smarter than Objective-C's. Given how dynamic the language is compared to Swift, Objective-C can make very few decisions at compile-time (inlining, static binding, de-virtualization, strict type checking, etc.). It can definitely get faster than it is now, but it is always going to be doing much more work than an Objective-C compiler.

Most of the compile time issues comes from type inference (exponential algo!), a really simple file based incremental compilation logic system and generic / struct specialization. If you could make a version of swift that turns off those two features and improves incremental compilation then it would probably be pretty good. Compile speeds go into the seconds when you try simple things like append 10 array variables…

Some anecdata: I'm working on a 100k+ LOC Swift project and I can confirm, compilation is a dog and much of my day is spent getting myself back on track after waiting for compiles to finish.

That said, I'm in love with the language and I'd rather wait for a compile to finish than have a server blow up because of a null pointer exception. After working on a large Python backend, it's been really nice having a compiler to watch my back.

Re: Server APIs Project

#129

Post by tspike »

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…

Great question, I'm interested in the responses as well. I'm using XVim with Xcode, but it's horrendously unstable and much slower than it needs to be.

Re: Server APIs Project

#130

Post by DanielRibeiro »

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…

Xcode 8 is more stable for swift these days.
Post reply on HN