Hacker News Reader

I bet that in 10 years time, once the hype has died down, Go will be seen as a middle-of-the-road language for middle-of-the road applications. A low-risk, conservative, sensible, and ultimately boring choice.

In ten years, Go will be seen as what Oberon is seen as today: essentially all the things you mention, plus the fact that there will be a dedicated community of people who like the no-nonsense "do more with less" approach that is peculiar to this family of languages and don't want to live without it. Plus, Go will most likely have some evolutionary continuation anyway.

You really think so? I think that implies that it remains unsuccessful, which (given its current trajectory) seems unlikely.

I think it's more likely that in 10 years, Go will be the new Java. Big companies (besides Google) will use it, Hacker News will hate it, consultants will write books about it, and language geeks will be trying to replace it. Recall that Java also had a no-nonsense "do more with less" approach. The problem is that once a language gets popular, it's inevitably pushed into more and more domains where it's unsuitable, folks need to learn it to earn a living, and all the folks who define themselves by what languages they know will move on to greener pastures.

The only way a language can remain cool for decades at a time is to "avoid success at all costs", which was actually one of Simon Peyton-Jones's goals for Haskell (which has remained remarkably true to that ideal). Otherwise Stroustrop's Law kicks in: "There are two kinds of languages: the ones nobody likes, and the ones nobody uses."

C is very successful and barely hated (C, not C++).

Yeah, C and to some extent Python seem to be exceptions to Stroustrop's Law. There was a poll on this recently:

https://news.ycombinator.com/item?id=6527104

My pet theory on why is that both of these languages didn't try to be middle-of-the-road, good-for-everything languages, they were created to solve a specific problem and were very well designed for that niche. So programmers use C for systems programming and when they need to be close to the metal, they don't use it for large applications with ambiguous requirements - and so all the hate that the latter engenders gets directed to C++ and Java. And programmers use Python when they need to prototype stuff, script things, or write a quick tool where performance doesn't matter - and when performance does matter, they either end up calling out to C (which is actually good for that) or they end up rewriting in Java and cursing out that language.

I like C, but I also like the type-safe, efficient containers and generic algorithms of C++.

In many ways, the containers and generic algorithms of C++ may not be necessarily that efficient: http://datadraw.sourceforge.net

You really think so? I think that implies that it remains unsuccessful, which (given its current trajectory) seems unlikely.

Oops. I meant "seen technically", not "seen socially".

I think it's more likely that in 10 years, Go will be the new Java.

I'd rather think of Go as the new C. :-)

Also, as far the "do more with less" and "no nonsense" stuff is concerned - have you seen the spec of Java on one side, and the specs for Go and Oberon on the other? There's quite some difference.

I agree that for quickly writing code Python is quicker, but I'm not sure it's necessarily to do with dynamic typing. I've been using Go for about a year and a half and Python for about double that (and other things before that like C#). I'm still trying to pin down the usability differences, and what causes them.

List comprehensions are one of the most obvious things. LINQ and Haskell and co have shown that this is absolutely doable with a static type system.

The lack of genericity is one of those things that will be argued about for the lifetime of Go, I think. Python doesn't need it because of the dynamic typing but the same problems are solved to some extent by the compile-time-duck-typing enabled by its interface system.

I'm not sure I agree re productivity. One on project I reached 30,000 lines of Python, collaborating with 3 other people remotely. Some things would have been a lot easier with static typing. I think.

There's work in progress on type inference and static typing for Python, and Python 3 supports type annotations (PEP 3107). Whether they'll get anywhere remains to be seen - it's a challenging problem, not the least because several of the language built-ins have strange typing rules. (What's the type of multiplication?)

  type(3 * 5) => int
  type(3.0 * 5) => float
  type(3 * 'foo') => string
  type(3.0 * 'foo') => TypeError

Isn't operator type can be defined using 2 parts:

1. What object calls the operator relevant method

