Live data from Hacker News

Server APIs Project

swift.org

151–160 of 181 posts

Re: Server APIs Project

#151
post #146

Earlier quoted context omitted.

I'm not sure I understand, is there some special casing going on with "(== 10)"? As I'm admittedly not aware of it.

Not anything major. It's just syntactic sugar for "\x -> x == 10".

How is it syntactic sugar? It's just applying "10" to the first parameter of "==".

Re: Server APIs Project

#152
post #118

Is there anyway to build on Linux yet? Having to use a Mac to build and deploy is really inconvenient for some continuous integration setups.

Swift has had Linux support ever since it was open sourced.

Just not with Xcode projects? I was looking for something like xcodebuild that I could run in a docker container and never found anything. Can you point me in the right direction?

Re: Server APIs Project

#153

Earlier quoted context omitted.

Why? Java EE has a much stronger success track record than Erlang/OTP does.

Could you provide examples?

There are millions of lines of enterprise Java code running these days and a good chunk of these are using Java EE.

The trend has started moving away from it these past years but it's pretty clear that even the worst and early versions of Java EE (looking at you, EJB 2) have been used to power massive web sites and applications that are still in use today.

Erlang/OTP is nonexistent in comparison.

Re: Server APIs Project

#154

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…

Scala on Android is pretty terrible

How? Even the tooling seems to be vastly superior to the Gradle one.

Deals with SDK dependencies automatically, typed resources and views, better Instant Run, ProGuard caching, extremely low overhead, fast compiles, ...

Re: Server APIs Project

#155

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…

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.

I work with a team of 8 scala developers of varied experience. We try to set the bar at the sweet spot of power and readability. If someone's code becomes super dense because they've gone crazy with scalaz constructs then we ask at review stage to simplify, to comment and/or educate the rest of the team. I don't think experienced coders should be irresponsibly using Scala at a level that is inappropriate for the team.

Re: Server APIs Project

#156
post #135

Earlier quoted context omitted.

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

Seeing Odersky's talks, that is a gross mischaracterization of what he has said on the topic. There's a certain readable, elegant, concise style of code that is expressed very naturally in Scala, and if you take Odersky's courseras, it's very clear that it's something that was a preeminent design goal of the language.

The Scala community, on the other hand, got hijacked by a bunch of Haskell neckbeards who spew executable ASCII art over every codebase they get their hands on. The formation of the Scala Center feels like a response to this -- an effort to "retake" Scala.

Re: Server APIs Project

#158

Earlier quoted context omitted.

It usually means "good", though some people use it in an ironic sense to imply something is bad. Kinda like how "bad" can also mean "good" in the right context, but in reverse. Here I took it to mean "good."

The definition I am aware of is undeniably negative: "disagreeably damp, musty, and typically cold"

It comes from stoner culture, where it's a sign of high quality when the psychoactive plant matter is still damp and smelly.

Re: Server APIs Project

#160
post #132
post #80

Earlier quoted context omitted.

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

That Java 9 feature would definitely be amazing. I agree, Swift is nowhere near the maturity of the Java ecosystem.
Post reply on HN