5 ms·

While the author has a lot of valid points, he forgets the goal of Go. Go was designed as a simple language, that is fast, but has similar power to existing dyn

by TeeWEE 12y ago

While the author has a lot of valid points, he forgets the goal of Go. Go was designed as a simple language, that is fast, but has similar power to existing dynamic languages such as python. The tradeoff in these designs are to prevent tuple types, always keep using structs, prevent using algebraic types over structs. Allow for nil, but try prevent common Null errors etc. Haskall is theoretical a much better language. But Golang was designed to be practical & simple over being mathematically sound, and theoretical better.

kasey_junk 12y ago
> Go was designed as a simple language, that is fast, but has similar power to existing dynamic languages such as python. I'd like to see a citation for this as I've never seen this as a stated goal of golang. In fact, if it were the stated goal that is one of the most damning arguments against golang as it very clearly fails at this task. I've been under the assumption that golang was designed to make writing/deploying/managing simple web services across a wide variety of machines and across a wide variety of teams. While I'm still reserving judgement on it accomplishing this goal, I'd say it is much more likely to accomplish this than trying to have similar power to python.
- Someone 12y ago
  http://golang.org/doc/ http://golang.org/doc/: "Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language." That comes reasonably close.
Cyther606 12y ago
For a Python-like core language with an expressive type system that is simple, clean and immediately absorbable, you're really looking for Nim, not Go. The following produces a single binary with native code generation via compilation to C, no VM: import rdstdin, strutils let time24 = readLineFromStdin("Enter a 24-hour time: ").split(':').map(parseInt) hours24 = time24[0] minutes24 = time24[1] flights: array[8, tuple[since: int, depart: string, arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."), (583, "9:43 a.m.", "11:52 a.m."), (679, "11:19 a.m.", "1:31 p.m."), (767, "12:47 p.m.", "3:00 p.m."), (840, "2:00 p.m.", "4:08 p.m."), (945, "3:45 p.m.", "5:55 p.m."), (1140, "7:00 p.m.", "9:20 p.m."), (1305, "9:45 p.m.", "11:58 p.m.")] proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int = hours * 60 + minutes proc cmpFlights(m = minutesSinceMidnight()): seq[int] = result = newSeq[int](flights.len) for i in 0 .. <flights.len: result[i] = abs(m - flights[i].since) proc getClosest(): int = for k,v in cmpFlights(): if v == cmpFlights().min: return k echo "Closest departure time is ", flights[getClosest()].depart, ", arriving at ", flights[getClosest()].arrive Statistics (on an x86_64 Intel Core2Quad Q9300): Lang Time [ms] Memory [KB] Compile Time [ms] Compressed Code [B] Nim 1400 1460 893 486 C++ 1478 2717 774 728 D 1518 2388 1614 669 Rust 1623 2632 6735 934 Java 1874 24428 812 778 OCaml 2384 4496 125 782 Go 3116 1664 596 618 Haskell 3329 5268 3002 1091 LuaJit 3857 2368 - 519 Lisp 8219 15876 1043 1007 Racket 8503 130284 24793 741 Not only is this syntax far more approachable for anyone who likes Python, as opposed to Go, Nim is actually suitable for systems and embedded programming. Optional GC and manual memory management makes Nim one of the few up and coming systems programming language that ventures into C territory while still being safe and pragmatic enough for general usage. http://goran.krampe.se/2014/10/20/i-missed-nim/ http://goran.krampe.se/2014/10/20/i-missed-nim/ https://github.com/Araq/Nim/wiki/Nim-for-C-programmers https://github.com/Araq/Nim/wiki/Nim-for-C-programmers
rjberry 12y ago
I dislike it when people say languages are either 'practical' or 'well designed'. As if a language is only useful if it's not built on sound mathematical ideas ... Generics are not a particularly new idea and nobody who uses language that implement them yearn for the days when they weren't around. See Paul's post on the idea that 'worse is better': http://pchiusano.github.io/2014-10-13/worseisworse.html http://pchiusano.github.io/2014-10-13/worseisworse.html
- jbooth 12y ago
  The point is that you reach an area where the mathematical ideas don't map perfectly to the underlying functionality you're providing. You can make your language "unsound" by violating those mathematical principles, or you can make something like the I/O monad. It is indeed "soundness" vs "practicality". EDIT: Oh, and that link seems to have misunderstood the 'worse is better' philosophy -- C++ isn't the champion of 'worse is better', C is.
  - rjberry 12y ago
    Paul explains fairly well why he thinks C++ is a good example of "worse is better", including quotes from the language designer to that effect. I think when you get to more complicated (or at least alien) abstractions like the I/O Monad, it's not about whether it's practical to build software with it. It's perfectly practical - I know people working at big investment banks writing large scale software in Haskell, and they don't have any issue with it. What it comes down to is whether the people you work with will understand or want to invest the amount of time required to learn those abstractions. If you're working with very talented programmers, that might be yes. With the majority of programmers it is probably no. But we're not talking about the I/O Monad. We're talking about generics, which are not difficult to understand, and that Go lacks them is a shame, as it means that whole layers of abstraction are not available to the programmer, so they end up having to spend more time writing boilerplate.
    - jbooth 12y ago
      So he invested time in building up his straw-man before tearing it down? The problem with being in such a rush to confirm your own worldview is that you don't learn anything from anyone else's. The 'worse is better' philosophy is about valuing simplicity over completeness, specifically in the context of UNIX/C vs Lisp machines back in the 80s. How do you think most of those people feel about, say, the STL?

