No mention of multicore, threads, or asynchrony. I would hope that is part of this.
Those are already coming in Swift 4.
This is now unexpected to be in Swift 4 :(
Server APIs Project
131–140 of 181 posts
Re: Server APIs Project
#132Earlier quoted context omitted.
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.
In theory. I've never actually tried Excelsior or any other AOT Java compiler, so I can't comment on that. What I do know is that Swift is free and has first-class support for AOT compilation.
I think it was an error from Sun not to offer AOT in addition to JIT, but apparently they were religious against the idea, only offering it on the embedded JDKs.
This could have made Java actually relevant on the desktop, ignoring for a second how clueless Sun was about doing good desktop libraries.
However with Java 9 you will be able to use the new Java linker and create you own little VM + AOT startup code.
So that coupled with the large Java eco-system is already good enough for many of us.
Swift does compile to AOT today, but the tooling and libraries outside Apple platforms is almost insignificant, and only good enough for startups willing to bet on it.
Re: Server APIs Project
#133Earlier quoted context omitted.
Yes, but you need to bundle a JRE and the Scala library (~5 MB).
I don't know a whole lot about any of this, but isn't Swift's library bundled with iOS apps? Or is that for a different purpose, such as iOS being able to run apps that target different versions of Swift?
Yes, it's because Swift's ABI isn't stable yet.
Re: Server APIs Project
#134So what makes Swift better than Java/C# for server-side development? I'm getting tired with some languages and I'm looking for (fun) replacements. Yesterday I was reading about Elixir. Why and when should I adopt Swift?
Re: Server APIs Project
#135Earlier quoted context omitted.
> 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. Well for it's intended audience it's exactly what they want I guess, same could be said for Swift IMO. That said, Swift definitely has boarder appeal.
In which sense?
I was saying Scala was designed for a certain audience in mind, probably Haskell/OCaml devs forced to develop for Java or something like that. Similarly Swift was designed for an intended audience in mind, iOS developers, and so certain programming features would not mesh well like higher kind types.
Maybe this is more of a case of an ideal feature set as envisioned by Odersky vs' Lattner, idk. Either way different people look for different things in a language and that's all I'm saying really.
Re: Server APIs Project
#136Having spent 10 months working in Swift, this is probably the last thing on earth I want to see right now. Pretty 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.
What is it about Haskell? I'm currently heavily invested in Rust and have very briefly looked at Haskell, but find it to have some oddities that I can wrap my head around.
So I only know a minimal amount about Rust, so if there's things which are the same there, then I'll probably be blindly ignorant about them.
First thing is that with the build tool Stack and now with recent versions of Cabal the process of having a nice repeatable consistent build is pretty smooth. I also used a tool called ghcid to get sub-second feedback on my changes as I make them.
Haskell has started at the opposite end of the spectrum to most programming languages, as in "How do I represent functions mathematically?" rather than "How do I flip this bit in the accumulator register?". Which is probably somewhat to your point about oddities, for me coming from an OOP background there was a huge mental shift that had to happen to "get it". I've found that things tend to just slot together so much more easily as a result. Curried functions for example was a revelation for me, being able to pass (== 10) to a list filter isn't some special case syntactic sugar it just falls out by default.
Now much more people have gotten to grips with it there are amazing things like the servant libraries which allow you to define a HTTP service(url, query params, request method, etc.) with a type. You can implement a service against that type and get all the appropriate checks, which is great. But then the incredible part is that you can get it to create functions for each endpoint in that service totally automatically at compile time: https://hackage.haskell.org/package/servant-client#readme
Re: Server APIs Project
#137Earlier quoted context omitted.
> 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…
It sounds like you're used to manual reference counting in ObjC, which genuinely is a pain. Swift (and modern ObjC) use automatic reference counting, which is much more robust and less dependent on autorelease pools. For one thing, class instances get released when they no longer have a strong reference -- so to answer your specific question, you can totally instantiate a class for just one iteration of a loop. Plus,…
> I personally cringe whenever I have to go back to a GC and relinquish all control over object lifecycle.
I think it is a matter of which language and which GC.
A few do offer the possibility to control allocation, and sadly a few others that were good at it died in the late 90's.
Re: Server APIs Project
#138Earlier quoted context omitted.
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…
The real problem with Scala is Java. Most of us over here in C / Ruby / Python land or .NET land have been bitten by dipping our toe into Java and now avoid it like the plague.
The only Java I have issues with is a fork called Android Java.
Re: Server APIs Project
#139Earlier quoted context omitted.
Also, most Scala deployments are "statically linked", i.e. all JAR/class files are together.
Yes, but you need to bundle a JRE and the Scala library (~5 MB).
Starting with Java 9 you will be able to trim down the JRE just for your application, with the new introduced linker.
Re: Server APIs Project
#140Earlier quoted context omitted.
What is it about Haskell? I'm currently heavily invested in Rust and have very briefly looked at Haskell, but find it to have some oddities that I can wrap my head around.
So I only know a minimal amount about Rust, so if there's things which are the same there, then I'll probably be blindly ignorant about them. First thing is that with the build tool Stack and now with recent versions of Cabal the process of having a nice repeatable consistent build is pretty smooth. I also used a tool called ghcid to get sub-second feedback on my changes as I make them. Haskell has started at the opp…
Minor nitpick: "(==) 0" wouldn't be syntactic sugar, but "(== 0)" is. But I agree it's a very natural consequence of the way the language is designed.