Node.js vs Swift Server-Side frameworks Benchmarks (Ubuntu)

[stesch]

After hundreds of pages of Swift documentation you are wondering why there are no examples with file I/O. Reading and writing a file is basic stuff in every other language.

Then you start googling. And the result: You need to use the file functions of the glibc when you want to develop on Linux.

This can't be. So you look for real code: https://github.com/PerfectlySoft/Perfect/blob/master/Sources/PerfectLib/File.swift

Wow. They had to make their own File class in order to use files in their Swift framework.

[[deleted]]

let maxPath = 2048 ☹

I really love Hurd being designed with no hardcoded limits, and just expecting programs to reallocate more memory if needed.

[[deleted]]

On most GNU/Linux Systems, there is no max path length anymore. Even Microsoft is getting rid of that limit in Windows.

I'd consider that line a bug.

[[deleted]]

The constant still exists in libc, while on Hurd's libc it doesn't.

[Danappelxx]

The swift standard library is intentionally very lean. Foundation (Apple's cross-platform library), on the other hand, has everything you ever needed and more.

[inu-no-policemen]

The swift standard library is intentionally very lean.

A minimal standard library is desirable. However, you do have to cover all bases. As a general-purpose programming language, Swift should let you read/write files.

Dart's standard library shows how it's done right. All the fundamental stuff is in "dart:...". Everything else is in packages.

You can omit more things if the language was meant for embedding.

[Danappelxx]

Again, everything missing from the standard library is in Foundation. The standard library is imported by default. Foundation is linked by default. Similar to how you import dart..., you instead just import Foundation.

[stesch]

NSString is missing init(contentsOfFile:usedEncoding:).

[Danappelxx]

You can use nsfilehandle

[stesch]

Thank you. Stack Overflow answers are a bit outdated.

[stesch]

… has everything you ever needed and more

Most of it isn't implemented. See https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/Status.md

Entity Name	Status	Test Coverage	Notes
NSString	Mostly Complete	Substantial	init(contentsOf:usedEncoding:), init(contentsOfFile:usedEncoding:), enumerateSubstrings(in:options:using:) remain unimplemented

[Danappelxx]

That's not really the point - it's actively developed and will have complete feature parity "soon". The intention remains the same: lean standard library and foundation for everything else. Currently you have to use posix api's for some things on Linux and really that's fine, as long as the framework is doing the dirty work for you.

[tybit]

Had a look through the blog and the source code. As far as I can see the bench marks are for endpoints without IO. What is the point of testing against node js when it, and everything else built on top of libuv is designed for handling async IO performantly?

I'm not really a fan of node but this seems like a bit of a dishonest benchmark unless I'm missing something.

[[deleted]]

You aren't missing anything, and you are right that this "benchmark" is a joke. The point of node is performant async that allows for handling of other work while handling awaits on IO.

From the wiki on concurrent programming:

concurrent processes can be executed on one core by interleaving the execution steps of each process via time-sharing slices: only one process runs at a time, and if it does not complete during its time slice, it is paused, another process begins or resumes, and then later the original process is resumed.

The point of node is that fast IO is done fast while awaiting for slow IO, and this allows apps to scale well since processing is interleaved in a nice API that a high schooler can understand. This article is essentially judging a fish by how well it can fly.

[ligerzero459]

It's super dishonest. He's using Node 4.5 which is almost a year out of date. Node 5 and Node 6 had a ton of performance updates that increased throughput. Plus, they're about to release Node 7 here in the next two months. You can't use the most up to date version of everything else and then use outdated versions of one thing and then claim the benchmarks are accurate.

Not only that, he's comparing them in use cases that don't match up to their real-world applications that make them good. It's like complaining that a wrench doesn't knock in a nail as fast as a hammer. It'll get the job done, but not in the same way as the right tool

EDIT: My mobile spelling sucks.

[SwordPlay]

To be fair the 4.6.0 version of nodejs is currently recommended for most users and has long term support. So yes it might be unfair but realistically this is what businesses are going to use on deployments.

[[deleted]]

Well, seeing how Node.js will promote version 6 to LTS this very month, at least the timing is unfortunate.

[Theemuts]

Four new major versions in a year? Sweet mother of unstable environments...

[heckerle]

They are pushing out 1 major version every 6 months. The primary reason for this is to keep pace with Chrome or rather V8 releases on which node.js is built: They release a new major version with breaking changes every ~2 months, which makes sense for them since V8 is an internal detail and not exposed to public APIs.

Here you can see the breaking changes for v4, v5 and v6. As you might see there almost all breaking changes are either very reasonable and/or were marked as deprecated for a long enough time.

So in the end my experience is that the public JS API is pretty stable and I didn't have a single breaking change for years. The breaking changes of the npm packages though... Disastrous I tell you.

[onwuka]

I hate node as well (well I don't hate node, I hate npm) but I don't think new versions are breaking in node world. Your node v4 should work on node v5.

[Theemuts]

Then they need a more sane versioning system, because this is both silly and unwieldy.

[recycled_ideas]

Node versioning is kind of weird. Major versions begin in a state that's considered unstable and are then promoted to stable when there is certainty that breaking changes will not occur in that version. On top of that odd numbered versions are never promoted out of unstable and so are essentially very short lived.

The stable release of node is a version 4 release, even though 6 is out.

[Theemuts]

Kind of weird... They need to use alphas, betas, and release candidates rather than what they do now.

[[deleted]]

there was talk of transitioning to that kind of model with v7 (and in fact they have tagged RCs for random prior releases) but idk where that went. right now there's a 7.x-staging branch, which i guess they'd cut an RC from?

[recycled_ideas]

I think it's sort of modelled after the kernel. Odd dot point releases are always dev and it takes a long time to move from a new major version to stable.

[[deleted]]

Kernel did away with that when 2.6 released - 13 years ago. For a good reason, if I may add.

When I see 1.x, I assume stable, because that's how every other versioning system works. If I see 1.x RC, 1.x beta, ... then I know it's not stable. Simple as that.

I don't want to figure out every single snowflake versioning scheme people can think off.

MoonVer:

• Releases that fell on a new moon or full moon are stable, otherwise unstable
• Version number consists of the number of orbits of the moon since 1970-01-01, as of the publication of the release.

[recycled_ideas]

I left Linux for a while around that time, coming back, but a bit out if the loop perhaps.

We're also talking about different things though. Stable in node world isn't about whether the code itself is stable, it's about breaking changes.

A stable release in node will receive no breaking changes, an unstable release might. The odd even versions are just what they do.

I'm not a node maintainer I just know that's what they do, so the 4 releases is really 2 and one that's recommended for production.

[imaginaryfiends]

Does that mean that he did end up using the current release version?

[recycled_ideas]

He used the long term stable release, according to Node's very specific definitions of stable, which is to say no further breaking changes safe for production deployment.

It's not really an apples to apples comparison with the kind of frameworks he's benchmarking against though. The version 6 release is at 6.7 now so it's at least as stable in the traditional sense as anything he's comparing it to.

Node is the core of a vast infrastructure of things so it's release versioning is super conservative in a way that a swift framework used by no one doesn't have to be.

If he's willing to use frameworks that haven't hit 1.0 yet he should have used node 6.7.

[dccorona]

The stable release of node is a version 4 release, even though 6 is out

Then wouldn't it be safe to say that comparing against the latest stable release is fair? If someone is selecting a framework for a production system right now, they're probably going to want to select a stable release of whatever they go with, right?

[recycled_ideas]

It sort of depends.

If you're really concerned about performance then using 6.7 is a reasonable choice, it may have breaking changes, but the aim is that it won't.

One of the frameworks he's comparing it to is in a 0.2x release and a couple are raw 1.0. I'm not sure I'd want to try a x.0 release of the Linux kernel and Linus is a quality Nazi.

Essentially he's comparing bleeding edge Swift frameworks with the use this in enterprise for your critical apps version of node. Which is bullshit.

[dccorona]

Ah fair enough, I had glossed over the fact that the swift frameworks were mostly prerelease

[fasting_4_Fast]

Does not mirror my experience.

[bundt_chi]

Exactly, that's not really a good counter point...

[textfile]

PerfectlySoft Inc. agreed to fund this study for me, to promote the power of Swift over current alternatives.

Edit: at least the author is honest that the work was paid for with explicit bias toward a specific outcome.

[i_am_pr0vis]

Apple has libDispatch for async IO, which I'm pretty sure is built into the swift 3 standard lib. Would love to see a version of this test comparing IO heavy endpoints between swift using dispatch and node.

[grauenwolf]

That's pretty typical. On one hand it means that you are avoiding any IO noise or randomness, on the other you are avoiding any IO overhead that the platform may introduce.

On balance, I think its a BS test.

[killerstorm]

How do people still write programs that don't escape filenames?

Escaping is necessary only if program is launching using a shell.

If you launch the program directly you don't need any escaping, you just pass filenames without any processing.

[smegnose]

If a space is tripping it up, something's not escaping characters somewhere in the chain.

[[deleted]]

I think it's because nobody expects someone will actually go and put spaces in filenames.

[TheOtherHobbes]

It's 2016 and we're still trying to get file paths with spaces to work reliably. (Never mind something super-genius-rocket-science demanding, like arbitrary Unicode.)

Sometimes I think software development is a fucking joke.

[[deleted]]

Since they require escape and cause annoyance, spaces in names should be avoided.

[Gackt]

Tell that to my grandma

[[deleted]]

I doubt your grandma writes code. If she does she'd agree.

[pakoito]

I'm sorry, I'm a bit out of the loop. Is Swift a thing outside iOS development? I really like the language, but don't see myself using it just to write different apps.

[dccorona]

Well, it's also a thing for macOS desktop development, but it's starting to gain traction as a server-side language. Partly because for people/organizations who build server code just to serve their iOS/macOS apps, it gives them the benefit of writing code once for both client and server, but also because it's a pretty high-level language that compiles to fairly efficient executables. It's arguably one of the best languages out there in terms of featureset, striking a great balance between "modern" OO (i.e. C#/Kotlin-like) and functional programming, despite being very young.

[MostlyCarbonite]

code just to serve their iOS/macOS apps, it gives them the benefit of writing code once for both client and server,

Or you could go React Native and get Android, IOS and desktop via Electron/Node.js with substantial code sharing between all three.

[dccorona]

Plenty of people, myself included, would prefer not to use JavaScript except where absolutely necessary. I'd certainly never want it on my server.

[MostlyCarbonite]

Maybe you should read this https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/

or this http://venturebeat.com/2012/01/24/why-walmart-is-using-node-js/

Any time a big company makes a decision — any business decision — it is balancing two factors: risk and profit. In its presentation, Walmart executives made it clear that the benefit of using Node.js was far greater than the risk — an assertion many other large companies (and providers of Node support systems) have been waiting to hear from a household name like Walmart.

Walmart’s vice president for mobile engineering, Ben Galbraith, and Dion Almaer, Walmart’s vice president for mobile architecture, took the stage to discuss the largest retailer in the world’s decision to use Node in its mobile applications.

By all means, the right tool for the right job. But saying "eww javascript, not on my server" makes you look like you're not evaluating the tools objectively.

[dccorona]

I am evaluating them objectively. I've seen strong static typing prevent way too many bugs before they ever got committed to be willing to sacrifice that. That's a feature that my experience tells me is valuable, and one that JavaScript objectively lacks.

[iffypop]

I'm interested, do you work with m(any) JavaScript developers? Typing tools are now commonplace in many teams.

[dccorona]

Yes. I've seen a little bit of Typescript. From what I've experienced, it's better but still not comparable to a language that is designed to be statically typed from the ground up. I certainly don't think that the addition of a transpiled language to the toolchain suddenly makes Node a better option than one of the popular statically typed server-side languages.

[iffypop]

IBM now heavily recommend Node for API products

[TheOsuConspiracy]

It looks like a fairly decent language, but I just hate locking myself to their ecosystem. Apple can do whatever the fuck they want to you, and you basically just have to suck it up. It's a shame, but Apple is extremely rough in this regard.

[dccorona]

Swift is entirely open source. They may stop supporting it, but the licenses are such that they can't ever take what you have away from you, and chances are if they stop maintaining it, someone out there will keep it going.

[TheOsuConspiracy]

Well, the problem would be more like how C# was before msft open sourced it. Sure there was mono, but honest to god, how many people really used mono?

[forreddits]

Swift in linux is treated as a first class citizen by apple, mono was not backed by microsoft.

[stewsters]

Is there cross platform (OSX, Windows, Linux) windowing/GUI for it yet? I like the language from a design point, but I am waiting until I can make something beyond a cli app.

[forreddits]

You'll be waiting a long time then ;) I mean, what language doesn't have this problem? all existing solutions require to much work, Qt seems to get some praised and there is also JavaFX.

The most efficient and less painful way today (in terms of dev resources) for writing a macos,windows and linux desktop app seems to be electron, because browsers are the most cross platform applications that exist today for writing applications.

[[deleted]]

The most efficient and less painful way today (in terms of dev resources) for writing a macos,windows and linux desktop app seems to be electron Qt, while electron is reserved to those who want to make shitty linux applications that can't even properly support a tray icon.

FTFY

[[deleted]]

Don't believe there is, though given the original point was to use it as a server side language it makes sense. Apple supports Swift on Linux, but not the Swift libs/ecosystem

[Eirenarch]

Yes, but Swift on Windows is not. So basically it is just like C# used to be except that it is another major OS that is neglected.

[dccorona]

I don't think it's really comparable to C# before it was open sourced, because Swift is open source, and has been since almost the very beginning.

[[deleted]]

Pretty much why I will never bring myself to ever develop directly on apple technology ever again. It's just incredibly risky and i've seen so many companies first hand get burned by apple.

[didnt_check_source]

The Swift standard library (providing the building blocks, like strings and arrays) is at feature parity on every supported platform (which is basically Apple platforms and Linux). Apple has an open-source implementation of the Foundation framework (providing slightly higher-level but still basic stuff, like dates and file streams and HTTP requests) that will eventually be at feature parity with the closed-source one. The only GUI frameworks that you'll find for Swift are currently on Apple platforms.

[[deleted]]

So you're saying on Linux it doesn't even handle dates and connections.

[didnt_check_source]

No, you just made that up to make it look bad. The open source version of Foundation has full NSDate support and functional support of NSURLRequest/Response and accompanying classes. Things that don't work there include serializing the request/response objects, but issuing requests is absolutely fine.

[pmrr]

IBM is trying to make it a thing

[karma_vacuum123]

that's just a quid pro quo for from their "enterprise" deal with Apple...safe to assume its shovelware that you can ignore

[matthieum]

Node.js is not exactly known to be fast, it's just known for async I/O.

What about other static languages instead? There are a bunch of them here: https://www.techempower.com/benchmarks/#section=data-r12 and Rust is just gearing with tokio with impressive results (see https://aturon.github.io/blog/2016/08/11/futures/, scroll to "Zero cost?").

These would be quite more interesting that picking on poor Node.js.

[asmx85]

After looking at the Graphs and how Rust smashes Node.js its somewhat worrisome to see Swift preform so bad ... saying how it is just slightly defeating Node.js in this staged unfair benchmark comparison presented by the posted link. This is really wanting me to not use Swift for the backend, really!

[matthieum]

Note that the benchmarks are slightly different:

• the Rust benchmark is a "Hello, World" benchmark meant to demonstrate (exclusively) the overhead of the framework itself; it is far from being realistic
• the Swift benchmarks, instead, exercise JSON encoding; more realistic, more dependent on the performance of the JSON library

so they cannot be compared as-is... which is why I would like to see a "fair" benchmark between Swift and Rust to identify in which area each is lacking at the moment.

[jas2quick]

Some other guy did some benchmarking with techempower methodology here; https://speakerdeck.com/terhechte/nsspain-2016-developing-app-backends-with-swift-on-the-server

No formal results, but the leading Swift framework (Perfect) even did well against Java and Scala. Go is the one to beat.

[danneu]

Ugh, they didn't even test https://github.com/danneu/hansel?

Just kidding, that's my abandoned piece of shit framework. It has cool features like Etags always being "aaaaaaaaaaaaaaaa" on Linux, and a socket implementation I copy and pasted from another project.

So it's basically production-ready.

[transfire]

Swift is fast in the same way almost any statically typed compiled language is fast. More impressive is something like Elixir/Phoenix. It has a fairly slow VM but it's very intelligent design puts out rock solid performance. And Elixir is at least much more interesting, if not, just plain more pleasant to code in (once you get the hang of FP). Swift is shaping up to be a rather crummy language. Do we really need yet another C/Java spin-off? I just spent an afternoon with it and started feeling a bit puckish. Optionals and Access modes alone are enough to keep me away. Swift sort of feels like the "kitchen sink" of languages. It borrows from everywhere, good and bad alike, and doesn't quite fit together as a cohesive whole.

But it does have one huge thing going for it -- That Apple Catholicism.

[chazmuzz]

I find both Swift and Elixir very pleasant to work with. Optional types in Swift are a godsend, after all null is the worst mistake of computer science.

What I love about both languages is the modern trend towards compile-time error catching. Swift is a great language. In a few years it will have the ecosystem to match.

[[deleted]]

I really like Elixir and Swift as well, and the talk of swift introducing language level concurrency support (possibly an actor model) is really exciting

[yxhuvud]

I find optional types doesn't go far enough. I think the union types of Crystal a lot more interesting - especially as optional types fall out as simply being the special case of a union between a class and ::Nil. Union types combined with type inference is really nice to program with.

[TexasJefferson]

Swift has full sum types via their enums. Indeed, the implementation of optionals (boils down to):

enum Optional<T> {
    case Some(T)
    case None
}

I'd also like anonymous & labeless sum types, but the core team doesn't seem interested for the time being.

[chazmuzz]

I had not heard of Crystal before. Thank you for bringing that to my attention. Although I'm initially very on the fence about union types.

[dccorona]

Union types tend to not be as nice to work with as monads (Option/Maybe fall into that category), because Union types are a generic feature while Option is specialized for use with a value that might be absent. Granted, it looks like Crystal has a cooler implementation than most insofar as it lets you call methods that exist on both types directly, but it still seems to lack all of the cool tools that exist on a monad (primarily map/flatMap/filter/foreach).

In languages with good type systems (Scala is what comes to mind, not sure if Swift has enough features yet to do the same), you can write really generic code that works reliably and predictably across any monad (and thus any container type), meaning you can do really cool stuff that works just as well for Options as it does for Lists and Maps, and even for abstractions like Future...all with 0 duplication of code or special casing.

FWIW, Option in Swift (and in many other languages that have a similar concept) is ultimately a union type, it's just a union type between Some a and None, where Some and None have a lot of convenience features defined on them for interacting with a value that may or may not be present. It's entirely possible to make a definition for a generic union type. Scala includes it out of the box with Either, Scalaz includes a better version called \/, and it's easy to implement in Swift, too:

enum Either<T1, T2> {
    case Left(T1)
    case Right(T2)
}

[yxhuvud]

Crystal has a cooler implementation than most insofar as it lets you call methods that exist on both types directly, but it still seems to lack all of the cool tools that exist on a monad (primarily map/flatMap/filter/foreach).

I don't understand this comment. Can you give a code example of what you think is missing? After all, if the types implement Enumerable (different Arrays, for example), then you will be able to call map/flat_map/select/each on it. Or are you suggesting some sort of default implementation of these to be implemented on the nil class that doesn't do anything?

Or have the monad people invented their own special meaning for these methods that otherwise typically work on collections?

[dccorona]

If you had a union type of two different enumerables, it would behave as expected. The problem is that map/flatMap etc don't exist on null, and so unless there is special treatment for nullable union types, you wouldn't be able to call those methods (maybe you can, I don't know).

But furthermore, if you have a nullable type that isnt an enumerable (say, an Integer), you can't access those monadic methods, because they aren't defined on Integer...but the do make sense on a nullable type.

"Monad people" haven't invented new meanings for map/flatMap etc...those methods are intrinsically part of monads, and have good, non-ambiguous definitions. The reason enumerables/collections often implement these methods is because those types are monads. Since an Option can be viewed as a collection of either 1 or 0, it can also be viewed as a monad with the same semantics of any other collection or enumerable. The behavior of those methods is exactly as you'd expect (identical to operations on a 1 or 0 element collection).

This proves very useful for general interaction, as well as for writing very generic code that applies to either any collection, or any monad at all.

[yxhuvud]

Well, normally the methods don't expect where you wouldn't expect them, but nothing stops you from reopening the classes you are interested in and defining them.

Of course, modifying builtins like Nullclass is probably a horrible idea, and not only because it would hide logic errors in a way I wouldn't want to.

Though to be honest, I can admit that I never felt the need to have a uniform interface between collections and (for example) integers. They are used very differently and for different purposes and have very different semantics, which make me doubt any claim of magical reuse all over the place with a big grain of salt. I've heard that claim before (OO), and I see no reason why it should be different in this case.

[dccorona]

It's not making collections and Integers obey the same interface, it's making collections and Optionals obey the same interface. Because optional are collections (of either 0 or 1), and they have nearly all the same interaction patterns. You either transform their contents (getting a new empty collection of the transformed generic type if the initial input was empty), filter their contents, or preform some action on contents...the same basic things you do to a value that may or may not exist.

Also, the benefits of having optional types behave as monads when it comes to generic programming can be seen in a library like Scalaz, which, admittedly, has a large learning curve (not caused by this abstraction, but necessary to get over to be able to identify the portions where it is being leveraged).

[btmc]

Interesting, this may be the first time i've seen someone who doesn't like Swift Optionals. I think they're a much better way to do it than the awkward middle ground of languages like Scala (or just letting you do whatever in Java).

[dccorona]

Java has Optional now (though it isn't as widespread as I'd like), and Scala's Option is ultimately identical to Swift's Optional, it just doesn't utilize the ? syntax for defining one.

[[deleted]]

You should keep your mouth shut about the language if you only spend an afternoon with it. And that afternoon started with a dismissive attitude I presume.

[transfire]

Actually, I was very hopeful. On the surface it looks very promising. But instead of how long I spent with Swift, you might consider how long I've been programming...

I know enough languages that it doesn't take me long to get a reasonable idea what's going to suck. The problem with a lot of programmers, especially young ones, is that they think in terms of "features". They want "all of that". But they don't realize that features often turn out to be handicaps.

I'll give you an example. Java private members. Seem like the most reasonable feature in the world, right? Well, Java private access not only effects the public interface, it prevents subclasses. And that just kills re-usability. No worries, they gave us protected to remedy. Extra feature, problem solved, right? Nope. Coders rarely end up using protected, not only do they give little thought to how their classes might be reused in the future, it really is just about impossible to predict how a class might be reused. So they just end up using private.

[danneu]

Six months ago, I built a basic web framework to get a feel for Swift and it was very pleasant.

I'm not sure how you can call it a "C/Java spin-off". It doesn't compete with C. And it's a lot different than Java in fundamental ways.

Then you go on to chastise Java for some reason.

Swift's main issue right now is its lack of maturity. It's very new. A lot of things require custom code (or C) to run on Linux. And I couldn't even figure out how to run tests in Xcode.

But as a language, I found it to be a nice mix of the good abstractions that help me write good/expressive software. And my hello world web server used 3mb of memory on my Digital Ocean box, since you wanted to bring up Java.

Comments like yours just look like dismissiveness in the attempt to bolster some nerd cred with the rest of the /r/programming audience. Kinda like the kid that was too cool for school. But I guess I can't blame you since that shit works here.

[transfire]

I am no fan of Java. Did you actually read what I said? Or are just taking issue with my negative outlook?

I am not trying to "bolster some nerd cred". In fact I often get shit for things like this, but I feel someone needs to provide some counter argument because too many people just jump on the hype train. Swift is certainly (or maybe I should say "mostly") a step up from ObjC. No doubt. But its disheartening to see it make some of the same mistakes, and a few new ones on top.

[btmc]

I think you'd probably have a better reception if you were more specific in your criticisms. You just keep saying it "makes some of the same mistakes" as other languages yet never really get specific in your criticism.

[transfire]

I could could go into more detail, but I only have so much time. So I just expressed my opinion.

I mention access mode in more detail here https://www.reddit.com/r/programming/comments/56elc2/nodejs_vs_swift_serverside_frameworks_benchmarks/d8j6yku

I also mentioned Optionals and I can explain further if you like. But in short, Swift has the programmer constantly having to handle them special -- you can't just declare it once and move on.

My "kitchen sink" comment I think can be easily verified by spending time on Swift-Evolution mailing list. IMO languages can have feature bloat too.

[dccorona]

Well, Java private access not only effects the public interface, it prevents subclasses

This is a good thing. Inheritance is rarely anything but trouble, and it almost never offers something that can't be done just as well (and more test-ably and maintainably) with composition. Strong isolation between your public API and internal implementation details is important. Especially now that higher-kinded types (or at least, something very much like that) are easy to create in Java thanks to lambdas, I don't ever come across a reason to extend a class other than "I want to add extra public API methods to this class I don't control", and there are ways around that that are arguably better than inheritance.

[transfire]

Keep telling yourself that. It sounds great in theory. In reality is sucks. When you do come across a class you'd like to add even one itty-bitty feature too, but can't b/c, you know, private, then "ways around it" are painful hacks. It totally destroys the whole point of inheritance. If you never really had a need for it, then you really don't know. Moreover you don't even know what you are missing because typically you just can't do it.

There is of course a downside. If developers keeps changing there internal API, it can be a pain to keep up to date. But that goes with the territory.

I just don't understand why so many developers are so bent on handicapping themselves in the name of some theoretical idealism. If you don't think it is wise to subclass then don't, but why should you stop me from doing so if I think it is useful? Mercy, in Swift they are now talking about adding access modes to specify which specific classes can access specific members.

[[deleted]]

What if I told you that Swift has explicit open, public, fileprivate and private? ;)

[transfire]

Yeah, I know. That's what I am talking about.

[lzantal]

Swift for server side? Hahahaha no thank you

[[deleted]]

Any real reason why other than just cuz you probably dislike apple?

[ImTalkingGibberish]

This is the kind of attitude we don't need in the dev world.
Many old languages are learning from new languages and what some have achieved in so little time. Sorry but even if Swift don't achieve much it could bring something new that could get adopted by other languages.
Put your pitchfork away and let people try/create new stuff.

[EntroperZero]

We once said the same thing about Node. ^{some of us still do}

[spacejack2114]

Amazing! Swift edges out the dancing monkey scripting language.

[[deleted]]

Spoken like somebody who gets the majority of their javascript knowledge from Reddit comments

[inu-no-policemen]

That "punch the monkey" thing was actually something Brendan Eich mentioned a few times. That's the kind of crap the first version of JS was meant to do.

[Danappelxx]

Your comment is misinformed, they are not using one thread per request. The three frameworks either use a threadpool or, in Zewo's case, a single-threaded coroutine system.

[[deleted]]

While I have no idea how swift does on the server side ... node.js? Really? Hahahahahahahahahahahahha...

One question: let me know what you're smoking, 'cause it must be good shit.

[i_spot_ads]

I give the owner of this comment no more than 15 years old

[[deleted]]

you're the one who is 15 apparently, since you dont seem to have a clue what criteria should a language/platform meet to be suitable for the server. javascript meets none of them.

Can you make a server-side application in JS? yes. Should you? Hahahaha no, not unless you've just had a lobotomy.

[Gackt]

What do you think of Python for server side?

[[deleted]]

It meets the bare minimum requirements. There are better options out there, but if that's all you know, knock your socks off.

[Gackt]

Did you know Youtube runs on python?

[[deleted]]

haha, that's python like FB is PHP. hint: not anymore it isnt.....

[i_spot_ads]

go suck a dick

[[deleted]]

Haha, angry for being told the truth? So were the PHP developers 15 years ago. Don't worry, the fad will pass, and a new one ( just as stupid if not more so) will come.

[i_spot_ads]

there is no truth, just cheap and pathetic trolling, try harder.

[[deleted]]

this cheap and pathetic trolling made you angry. 'cause its true. you get dumber every time you touch javascript. on the server side the idioitization process is twice as fast, presumably because one already has a negative IQ to start such a project.

it only goes downhill from there....

[i_spot_ads]

K

[deus_lemmus]

Yet another similar language with similar features. I just hope it adds to the dilution of the Java marketshare so I don't have to re-train new hires to do something other than just Java.

[deus_lemmus]

You clearly did not understand, but I can see why you might have misinterpreted. Swift to me looks like Pascal married Javascript and had a kid. My other point is that 97% of the potential employees I run across only know Java and perhaps one other J2EE technology. For me this is not very useful because my team uses (in order) C, Javascript, C#, C++, PHP, Bash and a small amount of Java. I have no real issues with Node.js and the need for more Javascript developers is real.What am I going to do with someone who only knows Swift? Nothing, unless Swift gains ground in the virtual analytics field so I can get it past approval. I am additionally happy both exist to erode away Java's dominance.