> Responding to nastiness with more nastiness is the surest way to destroy HN. The way to help is to gently point out that we all need to follow the site guidelines.
No where in the article does it mention that they had performance issues. Some developers write in JavaScript and it's fast enough. Swift performance is more than acceptable for most apps.
Sure, but it is slower and more maintainable. So "gain maintainability at a cost to performance" is correct. Which is generally what you want in most domains, but in areas where performance is more critical than maintainability you would rather use C still.
I don't know how Javascript plays into that - I assume Javascript is slower than Swift, but I don't think it is more maintainable.
We're not choosing religions here. Language is a technical decision (with business impact due to hiring availability). You choose the language that fits your goals best, not which one has a better saint.
"You choose the language that fits your goals best."
That's often an abused statement with no actual significance. If you are writing native iOS apps, you basically get two, maybe three, choices.
There is always a group of developers who will rush ahead and there's a group that will lag behind. It has more to do with human nature than the technical features of a language. That's why a year ago I started collecting a bunch of Swift resources in one place. Ive got almost 1500 urls.
Most blogs/articles on iOS development are now in Swift. If you are learning iOS 9, for example, it's easier to go with Swift. Swift is now the path of least resistance.
I seriously doubt most apps have more than a few performance critical areas that need to be in C -- and Swift in no way prevents you from jumping out to an Objective-C wrapper class for these exceptions.
A lot of .NET indie games are relying on such a zombie - Farseer. A Box2d clone so full of features and complexity, nobody but the owner can support it. And the owner checked out.
No, but Visual Studio 2015 came out July 20, only 7 weeks ago. I've been using it 3 weeks now. I find it difficult to judge a proposed feature when there was so little time to get used to the current situation. Maybe it's a great idea, I don't know. It looks like the next step beyond the Null-Conditional operator. I'll be migrating a lot of code to use that in the coming weeks. After that I'll have a much better idea how much I like this idea.
It's a proposal. It doesn't even have to be implemented in the language for the next version. The C# 6 proposals were done a long time ago as well, and some didn't make it into the language after all.
What would you have the language designers do? Wait two years before even thinking about what to work on next?
It was released 7 weeks ago, but has been in preview for several months prior to that. This could be a result of looking at feedback for the preview, and deciding that this feature wasn't a good fit for 2015, but was something that should be discussed soon.
Case in point: You can define a type as an enum, a discriminated union, a record type, an interface, an abstract class, a class or a struct. You can have a primary constructor for a class or struct, or like a method with the new() keyword. You have namespaces and modules.
F# also has first-class tuple types. But the better way to look at it is that you can have records and can put them in sum and products. Then for compat, there's the types for .NET's OO system. But sure, that's an increase in complexity in F#.
Yet in C# you have hard-coded keywords for things like System.Threading.Monitor (the lock keyword). This doesn't exist in F#-the-language, but is implemented via a simple function so it doesn't count. (Just like you wouldn't consider System.Math.Max part of C#-the-language).
In C#, you have hard-coded operators, whereas in F# they're essentially just functions (compile-time type parameters work similar to _Generic in C11). In C# you have hard-coded LINQ and async syntax, whereas in F# you don't (just one general construct for computation expressions).
People cite stuff like F# pipelining, but that's not a language feature, it's just a function. C# and F# both have quotations, but F#'s are more complete, not a one-off to implement LINQ-to-SQL. That reduces complexity, or is at least a tie. (In the way that arithmetic over integers is less complex than arithmetic over int32.)
Type extensions are another case of this. C# has them, but only partially implemented (extension methods), whereas F# implements the feature in a less complex way that provides more coverage.
OTOH, F# does stuff like transforming Int32.TryParse to match as a tuple (nice, but a complication). And it also has really ugly things like this one: Explicit parameter names take higher binding than = operator. Example:
Foo(Bar = Baz) // Calls Foo with argument Bar with value Baz
Foo((Bar = Baz)) // Calls Foo(bool) with result of (=) Bar Baz
My gut feeling is that once you subtract F#'s stdlib and add in C#'s plethora of edge cases, you're not actually significantly less complex in a meaningful way using C#, and F#'s improved uniformity wins out.
