Hacker News Reader

The edge cases regarding generics have to do with the mixing of inheritance subtyping and generics. The ML family have working generics and they work well. Go made the good decision of avoiding sub-typing, so they should not have a serious problem with generics.

The C# author, Anders Hejlsberg, back when C# was around 5 years old has admitted that they failed to study the state of the art of programming language design and repeating the (very old) nullability mistake. This should despell the myth that design mistakes in modern programming languages are intentional trade-off positions. It isn't true -- modern language designers simply forsake the process of learning the various state-of-the-art languages and decide to reinvent the wheel, poorly.

People get attached to languages, so this will hurt some feelings here, but I think this is true of Go too. Rob Pike and others have repeated the mistake of failing to learn from the state of the art and re-encoded several age old PL design mistakes that could have easily been averted. A couple of clear mistakes in Go:

* Everything is nullable

* Boolean blindness

Some features that Go should have stolen:

* Sum types and pattern-matching (this would help with boolean blindness)

* Type-classes (So much more powerful than interface inheritance, and can be implemented more efficiently in many cases)

Given the majority of programmers themselves also do not study the state of the art, these designs, for all their (avoidable) mistakes become popular and persist, and make us all live with poorer-quality software for much longer.

[1] http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-Q... (1:00:35)

See the excellent discussion of Go's declaration syntax [1] and compare with "The Spiral Rule" for C [2].

[1] http://golang.org/doc/articles/gos_declaration_syntax.html

[2] http://c-faq.com/decl/spiral.anderson.html

[1] finally explains to me why so many new languages like Scala and Kotlin and Go use the right-hand side declaration syntax. And it also automatically aligns multiple variable identifiers in one column.

In Rust the choice was much simpler: we didn't want to use the lexer hack, and we wanted to avoid arbitrary lookahead in the parser. Consider:

    let hashmap<int,str> x;
    let x;

After parsing the "let" we don't know whether to parse a type (which can be arbitrarily long) or a variable name. Switching to postfix types neatly solves the problem:

    let x: hashmap<int,str>;
    let x;

I like how Rust uses colons for the type, compared to Go's colonless syntax. The colon works as a nice visual delimiter.

I like a lot about Rust, but one thing I vehemently dislike is how type names are all lowercase by convention. It's unambiguous in variable declarations, but everywhere else it reduces visual information. In most other languages, I immediately know that "Foo" is a type and that "foo" is a variable. Even though Rust allows for omitting the type in many places, it quickly becomes a sea of lowercase for me.

This, plus the focus on short keywords/identifiers and C++-style syntax (::, semicolons), makes Rust look a lot gnarlier than Go, overall.

It also seems to me that Rust still hasn't fully adopted its "object syntax"? One aspect of Go I really like is how functions can be used as methods and you design entire interfaces associated with a type -- the best of object-orientation without the worst. Rust also does this, but on the whole it seems the current standard library is not designed around this philosophy. For example, code uses `vec::len(foo)` instead of `foo.len()`. Are you moving away from the OO syntax, or is it simply considered a stylistic choice?

You'll be happy to know that these issues are being addressed:

* I agree about type capitalization. I try to capitalize my types in new Rust code, and I'm advocating switching to it generally. It is currently on the roadmap. (It's not just a stylistic thing; we can fix several issues in the grammar that way, most notably the distinction between an enum like None and a variable like x.)

* The keywords are going to stay short (although some of them are being revised to read better; e.g. "cont" -> "again", "iface" -> "trait"), but identifiers are going to lengthen in new code.

* '::' may change to '.', to make it easier on the eyes. I personally prefer '.', and am advocating the change.

* You're right that Rust hasn't fully adopted dot-notation. This is an artifact of dot-notation being introduced later in the design, and we're in the process of transitioning code from vec::len(x) to x.len(). We definitely aren't moving away from the OO syntax; in fact we're moving toward traits [1] and maximally-minimal classes as a way to unify OO, Go-like interfaces, and Haskell-like typeclasses under one simple, coherent system.

I'd prefer it if semicolons stayed, however; I think automatic semicolon insertion is more trouble than it's worth, as it ruins people's house bracing styles and causes confusing errors. That said, the way a trailing semicolon changes a block's return value is very confusing, and I'm pretty sure we can fix that issue.

[1]: https://github.com/mozilla/rust/wiki/Proposal-for-unifying-t...

"identifiers are going to lengthen in new code"

I'll be holding you to this promise. :) Indeed, what's the point of super-short keywords if not to allow identifiers to be more descriptive while maintaining an 80-column limit?

Wow. I'm pleasantly surprised that all of my issues are actually being addressed -- I was thinking that I might be in the minority on these points. I need to be paying closer attention to the mailing list.

