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

111–120 of 181 posts

Re: Server APIs Project

#111

Post by karim »

flukus wrote: post #109
hota_mazi wrote: post #46

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

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 :)

Re: Server APIs Project

#112

Post by timv »

flukus wrote: post #109
hota_mazi wrote: post #46

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

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.

I hear that argument a lot, but it only seems to be true if you never need to look at code from outside your immediate team/project (either because you don't use it, or you use it without ever understanding it)

In the case of Scala:

If you ever browse the standard collections library you'll run into a lot of different variance rules and implicit constraints. It is quite hard to really understand the collections library if you don't get your head around those.

If you want to use Spray for anything more complex than they spell out in their examples, then you need to understand their magnet pattern.

If you want to be able to debug a problem in Slick then you'll need to understand shapeless.

If you ever go anywhere near scalaz then you'll need to understand every esoteric symbol and operator in Scala, as well as be able to read and understand Haskell (because the patterns and types in Scalaz are often explained by reference to the Haskell equivalent)

Yes, I can set rules for my own team about what features we use internally, but I want my team to at least broadly understand the syntax and patterns used in the APIs that they interface with, which means you need to either read & understand most of the features that you aren't using internally, or avoid a very large percentage of the scala ecosystem.

Re: Server APIs Project

#113

Post by trevor-e »

Cyph0n wrote: post #78
paulddraper wrote: post #76

Earlier 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).

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?

Re: Server APIs Project

#114

Post by trevor-e »

steveklabnik wrote: post #95
tomjakubowski wrote: post #53

Earlier quoted context omitted.

Not as general or useful as Rust's "if let", though. Rust's "if let" affords fallible pattern matching on arbitrary types, not just on "nullable pointer types" (in Safe Rust, a "nullable pointer" is simply a regular reference wrapped in Option ).

Worth noting that we got the idea for if let from Swift :)

These are the little things I love seeing on HN. :)

Re: Server APIs Project

#116

Post by Gankro »

pcwalton wrote: post #69
adamnemecek wrote: post #47

Earlier quoted context omitted.

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

Yeah totally agreed. Swift is rife with way more special behaviours/magic to try to smooth over sloppy programming and just make stuff work. There's even a standard term for pushing a problem into the compiler: compiler heroics. Where heroics fall down, the language needs extra annotations to help the compiler out (@escaping closures is the most obvious).

Swift also has a lot of slightly more ergonomic but otherwise largely unnecessary features: initializers vs static funcs, guards vs ifs, throws vs returning an enum, fileprivate vs private.

Moving to working on Swift from Rust has led to me really appreciating how simple a lot of Rust really is. There's a lot of "oh it's literally just X".

But the lifetime thing is a huge empowerer of Rust being simpler everywhere else. It means a lot more stuff can be "just X", because X can be made safe.

Re: Server APIs Project

#117

Post by jorgengorg »

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.

Can you explain why this is such a significant benefit? Honest question.

Re: Server APIs Project

#119

Post by virtualwhys »

manojlds wrote: post #101
premium-concern wrote: post #90

Earlier quoted context omitted.

Then use Scala! You almost never need to deal with Java except if you want to. Plus, unlike C/Ruby/Python/.NET you get a JS backend that actually works¹ (unlike mess like GWT, or various other languages). ¹ In the sense of: Scala.js is stable, mature and production-ready. You can use it, save a lot of time, share a lot of code, use mny of the libraries you already know, enjoy great IDE and tooling support, use it in…

Typescript is C# in spirit

Scala.js is Scala.

Re: Server APIs Project

#120

Post by virtualwhys »

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).

> and will likely remain that way for a while

Not so sure, the alt-Scala train is moving fast (i.e. Dotty, Scala Meta, and Scala Native).

Scala.js is already production ready; come 2019 I'd consider present day Scala deprecated, replaced by Dotty with Scala.js and Scala Native compile targets.

In fact, initial release of the Scala to Dotty Migration Tool[1] is now available

It's happening ;-)

[1] http://scala-lang.org/blog/2016/10/24/scalafix.html

Post reply on HN