Hacker News Reader

Comment by AsyncAwait | Hacker News Reader

As someone who refused to sink any significant time into Swift until they open-sourced it, I have found it to be the most productive statically-typed, native language out there. Its type system feels like the best of C# and Rust, while it feels that the speed at which one can pick it up is not that much greater than that of Go despite being a much richer language, (I've started learning in January and am at the level now where I can take on a fairly complex Swift project and feel comfortable about being able to finish it in time, plus I now use Swift for almost any programming task, 90% of them at least). Plus, you have to give Apple credit for getting the open-source release right, (GitHub, pull requests, proposals, mailing lists, frequent dev builds, Linux support - I guess Chris Lattner has been the one driving this, but I have to give credit to Craig Federighi and Tim Cook for letting him do it.)

The only part that frustrates me is that SourceKit seems to crash every other minute for no apparent reason - but that is no fault of the language itself.

Swift is the first piece of Apple software I'm genuinely excited for. Congrats to everyone who contributed to the 2.2 release

View on HN

I love Swift dearly - I spent two years in Objective C land, after 8 years of C# and 10-ish years of C++ pain, and started using Swift day to day from Swift 1.2. But the current version have one big gaping hole: generic protocols are utter shit. For the uninitiated: Swift generic protocols don't have generic parameters, they have type constraints. Which means that a function can't return generic protocol. Which is the stupidest thing ever.

There's a way to dance around that restriction, by making an intermediate class to do type erasure by hand (why I should do that? That's compiler's job), but still - Swift crew are obviously very talented bunch with a good taste, how they allowed such nonsense from the start?

PS I don't want to sound too negative, Swift replaced C# as my favorite language, 95% of the time it's joy to use (especially after Objective C, I never agreed with that language), it's just - the generic protocol thing drives me mad.

Yeah, somewhat related to that; it's not currently possible to have typealias for a type with generic parameters, one has to wrap it in a struct or an enum, however Swift is very much not done and they're catching up quickly, so I'm optimistic, especially now that we can see and affect what's coming next.

Generic typealiases are coming, thank goodness: http://ericasadun.com/2016/03/08/generic-typealiases-are-a-t...

Awesome! This is what I'm talking about; now that Swift is open-source we can see which improvements have landed and what is coming next. Thanks for the link.

Have you used OCaml? Swift seems very similar to OCaml from what I can see - without the nice module system, but perhaps with a more familiar syntax.

> the best of C# and Rust

e.g.? I've only just scratched the surface of Rust and dismissed C# as a Java clone (but maybe I shouldn't have?). What's some examples of the best of Swift that you see?

One case where C# is far superior to Java is generics.

Generics were a cutting-edge feature in 2005. Microsoft took the opportunity to start from scratch, and released the .Net Framework 2.0 without backwards-compatibility, and with full support for generics. A List<String> is actually a List of String.

When Sun released Java 5, they didn't want to disrupt the established Java ecosystem. Their implementation is called "type erasure". As an example, List<String> is actually just List<Object>, with automatic runtime typecasting to String. https://docs.oracle.com/javase/tutorial/java/generics/erasur...

Java's solution works well enough, but it breaks down in certain scenarios, such as multiple levels of generics. For example, when getting an element from a List<List<String>>, Object is not cast to List<String> (which doesn't really exist), but merely List.

C#'s implementation of generics became even more sophisticated with C#4, which introduced covariance and contravariance. https://msdn.microsoft.com/en-us/library/ee207183.aspx

> Generics were a cutting-edge feature in 2005.

Generics have been around since at least the early '80s.

Well, "cutting-edge" in enterprise technology.

Another interesting failed prototype on the JVM was the language "Pizza" https://en.wikipedia.org/wiki/Pizza_%28programming_language%...

Ada isn't enterprise technology?

https://en.wikibooks.org/wiki/Ada_Programming/Generics

http://www.cs.dartmouth.edu/reports/TR86-104.pdf

(From 1984.)

