3 ms·

I was just ranting about this approach elsewhere. Go and QBasic are broken in the same way: both lack power in the core language and have special syntax for fac

I was just ranting about this approach elsewhere. Go and QBasic are broken in the same way: both lack power in the core language and have special syntax for facilities that really ought to be normal calls into the standard library. In Go's case, we have goroutines, error flag omission, maps, and so on; in QBasic, we have LINE. A language's core syntax should not privilege its standard library above other libraries.

stcredzero 10y ago
A language's core syntax should not privilege its standard library above other libraries. I'm not so sure. Smalltalk had this in spades. There is a downside to this. Giving a bunch of 20-somethings the full power to basically change everything can result in code-bases which suffer from the chaos of over exuberant hubris. Go is deliberately favoring a certain set of conventions. To do this, they are also deliberately making it harder to change the language from within itself.
- sbov 10y ago
  It's not about changing everything, it's about being able to make abstractions that aren't second class citizens. By giving this power, you also increase the consistency of the language.
  - stcredzero 10y ago
    By giving this power, you also increase the consistency of the language. Maybe. That's like the apocryphal story about the student asking a question if a particular proof step is really obvious, so the professor goes across the hall, derives stuff on the other blackboard for the next 30 minutes, then comes back into the lecture hall saying, "Yes, it's obvious." Maybe you increase the consistency of the language from one point of view, but what happens from the perspective of each individual project? What if this leads to projects where templates have been used to create 3 different template based "little languages" to make X, Y, and Z easier? You had 3 problems, but now you have 6. The oft written reply to that in these debates, is to limit the power of the template system -- but is that a robust goal under the group dynamics of the language community? I think not. One subliminal goal in the design of Go seems to be about privileging certain conventions to avoid a babel of roll-your-own conventions in large projects. This is all across the language and even in the toolchain.
    - catnaroek 10y ago
      The problem with templates is that they're ad-hoc: they can be specialized, and they're only checked at instantiation time. C++'s type level is literally a dynamic language, and template errors are literally stack traces, only made worse by backtracking, due to the deepest unification rule and SFINAE. But bona fide parametric polymorphism doesn't have this problem. ML's design is a constructive proof that you can have a reasonable degree of abstraction without compromising usability.
- quotemstr 10y ago
  It's a lot easier to use lints, binding coding standards, compiler options, and so on to limit your team to a subset of the language than it is to bolt more power later onto a language like Go. Being opinionated works well for some teams --- I get that. You don't need the language spec to be opinionated when you can get the same result through mechanisms that don't affect everyone. It's just like when we're writing code: don't make global changes to achieve some local effect
  - stcredzero 10y ago
    It's a lot easier to use lints, binding coding standards, compiler options, and so on to limit your team to a subset of the language than it is to bolt more power later onto a language like Go. This deserves a bitter laugh. For large, long-lived codebases, where there have been effectively many different teams and a number of different managers, the standards, coding styles, and tooling are almost certain to change. If you know of a large corporate codebase where this is not true, please tell me about it. Hell, you need to write a paper about this and start giving talks at conferences! It seems like the Go maintainers are trying to solve this by moving such conventions from the level of individual project to the level of the language community. I think there is merit in this. For one thing, I suspect this will create greater social and intellectual cohesion across the language community as a whole.
    - quotemstr 10y ago
      > For large, long-lived codebases, where there have been effectively many different teams and a number of different managers, the standards, coding styles, and tooling are almost certain to change Sure, but I've never been convinced consistency matters at that scale. I think it's enough to be locally consistent; Windows doesn't seem to be hurt by its codebase containing practically every style you can imagine. > level of the language community Sure, but if you make the language too Procrustean, you risk making that community smaller, even if it's more cohesive. Personally, I'd rather have a bigger community, even if the members don't agree on everything.
      - 10y ago
- pcwalton 10y ago
  Encouraging consistency across the language ecosystem doesn't have to conflict with layering. The problem with having what are properly library routines in the language core syntax is that it's a layering violation: it makes the language more complex, harder to reason about, and harder to learn because it creates special cases in the grammar and core semantics. (For example, note the inconsistent behavior of indexing a nil map vs. indexing a nil slice.) The way to discourage people from "changing everything" is to make the standard library ubiquitous and to use encapsulation to prevent people from changing its internals. If Go had generic maps in the standard library, and you couldn't get access to their internals, then the effect would be exactly the same as the built-in map that Go has today. You see this in other languages: very few people create custom dictionaries in C#, for example.
