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…
Server APIs Project
71–80 of 181 posts
Re: Server APIs Project
#72Pretty much every part of the entire toolchain has been a pain, from Xcode being Xcode, to compiler bugs and crashes, crappy package management and bad language design.
Having built servers in Java/C#/Scala/Haskell, I'd pick Haskell over those options and Swift every single time.
Re: Server APIs Project
#73Earlier quoted context omitted.
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.
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.
Compile speeds go into the seconds when you try simple things like append 10 array variables with a + operator because of type inference!!
Swift if a nice language otherwise. Most iOS devs & tooling are small teams creating projects that are around 30-50 kloc of code total. It works ok then, but when you get to 100kloc sizes, all of that fancy stuff is a relative waste in comparison to compile speed and xcode's indexer crashing and dying all the time.
Backend server projects usually have codebases that are far larger than clients after a while, so I worry about using it in the backend like that.
Re: Server APIs Project
#74Nice, 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.
Re: Server APIs Project
#75Earlier 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).
Re: Server APIs Project
#76Earlier quoted context omitted.
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).
I am aware of that, but it's not a fair comparison.
Re: Server APIs Project
#77Dumb question: I'd love to learn more about Swift and try out writing Swift code, but is development still limited to XCode/macOS?
You can play with swift on linux via docker too. https://github.com/swiftdocker/docker-swift I'm one of the maintainers :)
Or does Cocoa work on Linux too(last time I checked this is highly not plausible)?
Re: Server APIs Project
#78Re: Server APIs Project
#79Earlier 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…
Please have a serious look at Swift. I don't think this claim stands up to any kind of scrutiny.
Swift is more like C++ than anything else in terms of features, Kotlin has roughly the same amount of features as Scala but more special-cased ones. Kotlin solves one problem well, and only that one: If you want to write Java, but want it to be a bit less verbose, then Kotlin is perfect.
Re: Server APIs Project
#80Earlier 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.
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.