5 ms·

The Go standard library. At least two things coming together: A stripped down language, that explicitly aims to be readable and experienced programmers / author

by mtrn 11y ago

The Go standard library. At least two things coming together: A stripped down language, that explicitly aims to be readable and experienced programmers / authors.

cyphar 11y ago
I'm not sure I agree with that. JSON parsing uses panic() and recover() for some logic. And templating is more of a PoC for coroutines in Go than a properly fleshed out library. Not to mention that the AST parsing for Go is horribly designed (though you can do some cool stuff with it).
- enneff 11y ago
  > And templating is more of a PoC for coroutines in Go than a properly fleshed out library. I worked with Rob on that library and that's really not the case. It was designed from the ground up to replace the existing template library which was bad in several ways. The parser (which is I think what you refer to) is just an implementation detail.
  - cyphar 11y ago
    > I worked with Rob on that library and that's really not the case. It was designed from the ground up to replace the existing template library which was bad in several ways. The parser (which is I think what you refer to) is just an implementation detail. Right, but why can't I call define custom operators? And why is there no bracketing in conditionals? It just feels clunky to me (but maybe I'm too spoiled with Jinja2). I still feel like you could allow execution of functions passed in the data argument (as long as the developer doesn't shoot themselves in the foot, it shouldn't be a security problem). It's stuff like that which makes me feel like it was a PoC (or at least, not designed to be feature-complete). Still, it works pretty well for plenty of usecases (I use to generate config files every once in a while).
    - enneff 11y ago
      > I still feel like you could allow execution of functions passed in the data argument I don't recally anyone asking for this before. File an issue? https://golang.org/issue/new https://golang.org/issue/new > It's stuff like that which makes me feel like it was a PoC (or at least, not designed to be feature-complete). It's designed to be a useful template engine. I don't know about "feature complete", but we are still improving it. If you find it lacking then please file issues so that we can think about improving it.
- mtrn 11y ago
  I guess, the library authors needed to learn Go themselves as they build up the stdlib.
- landr0id 11y ago
  Even if you don't think the code itself is very nice, the API is pretty well-designed.
nemo1618 11y ago
Seconded. I'm not sure if this is common for other languages, but I use the Go stdlib as a reference for what good Go code should look like. And reading it often reveals little language tricks that I wasn't aware of. Example: The Sum method of the hash.Hash interface takes a byte slice as an argument, and appends the hash to it. Why not take zero arguments and simply return a new slice? Because the authors recognized that if you're doing hashing, you probably care about performance. Appending to a supplied slice allows you to save an allocation. The stdlib is full of little details like that, and it adds up to a really great programming experience. Go may be lacking in some respects, but it has Good Design stamped all over it.

by mtrn 11y ago

The Go standard library. At least two things coming together: A stripped down language, that explicitly aims to be readable and experienced programmers / authors.

cyphar 11y ago

I'm not sure I agree with that. JSON parsing uses panic() and recover() for some logic. And templating is more of a PoC for coroutines in Go than a properly fleshed out library. Not to mention that the AST parsing for Go is horribly designed (though you can do some cool stuff with it).

enneff 11y ago
> And templating is more of a PoC for coroutines in Go than a properly fleshed out library. I worked with Rob on that library and that's really not the case. It was designed from the ground up to replace the existing template library which was bad in several ways. The parser (which is I think what you refer to) is just an implementation detail.
- cyphar 11y ago
  > I worked with Rob on that library and that's really not the case. It was designed from the ground up to replace the existing template library which was bad in several ways. The parser (which is I think what you refer to) is just an implementation detail. Right, but why can't I call define custom operators? And why is there no bracketing in conditionals? It just feels clunky to me (but maybe I'm too spoiled with Jinja2). I still feel like you could allow execution of functions passed in the data argument (as long as the developer doesn't shoot themselves in the foot, it shouldn't be a security problem). It's stuff like that which makes me feel like it was a PoC (or at least, not designed to be feature-complete). Still, it works pretty well for plenty of usecases (I use to generate config files every once in a while).
  - enneff 11y ago
    > I still feel like you could allow execution of functions passed in the data argument I don't recally anyone asking for this before. File an issue? https://golang.org/issue/new https://golang.org/issue/new > It's stuff like that which makes me feel like it was a PoC (or at least, not designed to be feature-complete). It's designed to be a useful template engine. I don't know about "feature complete", but we are still improving it. If you find it lacking then please file issues so that we can think about improving it.
mtrn 11y ago
I guess, the library authors needed to learn Go themselves as they build up the stdlib.
landr0id 11y ago
Even if you don't think the code itself is very nice, the API is pretty well-designed.

nemo1618 11y ago

Seconded. I'm not sure if this is common for other languages, but I use the Go stdlib as a reference for what good Go code should look like. And reading it often reveals little language tricks that I wasn't aware of. Example: The Sum method of the hash.Hash interface takes a byte slice as an argument, and appends the hash to it. Why not take zero arguments and simply return a new slice? Because the authors recognized that if you're doing hashing, you probably care about performance. Appending to a supplied slice allows you to save an allocation. The stdlib is full of little details like that, and it adds up to a really great programming experience. Go may be lacking in some respects, but it has Good Design stamped all over it.