woah 10y ago
The privileging of Go's stdlib is a core design choice. The idea is that your implementation code is simple, and the language takes care of library code in whatever way is best. If you don't like it, use another language.

stcredzero 10y ago

A language's core syntax should not privilege its standard library above other libraries. I'm not so sure. Smalltalk had this in spades. There is a downside to this. Giving a bunch of 20-somethings the full power to basically change everything can result in code-bases which suffer from the chaos of over exuberant hubris. Go is deliberately favoring a certain set of conventions. To do this, they are also deliberately making it harder to change the language from within itself.

sbov 10y ago
It's not about changing everything, it's about being able to make abstractions that aren't second class citizens. By giving this power, you also increase the consistency of the language.
- stcredzero 10y ago
  By giving this power, you also increase the consistency of the language. Maybe. That's like the apocryphal story about the student asking a question if a particular proof step is really obvious, so the professor goes across the hall, derives stuff on the other blackboard for the next 30 minutes, then comes back into the lecture hall saying, "Yes, it's obvious." Maybe you increase the consistency of the language from one point of view, but what happens from the perspective of each individual project? What if this leads to projects where templates have been used to create 3 different template based "little languages" to make X, Y, and Z easier? You had 3 problems, but now you have 6. The oft written reply to that in these debates, is to limit the power of the template system -- but is that a robust goal under the group dynamics of the language community? I think not. One subliminal goal in the design of Go seems to be about privileging certain conventions to avoid a babel of roll-your-own conventions in large projects. This is all across the language and even in the toolchain.
  - catnaroek 10y ago
    The problem with templates is that they're ad-hoc: they can be specialized, and they're only checked at instantiation time. C++'s type level is literally a dynamic language, and template errors are literally stack traces, only made worse by backtracking, due to the deepest unification rule and SFINAE. But bona fide parametric polymorphism doesn't have this problem. ML's design is a constructive proof that you can have a reasonable degree of abstraction without compromising usability.
quotemstr 10y ago
It's a lot easier to use lints, binding coding standards, compiler options, and so on to limit your team to a subset of the language than it is to bolt more power later onto a language like Go. Being opinionated works well for some teams --- I get that. You don't need the language spec to be opinionated when you can get the same result through mechanisms that don't affect everyone. It's just like when we're writing code: don't make global changes to achieve some local effect
- stcredzero 10y ago
  It's a lot easier to use lints, binding coding standards, compiler options, and so on to limit your team to a subset of the language than it is to bolt more power later onto a language like Go. This deserves a bitter laugh. For large, long-lived codebases, where there have been effectively many different teams and a number of different managers, the standards, coding styles, and tooling are almost certain to change. If you know of a large corporate codebase where this is not true, please tell me about it. Hell, you need to write a paper about this and start giving talks at conferences! It seems like the Go maintainers are trying to solve this by moving such conventions from the level of individual project to the level of the language community. I think there is merit in this. For one thing, I suspect this will create greater social and intellectual cohesion across the language community as a whole.
  - quotemstr 10y ago
    > For large, long-lived codebases, where there have been effectively many different teams and a number of different managers, the standards, coding styles, and tooling are almost certain to change Sure, but I've never been convinced consistency matters at that scale. I think it's enough to be locally consistent; Windows doesn't seem to be hurt by its codebase containing practically every style you can imagine. > level of the language community Sure, but if you make the language too Procrustean, you risk making that community smaller, even if it's more cohesive. Personally, I'd rather have a bigger community, even if the members don't agree on everything.
    - 10y ago
pcwalton 10y ago
Encouraging consistency across the language ecosystem doesn't have to conflict with layering. The problem with having what are properly library routines in the language core syntax is that it's a layering violation: it makes the language more complex, harder to reason about, and harder to learn because it creates special cases in the grammar and core semantics. (For example, note the inconsistent behavior of indexing a nil map vs. indexing a nil slice.) The way to discourage people from "changing everything" is to make the standard library ubiquitous and to use encapsulation to prevent people from changing its internals. If Go had generic maps in the standard library, and you couldn't get access to their internals, then the effect would be exactly the same as the built-in map that Go has today. You see this in other languages: very few people create custom dictionaries in C#, for example.

woah 10y ago

The privileging of Go's stdlib is a core design choice. The idea is that your implementation code is simple, and the language takes care of library code in whatever way is best. If you don't like it, use another language.