5 ms·

Great for server-side apps. Configuration management is a breeze with its single-large-executable approach. I agree with a lot of the design decisions; and find

Great for server-side apps. Configuration management is a breeze with its single-large-executable approach. I agree with a lot of the design decisions; and find it a nice language to work with. It suffers a bit from the fact that dynamic languages like Python are (and will always be) nicer and more productive for hacking around in when performance is not a concern; and from the fact that you cannot (yet) beat C for (single-thread) performance. So, if productivity is everything: use Python, or your dynamic language of choice. If performance is everything, use C (or C++, if you really must).If, on the other hand, you want a nice balance between (good-enough) productivity and (good-enough) performance, Go is a great bet. 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. Which is great, because that is exactly what Go is trying to achieve.

gngeal 13y ago
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.
- nostrademons 13y ago
  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."
  - mseepgood 13y ago
    C is very successful and barely hated (C, not C++).
    - nostrademons 13y ago
      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 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.
    - qznc 13y ago
      I like C, but I also like the type-safe, efficient containers and generic algorithms of C++.
      - gngeal 13y ago
        In many ways, the containers and generic algorithms of C++ may not be necessarily that efficient: http://datadraw.sourceforge.net http://datadraw.sourceforge.net
  - gngeal 13y ago
    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.
afandian 13y ago
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.
- nostrademons 13y ago
  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
  - hershel 13y ago
    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.
    - nostrademons 13y ago
      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.
threeseed 13y ago
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.
- qznc 13y ago
  I think enterprises will rather adopt functional programming via Java.
- threepipeproblm 13y ago
  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.
  - gngeal 13y ago
    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?)

gngeal 13y ago

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.

nostrademons 13y ago
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."
- mseepgood 13y ago
  C is very successful and barely hated (C, not C++).
  - nostrademons 13y ago
    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 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.
  - qznc 13y ago
    I like C, but I also like the type-safe, efficient containers and generic algorithms of C++.
    - gngeal 13y ago
      In many ways, the containers and generic algorithms of C++ may not be necessarily that efficient: http://datadraw.sourceforge.net http://datadraw.sourceforge.net
- gngeal 13y ago
  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.

afandian 13y ago

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.

nostrademons 13y ago
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
- hershel 13y ago
  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.
  - nostrademons 13y ago
    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.

threeseed 13y ago

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.

qznc 13y ago
I think enterprises will rather adopt functional programming via Java.
threepipeproblm 13y ago
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.
- gngeal 13y ago
  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?)