by TeeWEE 12y ago

kasey_junk 12y ago

> Go was designed as a simple language, that is fast, but has similar power to existing dynamic languages such as python. I'd like to see a citation for this as I've never seen this as a stated goal of golang. In fact, if it were the stated goal that is one of the most damning arguments against golang as it very clearly fails at this task. I've been under the assumption that golang was designed to make writing/deploying/managing simple web services across a wide variety of machines and across a wide variety of teams. While I'm still reserving judgement on it accomplishing this goal, I'd say it is much more likely to accomplish this than trying to have similar power to python.

Someone 12y ago
http://golang.org/doc/ http://golang.org/doc/: "Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language." That comes reasonably close.

Cyther606 12y ago

For a Python-like core language with an expressive type system that is simple, clean and immediately absorbable, you're really looking for Nim, not Go. The following produces a single binary with native code generation via compilation to C, no VM: import rdstdin, strutils let time24 = readLineFromStdin("Enter a 24-hour time: ").split(':').map(parseInt) hours24 = time24[0] minutes24 = time24[1] flights: array[8, tuple[since: int, depart: string, arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."), (583, "9:43 a.m.", "11:52 a.m."), (679, "11:19 a.m.", "1:31 p.m."), (767, "12:47 p.m.", "3:00 p.m."), (840, "2:00 p.m.", "4:08 p.m."), (945, "3:45 p.m.", "5:55 p.m."), (1140, "7:00 p.m.", "9:20 p.m."), (1305, "9:45 p.m.", "11:58 p.m.")] proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int = hours * 60 + minutes proc cmpFlights(m = minutesSinceMidnight()): seq[int] = result = newSeq[int](flights.len) for i in 0 .. <flights.len: result[i] = abs(m - flights[i].since) proc getClosest(): int = for k,v in cmpFlights(): if v == cmpFlights().min: return k echo "Closest departure time is ", flights[getClosest()].depart, ", arriving at ", flights[getClosest()].arrive Statistics (on an x86_64 Intel Core2Quad Q9300): Lang Time [ms] Memory [KB] Compile Time [ms] Compressed Code [B] Nim 1400 1460 893 486 C++ 1478 2717 774 728 D 1518 2388 1614 669 Rust 1623 2632 6735 934 Java 1874 24428 812 778 OCaml 2384 4496 125 782 Go 3116 1664 596 618 Haskell 3329 5268 3002 1091 LuaJit 3857 2368 - 519 Lisp 8219 15876 1043 1007 Racket 8503 130284 24793 741 Not only is this syntax far more approachable for anyone who likes Python, as opposed to Go, Nim is actually suitable for systems and embedded programming. Optional GC and manual memory management makes Nim one of the few up and coming systems programming language that ventures into C territory while still being safe and pragmatic enough for general usage. http://goran.krampe.se/2014/10/20/i-missed-nim/ http://goran.krampe.se/2014/10/20/i-missed-nim/ https://github.com/Araq/Nim/wiki/Nim-for-C-programmers https://github.com/Araq/Nim/wiki/Nim-for-C-programmers

rjberry 12y ago

I dislike it when people say languages are either 'practical' or 'well designed'. As if a language is only useful if it's not built on sound mathematical ideas ... Generics are not a particularly new idea and nobody who uses language that implement them yearn for the days when they weren't around. See Paul's post on the idea that 'worse is better': http://pchiusano.github.io/2014-10-13/worseisworse.html http://pchiusano.github.io/2014-10-13/worseisworse.html

jbooth 12y ago
The point is that you reach an area where the mathematical ideas don't map perfectly to the underlying functionality you're providing. You can make your language "unsound" by violating those mathematical principles, or you can make something like the I/O monad. It is indeed "soundness" vs "practicality". EDIT: Oh, and that link seems to have misunderstood the 'worse is better' philosophy -- C++ isn't the champion of 'worse is better', C is.
- rjberry 12y ago
  Paul explains fairly well why he thinks C++ is a good example of "worse is better", including quotes from the language designer to that effect. I think when you get to more complicated (or at least alien) abstractions like the I/O Monad, it's not about whether it's practical to build software with it. It's perfectly practical - I know people working at big investment banks writing large scale software in Haskell, and they don't have any issue with it. What it comes down to is whether the people you work with will understand or want to invest the amount of time required to learn those abstractions. If you're working with very talented programmers, that might be yes. With the majority of programmers it is probably no. But we're not talking about the I/O Monad. We're talking about generics, which are not difficult to understand, and that Go lacks them is a shame, as it means that whole layers of abstraction are not available to the programmer, so they end up having to spend more time writing boilerplate.
  - jbooth 12y ago
    So he invested time in building up his straw-man before tearing it down? The problem with being in such a rush to confirm your own worldview is that you don't learn anything from anyone else's. The 'worse is better' philosophy is about valuing simplicity over completeness, specifically in the context of UNIX/C vs Lisp machines back in the 80s. How do you think most of those people feel about, say, the STL?