While I love that you are making major changes, I am sure that you are aware that the instability of the language is a problem for many people. I have been watching from the sidelines for a good while now, but aside from testing new builds and reading the developer blogs, I dare not start using Rust for anything. Niko Matsakis's recent blog entry about mutability was particularly disappointing as it seems such a basic idea should have been settled much earlier. I can appreciate the kind of experimental, agile approach to language design, of course; but while Rust is germinating, I have been forced to fall back to Go. I really hope the dust settles soon so the language can stabilize and mature.

As for the semicolons, I think a strict, well-defined rule such as the one used by Go is sufficient. Actually, Go is a bit too rigid about semicolon insertion for my taste. The following, for example, will not compile, despite the fact that the ending brace is expected by the parser:

    house := &House{
      color: Green,
      floors: 3,
      patio: true
    }

On the other hand, Go is perfectly happy about:

    import (
      "fmt"
      "io"
    )

...but I have not looked into why this is a special case.

The instability of the language is something we've been discussing a lot, but I think it's better to make a good language than to rush something out the door and be living with our mistakes years down the road. That said, we are racing to get the design finalized as quickly as possible.

These design discussions would have happened behind closed doors in most other places; the fact that you can see all of it just shows how open our development process is. We deliberately haven't been making much noise about Rust because we know it's unstable. When we are ready to finalize and commit to aspects of the language design, we'll make that clear.

Mutability is pretty hard. Consider what C++ and D had to go through with const/immutable correctness. The design we came up with is pretty novel and captures all of our use cases in a simple way, but it wasn't easy to arrive at.

Absolutely, better to have a good language than something rushed.

As an aisde, I'm curious if the core design of the language itself has been/is done online, as opposed to working closely in an office environment? In my experience, technical design is something that greatly benefits from being present in the same room as other people. The second you have to sit down and actually write out paragraphs about how you're right about some issue, and debate about it democratically with a group of people, efficiency drops significantly. I guess my hypothesis is that a small team working in a single location could bat out a language faster than a larger distributed team, and that possibly Rust has taken so long partly because it is an example of the latter.

> The design we came up with is pretty novel

Is this [1]? The roadmap makes it sound like it's up in the air ("one of the larger unknowns") at this point.

[1] http://smallcultfollowing.com/babysteps/blog/2012/05/31/muta...

I agree with their reasons. But Go should have been consistent and made the reversal even for pointer types and chosen another operator say postfix (^) for pointer instead of (*) to avoid conflating with multiplication.

So effectively "those ties mean that we cannot break completely from using parentheses to disambiguate types and expressions in the grammar".

Looks like Go's authors recognized all the issues very well and still went ahead with the final, wrong decision IMHO. They might as well have not bothered with postfix.

About 1., it mirrors the syntax for goroutines "go foo()". Both are supposed to be modified calls and can take arguments, so passing a function would be semantically wrong.

1. Reversing type and variable/parameter name is just aesthetics I guess but it still really bothers me. Perhaps there's a reason.

The reason is that it is much easier to read for more complex types. eg. function pointer in C: int (*pt2Function)(float, char, char);

function pointer in Go: var pt2Function func(float32,byte,byte) int

Try writing a type that is a pointer to a function that returns a function in C. It's a bit mind bending.

> which is how you'd refer to functions in Python or Javascript rather than their return value

It's what you'd do in pretty much every language other than Go, really. And it's quite annoying when defining the function inline: you have to remember the extraneous parens to call the function in-place.

> Python tuples are probably a more general (and better?)

Python's tuples are indeed more general, "better" is a more complex issue as the language does not provide much support for tuples management.

Erlang's tuple support is significantly better than Go's MRV-specific syntax in my opinion, so is Haskell's (although in Haskell you often would use dedicated data types where Go would use tuples, as you can pattern-match — and unpack — pretty much anything and declaring a datatype is extremely easy)

It's not a function reference. It's a deferred call: the call can have arguments.

There is no difference, a call can trivially be deferred by wrapping it in a function.

But then you would have to wrap one-liners more often. The syntax of the 'defer' keyword is obviously designed to match the syntax of the 'go' keyword for launching Goroutines, and it would be annoying to wrap every 'go' call with arguments in an anonymous function without arguments.

> But then you would have to wrap one-liners more often.

Would you really? Most of the examples I see over and over take no argument, the common case most definitely seem to be that. Not to mention it is not hard to design a HoF wrapping a callable and arguments, and deferring the application of one to the others.

> The syntax of the 'defer' keyword is obviously designed to match the syntax of the 'go' keyword for launching Goroutines

Which I consider problematic for the same issue.

> it would be annoying to wrap every 'go' call with arguments in an anonymous function without arguments.

No more annoying that calling functions being deferred, or coping with the weird irregularity of evaluating all sub-expressions but not the top-level one.

Sorry but I think your idea would just make the language less consistent. A call is a call, it can be deferred or made asynchronous (with the go keyword). In the latter case at least it is very common to specify arguments. Having a syntax to defer a function call, that only works with functions that take no argument, would be weird and inconsistent.

Which is why "defer" and the "go" should operate on blocks or statements, not expressions. For instance:

    defer { result++; }

Instead of:

    defer func() {
        result++;
    }();