2. Looking at the code of the relevant operator call, we'll see something like if type(obj)==str , do X . so depending on the type of obj , we can deduce output type automatically .

Another option is to use the approach mypy uses: let the language mix static type and dynamic type freely, and if we cannot determine type, let the code by dynamic , with the relevant warning .

Yes mypy isn't written yet, but it would be interesting to see how useful this approach would be.

There are a few big problems with that...

The first is that multiplication is...well, not always commutative in Python, but it has two operands and either of them can be the method receiver. For example:

  type(5 * 3) => int
  type(5 * 3.0) => float
  type('foo' * 3) => string
  type('foo' * 3.0) => TypeError

More generally, multiplication might be a method on either the right or the left type. If __mul__ is defined on the left operand, the interpreter executes the code in it. If not, and __rmul__ is defined on the right operand, the interpreter executes the code in it instead. If neither is defined, the interpreter throws a type error. So typing a * b requires knowing the types of both a and b and merging a set of rules for each of them.

The other problem is that you cannot in general determine the type of an expression by inspecting code, unless you apply some rules to the legal expressions in the language. For example, take this code fragment:

  def foo(fn):
    if typecheck.static_type(fn) == int:
      return 'a string'
    else:
      return 0

Assuming typecheck.static_type is our hypothetical typechecker and it operates on function objects. What should the type of foo(foo) be?

I suspect that any working solution involves some sort of constraint solver that gathers up all the constraints, simplifies them, determines if they're compatible, and then outputs a list of possible types it could be, each subject to certain assumptions on the input types.

Again i'm missing the problem.

If typecheck.static_type evaluates type on an object , typecheck.static_type(foo) returns type 'function'. And our function will return 0 , meaning type == int.

if typecheck.static_type does something else , more complex , we could always tell our tool that fn is dynamic.

typecheck.static_type is supposed to give you the full type of the object - not just 'function', but 'function(int) -> int'. Or I guess I in this case I was just looking at the return type, so 'int'. Hence the problem - foo is defined so that if its type is int, it returns a string, while if its type is string, it returns an int.

The problem with giving up and returning 'dynamic' is that dynamics tend to propagate through the code if you're doing anything moderately complex. If we give up, then any expression that calls foo() now typechecks as 'dynamic', and any expression that calls one of them typechecks as 'dynamic', and so on. You end up with a typechecker that doesn't tell you anything useful about your program, other than that it was dynamically typed.

If this is restricted to a few special cases like, say, Django ORM classes or namedtuple, it's not a huge problem, because you can hardcode in specific rules for them (or put in a plugin mechanism). But tricky typing rules abound even in the basic language features; as mentioned above, multiplication does not even have concisely expressible typing rules in Python.

No. In 10 years time it will sadly be forgotten like many of Google's experiments.

The low-risk, conservative, sensible and boring choice exists today. It's Java.

And as enterprises adopt functional programming via Scala/Clojure it will only cement those characteristics.

I think enterprises will rather adopt functional programming via Java.

I dislike Google for pulling the plug on consumer products as well, but this is a product designed for use at Google and I understand they are writing/converting a lot of code in it. So I think you underestimate Google's backing in this case, which is probably the reason Go has seen one of the fastest rises in popularity of any language, ever -- if not the fastest.

Go has made me enjoy programming again -- I find it very freeing not to have to use Java or .NET and memorize 40,000 builtin classes. Yes, Go is similar to Java in terms of its being a "middle of the road" conservative language. But (a)it's conservative for the 21st Century, rather than the 20th, and (b)ditching the virtual machine and bloat of Java is a good thing IMO.

I don't think it's the fault of the VM. There have been other languages that worked with intermediate code, and they weren't inefficient. It's just that fixing old stuff after you get millions of users leaves you with a very strange language, even a stranger one than if you add completely new stuff along the way. The latter is inevitable, but the former ought to be avoided. The Java people probably didn't realize in the beginning what they were building. (Well, of course, who would have, in their place?)