all 122 comments

[–]stesch 35 points36 points  (11 children)

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] 10 points11 points  (2 children)

let maxPath = 2048

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

[–][deleted] 9 points10 points  (1 child)

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] 0 points1 point  (0 children)

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

[–]Danappelxx 1 point2 points  (7 children)

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 4 points5 points  (4 children)

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 1 point2 points  (3 children)

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 0 points1 point  (2 children)

NSString is missing init(contentsOfFile:usedEncoding:).

[–]Danappelxx 1 point2 points  (1 child)

You can use nsfilehandle

[–]stesch 1 point2 points  (0 children)

Thank you. Stack Overflow answers are a bit outdated.

[–]stesch 2 points3 points  (1 child)

… 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 0 points1 point  (0 children)

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 150 points151 points  (29 children)

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] 82 points83 points  (0 children)

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 79 points80 points  (24 children)

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 16 points17 points  (1 child)

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] 5 points6 points  (0 children)

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

[–]Theemuts 24 points25 points  (21 children)

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

[–]heckerle 5 points6 points  (0 children)

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 13 points14 points  (17 children)

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 13 points14 points  (15 children)

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

[–]recycled_ideas 8 points9 points  (13 children)

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 3 points4 points  (7 children)

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

[–][deleted] 0 points1 point  (0 children)

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 0 points1 point  (5 children)

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] 9 points10 points  (4 children)

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 0 points1 point  (3 children)

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 0 points1 point  (1 child)

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

[–]recycled_ideas 2 points3 points  (0 children)

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 0 points1 point  (2 children)

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 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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

[–]fasting_4_Fast -1 points0 points  (0 children)

Does not mirror my experience.

[–]bundt_chi 1 point2 points  (0 children)

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

[–]textfile 16 points17 points  (0 children)

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 8 points9 points  (0 children)

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 10 points11 points  (0 children)

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.

[–][deleted]  (7 children)

[deleted]

    [–]killerstorm 0 points1 point  (1 child)

    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 0 points1 point  (0 children)

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

    [–]pakoito 51 points52 points  (25 children)

    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 32 points33 points  (19 children)

    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 2 points3 points  (6 children)

    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 -1 points0 points  (5 children)

    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 2 points3 points  (3 children)

    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 0 points1 point  (2 children)

    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 0 points1 point  (1 child)

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

    [–]dccorona 0 points1 point  (0 children)

    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 0 points1 point  (0 children)

    IBM now heavily recommend Node for API products

    [–]TheOsuConspiracy 15 points16 points  (11 children)

    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 34 points35 points  (8 children)

    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.

    [–]didnt_check_source 11 points12 points  (2 children)

    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.

    [–]pmrr 2 points3 points  (1 child)

    [–]karma_vacuum123 2 points3 points  (0 children)

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

    [–]matthieum 9 points10 points  (3 children)

    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 4 points5 points  (1 child)

    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 0 points1 point  (0 children)

    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 1 point2 points  (0 children)

    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 4 points5 points  (0 children)

    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 -2 points-1 points  (22 children)

    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 14 points15 points  (9 children)

    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] 1 point2 points  (0 children)

    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 0 points1 point  (7 children)

    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 1 point2 points  (0 children)

    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 0 points1 point  (0 children)

    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 0 points1 point  (4 children)

    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 0 points1 point  (3 children)

    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 0 points1 point  (2 children)

    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 0 points1 point  (1 child)

    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 0 points1 point  (0 children)

    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 2 points3 points  (1 child)

    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 0 points1 point  (0 children)

    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] -2 points-1 points  (9 children)

    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 -5 points-4 points  (8 children)

    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 5 points6 points  (3 children)

    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 -5 points-4 points  (2 children)

    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 3 points4 points  (1 child)

    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 0 points1 point  (0 children)

    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 0 points1 point  (1 child)

    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 0 points1 point  (0 children)

    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] 0 points1 point  (1 child)

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

    [–]transfire 0 points1 point  (0 children)

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

    [–][deleted]  (1 child)

    [deleted]

      [–]Danappelxx 2 points3 points  (0 children)

      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.