Also that you need such an ugly syntax just to not silently ignore return values from "defer" and "go" speaks volumes. For instance the "defer f.Close()" in the original post ignores errors from close, and with no exceptions these are just lost. It should be something more like:

    defer func() {
        err := f.Close();
        // handle error
    }();

You are basically always going to use this form anyway if you care about error handling. But lack of error handling in Google Go is another issue entirely.

Just to give an example from I project I'm working on now:

  output.WriteString("<statements>\n")
  defer output.WriteString("</statements>\n")

"1. Reversing type and variable/parameter name is just aesthetics I guess but it still really bothers me. Perhaps there's a reason (eg parsing speed) but I'd still prefer: float32 f1 float32 f2 = 45.4 over var f1 float32 var f2 float32 = 45.4"

I've always found this a nice change.

The first way, you read it as: I have a float variable, named f1 and its value is 45.4.

The second way, you read it as: I have a variable named f1, it's a float, and its value is 45.4.

The second seems more natural to me, putting emphasis on your name and value, instead of the type. It is even more obvious when you use the := syntax. `f1 := 45.4` => "I have a variable named f1, whose value is 45.4 (a float)."

2. The language is in UTF-8 so you can have snowman variable names but weirdly what gets exported from a struct or package and what doesn't is decided by uppercase/lowercase (respectively).

I knew that Go was both case-significant and Unicode-aware, but I had assumed (perhaps incorrectly) that they'd have some mechanism to export identifiers written in scripts that don't have a case distinction. Can anyone verify this? Or do they really expect e.g. Japanese programmers to write identifiers like `A緑` instead of `緑`?

Writing non-English identifiers in a programming language that is based on English keywords seems wrong to me anyway. I'm not an English native speaker myself, but I accept that the international language of programming and source code is English.

English is my only natural language, so I don't feel qualified to comment on whether or not this is attitude is acceptable in circles where English is not the native tongue. But from a language design standpoint, why even allow Unicode identifiers if you're going to foist ASCII on everyone anyway?

EDIT: Actually, I suppose Unicode-awareness means that they'd be foisting Unicode Category Lu[1] on everyone rather than simply ASCII.

[1] http://www.fileformat.info/info/unicode/category/Lu/list.htm

> Writing non-English identifiers in a programming language that is based on English keywords seems wrong to me anyway.

Then it should not be allowed at all.

Language users will find a way though, they can just write phonetically.

The standard idiom in Go is X緑, I believe.

What are the thorny edge cases that C# generics have? Java generics have use-site, not def-site variance, which is the source of most of the confusion... but C# gets this right.

If you have a class Sub implementing an interface IBase.

How does C# handle the case of List<Sub> being used as List<IBase>?

If it is allowed, does it let you do:

  List<IBase> base = subList;
  base.append(someOtherSub); // Oops! Broken invariant

Is List<T> covariant on T? If not, that's a thorny edge case, which results from the combination of OO-subtyping and generics.

Type parameters are invariant, unless explicitly specified to be covariant with a where clause.

Well, if List<T> is invariant on the T, then you cannot usefully have lists parameterized on interfaces, which is losing a useful ability. I'd say that classifies as a thorny edge case.

In Haskell, I can represent the type:

  (Show a, Ord a) => [a]

It seems like the same is impossible in C# due to generics' interaction with inheritance.

In C#, generic classes cannot be co- or contravariant on their types, but interfaces can. IList<T> itself is not covariant, as that would open the hole you mention, but it extends interface of IEnumerable<T>, which is covariant (it only allows you take T's out of the List, so it is OK if you do

    var subs = new List<Sub>();
    ...
    IEnumerable<Base> bases = subs;

The objects that 'subs' produces are guaranteed to be Sub's, and hence Base's, and you cannot insert a Base into 'subs' this way because IEnumerable does not have a method for doing that.

More info at http://msdn.microsoft.com/en-us/library/dd799517.aspx.

> 5. Still immature IDE/debugger support. I tried to set up the Go plugin on IntelliJ (my preferred IDE) but in creating a project it would fail throwing NPEs in the logs for reasons not quite clear to me.

On the Windows platform the Zeus IDE Go language support has been constantly improving:

http://www.zeusedit.com/go.html

Jussi Jumppanen

Author: Zeus Editor

I've had that ebook for a while but hadn't read it yet; I'll put some time into it this week I think.

Just on the editor front; I've had quite a pleasant time writing Go in vim, but I guess that depends on whether you would class using vim a pleasant time :D

Slightly OT, but in Sublime Text, cut with no selection cuts the entire line.

The sooner you stop trying to use Go with an IDE, the happier you will be. Seriously, I promise. Go+Sublime. It gets you syntax highliting, auto completion, import fixes (soon via Margo), automatic go fmt, builds started from inside Sublime if you want.

A graphical debugger is about the only feature you get in an IDE (at least that I use often in projects that I'd use Go for) that's missing and I'm happy enough with other debugging tools.