When does it matter what an element from a List<List<String>> is cast to at runtime? In a properly-written statically-typed program, types are a compile-time construct (ignoring the machinery of dynamic linking and method call semantics in particular implementations, which don't matter to the programmer), and though you may use them at runtime via reflection, I would argue that 99% of the time that you do, you're writing bad code. http://stackoverflow.com/questions/20918650/what-are-the-ben...

Type erasure introduces limitations on what you can do at runtime that forces a developer to write code to workaround it. For example, in Java you can't write a generic method that instantiates an object based on the type of the generic. The workaround is typically to pass in the Class type as an additional parameter to the method, which in theory should not be necessary. A lot of JVM-based languages are required to introduce additional complexity in the language to simulate reified generics (e.g. Scala's Manifest/TypeTag classes).

> A lot of JVM-based languages are required to introduce additional complexity in the language to simulate reified generics (e.g. Scala's Manifest/TypeTag classes).

I'm not sure how this makes sense. These tags are just standard context bounds, which are extremely useful and quite awesome.

You make it sound as if these tags were some kind of special feature added to the language, or context bounds were solely invented to support these tags.

> For example, in Java you can't write a generic method that instantiates an object based on the type of the generic. The workaround is typically to pass in the Class type as an additional parameter to the method, which in theory should not be necessary.

If a method needs to instantiate an object, the normal technique is to accept a factory function as a parameter. You can do the same thing with type-erased generics.

C# decided to create a shortcut for calling the constructor of a generic type parameter. But, for example, you can't call static methods of a generic type parameter (and a constructor is really just a slightly special static method).

Passing in the class type for instantiating a new instance is not what you should do in your applications. You don't know at compile time if the class you pass in has a default constructor, so your program can fail at runtime. As others have stated, the right thing to do is pass in a factory object. C# solves this by adding even more cruft to the language in the form of a "new constraint" that tells the compiler to ensure that the type has a default constructor. https://msdn.microsoft.com/en-us/library/sd2w2ew5.aspx

Don't Java Generics mess with method (argument type) Overloading?

> Generics were a cutting-edge feature in 2005.

I was already using C++ templates in 1994 with Borland C++ for Windows 3.1!

Ada, CLU and ML go back to the late 70's / early 80's.

Yes, but I guess that code would break in a million ways today in a modern C++ compiler

It certainly worked at the time, for that specific compiler

It was still a language feature even if it wasn't available 100% bug free in all C++ compilers.

C code also used to break left and right long after C90 was approved.

I had to use K&R C style code in 1999 because the HP-UX compiler at a customer location didn't knew any better, but that didn't mean other C features weren't available elsewhere.

> I had to use K&R C style code in 1999 because the HP-UX compiler at a customer location didn't knew any better, but that didn't mean other C features weren't available elsewhere.

Curious, what did you need to do specifically? Parameter declarations weren't inlined?

But anyway, C, being smaller, breaks in fewer ways

> Curious, what did you need to do specifically? Parameter declarations weren't inlined?

In those days HP-UX C compiler was still transitioning between K&R and ANSI standards.

We could only properly compile without strange errors while using K&R function declarations.

If memory serves me right, it was the first HP-UX release having support for 64bit file systems.

Templates are not proper generics. Templates can be used to emulate generics, but they are not the same thing at all. Templates are not first-class citizen of the type system (they don't survive to the typechecking phase), while generics are. You cannot write a generic list implementation in C++ and have it typechecked.

I'd like to hear more about that because I'm not sure I understand. Can you give an example for something you cannot do in C++ in a type safe way that you can do in C#, Java or Swift?

I already gave one. You can't write a generic list implementation and make the compiler prove your code is sound (according to the rules of the C++ type system) for any valid type argument value.

You obviously need to learn about template metaprogramming, enable_if, type traits and SFINAE.

C++ templates are Turing complete, you can validate whatever you feel like at compile time.

I'm absolutely aware of enable_if, type traits and SFINAE. But they do not address the concern I raised here. The things you mention come to play on template instantiation, after the concrete (non-generic) types are already known. The problem I mention is that with templates you cannot type check generic code. I can put whatever nonsense enable_ifs on my template declaration and the compiler does not check if they are satisfied by the implementation.

You can write the following C++ code and C++ allows it:

<template typename T> void foo(const T& arg) { arg.bar(); }

This is perfectly fine for a macro system. But this is not how truly generic type system would work. If templates were proper generics, the typechecker would immediately refuse this to compile saying something like: "Error: I can't prove T has the bar() member."

> C++ templates are Turing complete, you can validate whatever you feel like at compile time.

So please write a template metaprogram that validates if a given C++ class (input to the program, given as a template argument) matches a table schema in the database system (the table name and connection string are also given as template arguments). For fetching the schema, you have to connect to the DB, of course at compile time. If the schema does not match, the compilation should fail ;)

Because whoever wrote foo () was too lazy to make use of type traits and validate that T has a method called bar with zero arguments.

Do you want an example how to write it properly?

With or without the upcoming concepts TS already in GCC 6.0?

Also this example would require T to be an interface with a bar method in C#. Do you also want to the the variant with MI and pure abstract classes in C+?

> Because whoever wrote foo () was too lazy to make use of type traits and validate that T has a method called bar with zero arguments.

In a proper generic type system, the compiler validates it, not the programmer. Even if you constrain the type using type traits, the compiler would not check if the implementation satisfies the constraints. I can put a type trait for existence of bar() and then another programmer may rename bar() to baz() forgetting to update the constraint and the code will still compile fine.

Except that reasoning fails with concepts, already available in GCC 6.0 and as a TS.

So you're saying concepts will reject libraries that compile fine today?

They might, if used properly.

I do admit that I need to update myself with what GCC 6.0 allows vs the letter of the TS.

I don't think concepts are even necessary to do what pkolaczk wants to do, which is (I think) to constrain the argument to a particular interface, say Bar:

  template <typename T> 
  void foo(const T& arg) {
    const Bar* b = arg;
    b->bar();
  }

  template <typename T> 
  void foo(const T& arg) {
    static_assert(is_base_of<Bar, T>::value, "T must be a Bar");
    arg.bar();
  }

I can't say I'm a huge fan of either syntax, but the compiler will perform static type checking as if you had written where T : Bar in C#.

The body of the template won't be typechecked until the instantiation of the template. This is different than in C#. If I replaced arg.bar with arg.baz in C#, the generic type definition would not compile, even if I never use it. In C++ I can't write a template and have it typechecked for all possible input types satisfying the type constraints, in C# I can. So C++ type system is weaker than that of C#.

I see what you mean, but uninstantiated also means unused. So we're not talking about anything that could possibly lead to runtime errors. It's not an issue with type safety.

It definitely has a downside for the development process, especially when it comes to writing libraries. But it is also to some degree inevitable if you want structural typing. Maybe there is a better way to do it though.

Now I am curious about an example where generics are able to do what templates, which are Turing complete, aren't.

I think of templates as an automated copy+paste mechanism. C++ templates can bloat the compiled executable pretty significantly... If you define a generic Foo<String> and Foo<Widget>, C++ templates will generate two separate binary implementations. C# will use the same implementation, and perform type checks using reflection at runtime.

Further support for the idea that C++ templates are an automated copy+paste mechanism is that you're allowed to give templates arguments that are not types.

Further reading: https://msdn.microsoft.com/en-us/library/c6cyy67b.aspx

It is not how you think of them, rather what is possible to do with their expressiveness.

C# type checks imply a performance hit and are an implementation detail. Nothing prevents a C# compiler to choose another one. It has nothing to do with generics vs templates.

For example Modula-3 and Ada compilers use the same approach as C++ for code generation of their generics.

So where is that example of something that can only be written with C# generics, but not with C++ templates?

A github gist maybe?

It is not the case of what can only be written, but what can be written and typechecked. C# generics offer much stronger type safety for library writers than C++ templates. C++ templates are not type-checked. C# (and Java, and Scala and Haskell) generics are.

Yes they are type checked.

That is what enable_if, type traits, if constexpr and eventually concepts allow for.

No, they are not. This code compiles fine, despite an obvious non-generic type-error. You may add whatever number of type traits, constexprs, etc there, and it will still compile fine as long as syntax is ok.

  #include <string>

  template <typename T>
  void foo(const T& arg) {
    int x = std::string("int expected");
  }

  $ g++ -c template.cpp
  $ // see, no error

Templates are only syntax-checked. The type checker is not even executed on the non-generic code inside of templates. The type checker will be executed after the template is instantiated (expanded). At that point, generic types do not exist. There exist only concrete types.

They are still type checked when they are instantiated and the code is as generic as always.

Uninstantiated templates are dead code that will be stripped anyway.

Did I write anything different?

Sure, you can type-check them for particular type arguments. But you can't type-check them generally at the generic level and you have absolutely no guarantee that your library code is free of type errors. Not a problem if the goal is to produce the final executable, but a big problem for a library writer, who doesn't control the inputs (in this case: the types provided by the user of the library).

And AFAIK C++17 concepts do not address this problem, really. I can constrain my input types with them, and the calling code will be forced to conform to them (and the compiler will present a nice error message if it doesn't), but there is still no checking on the other side - that is if the template implementation is correct assuming these constraints. I can publicly declare my code requires T.bar(), then shamelessly call T.baz() in the template implementation and the compiler will not catch it.

This is like a Python program. You don't know if it type-checks before you run it, but even if you run it once or twice and it was fine, that doesn't guarantee there are no type errors.

Yes.

The code line int x = std::string("int expected"); has zero relation with any of the template arguments.

So a programmer error that doesn't have anything to do with the types provided for the template.

Sure it will be caught in C#, because its build model assumes the existence of modules and everything is compiled to binary.

In C++ a similar compilation error would occur when compiling the translation unit into a library where the template is instantiated.

Of course, most templates being header only the error will only occur when instating it, but it will still blow on compilation and prevent the final generation of the exe, dll being produced.

Also errors related to semantic type check, independent of template arguments is relatively easy to achieve with unit tests.

I still fail to see how a generic system that doesn't offer partial specialization or meta-programming as being more powerful than templates.

I never said more powerful. I said stronger. In C++ you need unit tests to check something I can have statically proven in C#. And obviously you can't instantiate your template for all possible valid input types, because this number can be infinite.

Monomorphisation is the name of the technique of producing a different version of the code for each set of type parameters that are used in the program. C++ and Rust use monomorphisation instead of doing runtime checks because they're trading off slightly bigger binaries for greater speed.

By not doing runtime checks you get to skip that work at runtime, obviously, but you also get to enable other optimizations like inlining the monomorphised version.

Templates are a macro system. Macro systems are often Turing-complete. But if being Turing-complete was the only important thing in programming, then we'd all code in assembly and never look forward. Most programming languages are Turing-complete, but this doesn't mean they are practically equivalent for every job. You know, Brainfuck is also Turing-complete, but you'd be probably pissed-off if I said heavy-templated C++ code readability is often close to that of Brainfuck.

Macro systems can be very powerful, but they are also quite hard to use. It is 2016 and error messages in C++ templates are still inferior to the messages you get in C#, Java or Scala generics, despite templates existing for much longer.

C++ templates are also not the very best at metaprogramming either. Take any macro system like the ones found in LISPs, Scala or Template Haskell - they are much more powerful and consistent with the rest of the language. I can code Scala metaprograms in Scala or LISP metaprograms in LISP. But I can't code C++ metaprograms in C++, I have to use this weird duck-typed functional template language which doesn't have even loops or conditionals.

That weird duck typed functional template language runs circles around C# and Java generics.

I have experience in compiler design and C#, Java and C++ are my tools of trade. So I know their generics systems pretty well.

Maybe if I get bored during Easter I can bother to provide your safe list.

> That weird duck typed functional template language runs circles around C# and Java generics

This sentence doesn't make much sense. Comparing oranges and apples. It is like saying Scala macros are better than Scala generics. C++ templates are neither great at metaprogramming (there are much better macro systems in other languages out there) nor great at generics (Java, C# or Swift generics are not state-of-the-art either, but in some cases I mentioned they are better).

One case where Java generics are far superior to C# (actually CLR) is implementing more advanced generics on top of JVM thanks to erasure. C# generics are too weak to express concepts found in Scala or Haskell type system directly, but at the same time too strong to serve as a base for a standalone implementation of such type systems.

Having worked with both for several years, I would rate C# as a much better language than Java. The language by itself is noticeably better, but the difference is even more pronounced if you include the ecosystem -- Visual Studio vs. Java IDEs, the class libraries, ASP.NET MVC vs. Struts and its ilk. I would check it out if you have the need to do any Windows-related programming. (Not sure how great the support is outside Windows.)

Uh, when was the last time you worked with Java? Struts isn't a popular framework anymore and hasn't been for awhile.

IntelliJ absolutely trounces VSS and some combination of Spring Boot, DropWizard or Vert.x blows ASP.NET MVC away. Not to mention the whole ecosystem is a hell of a lot more open. There is a library for just about anything under the sun.

Enterprise environments tend to be very conservative when it comes to stuff they let you install or even use. Often you can't just drop JARs in there, never mind use your own JRE. So you're often stuck with technology that sites like these consider quite ancient…

It gets even worse on desktops, as sysadmins might be able to isolate a server enough to allow some "new" tech, but vetting a new Java version or library for a few thousand office desktops is a task nobody really wants to do. So I wouldn't be surprised to still see some Java 1.4 Swing apps in use at big insurance or pharma companies. (And if I'd had to pick between that or do a web app that supports their IE8 browsers…)

"Enterprise environments" also have to be very conservative about security issues - which often means they're forced to update to currently supported versions of software. Java 8 is the only version currently receiving security updates.

The same thing applies to many other software packages, including browsers, Linux and Spring. Sane IA folks don't like to deploy known security holes.

It sounds like you're dealing with some backwards-thinking folk. ;-)

We are talking about enterprise here, so backwards-thinking is part of the package. And if you're big enough, you can get by with outdated standard software, either by hiring special consultants or by costly vendor support. I'm pretty sure you can "convince" Oracle to accept your money.

The alternative is auditing all your installed software packages with Java dependencies. Re-hire the agency that did that small Swing client 8 years ago. Hire someone completely new to reverse engineer another client because the original company went belly up. Ad infinitum, ad nauseam.

No wonder they'll do software cryonics.

This is getting better slightly in recent years, when you no longer have that many desktop clients and utilities, as upgrading servers is way easier than building new default images for all your desktop clients.

You are really dating yourself with Struts. That's early 2000s Java tech. Intellij, Java 1.8 and Spring Boot are really nice tools that you're missing out on.

Ah that could definitely be. Back when I switched from Java to C# there was a big difference, even just from having access to lambdas, LINQ, sane generics, etc. But it sounds like Java has gotten better on all fronts, which is great. The main thing I wanted to get across is that while C# has its roots in cloning Java, it ended up being far more than just a clone.

"and dismissed C# as a Java clone"

It definitely looks like that, but I'll take C# over Java any day

Java API looks like it was built by the worse bureaucrats they could find and one piece doesn't fit another except in a very specific (non-obvious) way

Some of the things off the top of my head in no particular order; protocols, (closer to traits than interfaces), Optional types, (elsewhere no null types), pattern matching (if let, case let), guards, (so you can cover your preconditions nicely), immutable let bindings first, var variables second, (with mutability being tied to the binding outsite of reference types/classes), tuples, lazy evaluation, flexible closure syntax, fairly powerful type inference, enums as tagged unions, (or as standard C enums if you want), extensions - even for core structures if you need it - straighforward way to define custom or overload existing operators, type system powerful enough to be able to implement a fairly convincing Functor, Applicative or Monad without much effort, structs AND classes, most things are value types...

But most importantly to me, Swift is composed in such a way that it just 'clicks' for me, ie many times many times I can guess how something is likely called or how it will behave without looking at the docs and I have a solid chance of being right - that 'intuitiveness' is something that is lacking in many other languages I've used over the years.

In regards to C#, by now it is definitely not just a Java clone anymore, in particular saner type system and much more functional features edge it for me over Java, plus the speed of evolution is much greater in the C# land. If you want to see how C# and Java differ but are tied to the JVM, try Kotlin: http://kotlinlang.org - it's fairly similar in feel to C# and has 100% Java compatibility.

Reply on news.ycombinator.com