7 ms·

I agree, but I think the age of the language and community is another factor. Java, Python, C++, these are all old languages with decades of history and habits

I agree, but I think the age of the language and community is another factor. Java, Python, C++, these are all old languages with decades of history and habits. Newer things like Node.js and Go have no history, no baggage to learn or avoid. I think starting in something with such a clean slate is somewhat easier because there is less ecosystem to learn.

laumars 14y ago
This has been my experience learning Go as well.
qznc 14y ago
I once heard a quote like this "programming languages are frozen knowledge about software engineering". (Anybody got a clue who said something like this?) New languages usually improve upon older languages by making certain errors impossible by design. For example, Go allows pointers, but not pointer arithmetic. With C we learned pointer arithmetic is often harmful (though sometimes necessary), so Java removed pointers from the language (not completely, though). Go takes a sensible middle way, because no pointers sometimes is ugly. Such a clean slate is good, because with older languages programmers fight their language deficiencies with habits (e.g. if (5 == x) instead of if (x == 5) to prevent if (x = 5)). On the other hand, we will find the pitfalls and dark corners of Go over time, but currently we do not know them enough. Go will acquire its own conventions, but we do not know all of them yet. This is the risk of a clean slate.
- mercurial 14y ago
  Funny you should take Go as an example, since it's often bashed for not having taken the last decade of language design into account.
  - qznc 14y ago
    Go does take the last decade of language design by Pike, Thompson, and Griesemer into account. Mostly Pike as I am not sure if the other two guys even did design some language in this time. Personally, I consider gofmt the biggest achievement of Go, if it manages to make that mainstream. While there are equivalent tools for C they are not widely used.
    - masklinn 14y ago
      > Go does take the last decade of language design by Pike, Thompson, and Griesemer into account. Decade which ended 20-odd years ago relative to the rest of the world, kind-of the point.
    - pjmlp 14y ago
      You mean by designing a language that is basically Alef from Plan9(1992) with a few changes? Yeah, really actual.
      - kragen 14y ago
        The English term for "actual" is "up-to-date". The English word "actual" means "not imaginary".
        pjmlp 14y ago
        thanks for the correction.
        kragen 14y ago
        Happy to help!
  - jff 14y ago
    There's a difference between not taking it into account, and not believing it is worth including.
- masklinn 14y ago
  > On the other hand, we will find the pitfalls and dark corners of Go over time, but currently we do not know them enough. Go will acquire its own conventions, but we do not know all of them yet. This is the risk of a clean slate. That's bullshit, Go is not a "clean slate", and a number of design issues of Go are known and have been known from the first release regardless of its designer's refusal to acknowledge them. We know pervasive nullable types are a source of errors, we know shared-memory concurrency is an error-prone default, we know a lack of generics makes userland code painful and generics are hard to retrofit in an established language (and even Go's designers know it, why do you think they build special-case generic collections in the interpreter?), we know allowing implicitly ignoring errors is a bad idea and making it easier to ignore than handle errors also is. These are not recent issues, they're well known and there are a number of possible strategies for handling them. And Go's worst sin, to me: we know that foisting complexity and repetitiveness upon the user leads to forgetting, and forgetting leads to mistakes. And that's exactly Go's approach to errors, resources management and shared structures mutability. Human error is something you can very reliably bet on, human infallibility... not so much.

laumars 14y ago

This has been my experience learning Go as well.

qznc 14y ago

I once heard a quote like this "programming languages are frozen knowledge about software engineering". (Anybody got a clue who said something like this?) New languages usually improve upon older languages by making certain errors impossible by design. For example, Go allows pointers, but not pointer arithmetic. With C we learned pointer arithmetic is often harmful (though sometimes necessary), so Java removed pointers from the language (not completely, though). Go takes a sensible middle way, because no pointers sometimes is ugly. Such a clean slate is good, because with older languages programmers fight their language deficiencies with habits (e.g. if (5 == x) instead of if (x == 5) to prevent if (x = 5)). On the other hand, we will find the pitfalls and dark corners of Go over time, but currently we do not know them enough. Go will acquire its own conventions, but we do not know all of them yet. This is the risk of a clean slate.

mercurial 14y ago
Funny you should take Go as an example, since it's often bashed for not having taken the last decade of language design into account.
- qznc 14y ago
  Go does take the last decade of language design by Pike, Thompson, and Griesemer into account. Mostly Pike as I am not sure if the other two guys even did design some language in this time. Personally, I consider gofmt the biggest achievement of Go, if it manages to make that mainstream. While there are equivalent tools for C they are not widely used.
  - masklinn 14y ago
    > Go does take the last decade of language design by Pike, Thompson, and Griesemer into account. Decade which ended 20-odd years ago relative to the rest of the world, kind-of the point.
  - pjmlp 14y ago
    You mean by designing a language that is basically Alef from Plan9(1992) with a few changes? Yeah, really actual.
    - kragen 14y ago
      The English term for "actual" is "up-to-date". The English word "actual" means "not imaginary".
      - pjmlp 14y ago
        thanks for the correction.
        kragen 14y ago
        Happy to help!
- jff 14y ago
  There's a difference between not taking it into account, and not believing it is worth including.
masklinn 14y ago
> On the other hand, we will find the pitfalls and dark corners of Go over time, but currently we do not know them enough. Go will acquire its own conventions, but we do not know all of them yet. This is the risk of a clean slate. That's bullshit, Go is not a "clean slate", and a number of design issues of Go are known and have been known from the first release regardless of its designer's refusal to acknowledge them. We know pervasive nullable types are a source of errors, we know shared-memory concurrency is an error-prone default, we know a lack of generics makes userland code painful and generics are hard to retrofit in an established language (and even Go's designers know it, why do you think they build special-case generic collections in the interpreter?), we know allowing implicitly ignoring errors is a bad idea and making it easier to ignore than handle errors also is. These are not recent issues, they're well known and there are a number of possible strategies for handling them. And Go's worst sin, to me: we know that foisting complexity and repetitiveness upon the user leads to forgetting, and forgetting leads to mistakes. And that's exactly Go's approach to errors, resources management and shared structures mutability. Human error is something you can very reliably bet on, human infallibility... not so much.