5 ms·

Golang is really the best example of a minimal language (Yes yes I know late to generics and all that). I think it works because they have spent huge amounts of

Golang is really the best example of a minimal language (Yes yes I know late to generics and all that). I think it works because they have spent huge amounts of effort to create a well designed and fairly comprehensive standard library. The best example of this is io.Copy. You give it a reader and writer and it does an optimal copy in almost all cases. A minimal language that doesn't have resources like Golang to put in the stdlib is just not gonna work.

voidhorse 4y ago
I agree. I've grown to really love Go the more I've used it and gotten the chance to compare it to other languages. There's a certain "completeness" and philosophical consistency to it that's really hard to find in other languages these days imo (some older languages, like Standard ML, C, Scheme, and some others also achieve this) because I think a lot of language designs now evolve more organically instead of being formally thought out up front.
- fndex 4y ago
  You might like Clojure.
- pcwalton 4y ago
  Go evolved very organically. Look at the inconsistency in the way nil slices vs. maps work, for instance, or the way comparisons against nil for interfaces work. Go may be simple to explain at a high level, but the details are very complex.
capableweb 4y ago
For me, C-like languages like Golang don't come close to be as minimal as lisp-like languages. I agree that the standard library of Golang is smaller compared to it's contemporaries, but the language itself is not small, there is a bunch of syntax to be learned compared to languages like Clojure, where the actual language is tiny, and the standard library on the bigger side.
- crop_rotation 4y ago
  A language like scheme is much simpler yes, but scheme or even Common Lisp don't have anywhere near as comprehensive a lib as Golang, which is what you need to create real systems.
  - epgui 4y ago
    This probably won’t make sense to most people who haven’t used lisp at work for real work, but… You just really don’t need much to get stuff done with a lisp.
  - erik_seaberg 4y ago
    There’s a lot missing from Go’s stdlib, including obvious uses for its builtin types. If you want Common Lisp’s (remove-if-not #'oddp #(1 2 3 4 5)) you have to write a loop from scratch, and then everyone has to read it carefully to learn what it’s doing (and especially what it’s not). Don’t get too excited about having HTTP or JSON built in, we weren’t using those in 1990 and they’ll surely be replaced by 2050.
    - kazinator 4y ago
      Strangely, ANSI CL says that remove-if-not is deprecated. That probably wouldn't be the case if it had been named retain-if or keep-if; the issue is likely the double negative. A function which pares down a sequence to just those elements which match a predicate is very useful; why would you deprecate such a thing.
      - lokedhs 4y ago
        Probably because the idea of the standards group was that you already had REMOVE and COMPLEMENT, so there was no need for it. These days the function is usually called filter, but I'm not sure it was a commonly used term then.
        kazinator 4y ago
mattbee 4y ago
Your example exposes an edge of Go that speaks to this essay. Yes io.Copy works with any Reader and Writer but dig into the documentation and there's a runtime check for the revised ReaderFrom and WriterTo interfaces that you might also implement for faster performance. It's just something you have to know, otherwise you will not get an optimal copy. Go 1 is right on the edge of being a big language, but what might stop it is that Google don't need it to get any bigger.
ojkelly 4y ago
As much as I’ve been loving Rust, there’s no doubt it’s a hard but rewarding journey to learn it. Go on the other hand, is a language I’m still confident I can teach a junior enough to be useful in an afternoon. The restraint shown by the Go team is admirable in how well they’ve stuck to their vision.
Animats 4y ago
> I think it works because they have spent huge amounts of effort to create a well designed and fairly comprehensive standard library. ... A minimal language that doesn't have resources like Golang to put in the stdlib is just not gonna work. Yes. Rust suffers from this problem. The language is now reasonably solid, but library quality and stability is all over the place. I've been annoying people in the Rust community by saying that it's time to get all widely used crates (over a million downloads, or depended upon by a widely used crate) to version 1.x. After that, no breaking changes without a major version change. Crates with re-exported types from lower levels force groups of crates into lockstep update. The big advantage of Go is that the libraries for doing server-side web stuff are the ones used internally by Google. So they've been thoroughly exercised. The obscure case that comes up once in a trillion transactions probably happened a hundred times in the last hour in a Google server farm.
- fbdab103 4y ago
  I want a step further than upgrading libraries to 1.0. I really want the Rust foundation to package up the essential libraries (bikeshedding to ensue, but something akin to Python or Go), and release those as a single, annual distribution. Even better if they could standardize the API across all of the packages, ensure minimal unsafe, etc. The `rust_stdlib_v2023` could only depend upon itself, and would be a basis for which other projects could then build from there. It annoys me to no end the huge number of packages I pull in for doing something "simple". It is great that packages can be so small and focused, but now I have a real trust problem. How am I possibly supposed to ensure there are no malicious actors in my dependency tree?
  - Animats 4y ago
    There's already a standard library. After that, there's just whatever anybody decided to upload to "crates.io". Nothing in between. Some form of curation and quality control is needed, at least for crates depended upon by other widely used published crates. The Rust foundation's crate manager job is apparently vacant until at least April, so nobody is officially in charge of this. Relevant XKCD: [1] My take on this for game development: [2] [1] https://imgs.xkcd.com/comics/dependency_2x.png https://imgs.xkcd.com/comics/dependency_2x.png [2] https://www.reddit.com/r/rust_gamedev/comments/11b0brr/were_not_really_game_yet/ https://www.reddit.com/r/rust_gamedev/comments/11b0brr/were_...

voidhorse 4y ago

I agree. I've grown to really love Go the more I've used it and gotten the chance to compare it to other languages. There's a certain "completeness" and philosophical consistency to it that's really hard to find in other languages these days imo (some older languages, like Standard ML, C, Scheme, and some others also achieve this) because I think a lot of language designs now evolve more organically instead of being formally thought out up front.

fndex 4y ago
You might like Clojure.
pcwalton 4y ago
Go evolved very organically. Look at the inconsistency in the way nil slices vs. maps work, for instance, or the way comparisons against nil for interfaces work. Go may be simple to explain at a high level, but the details are very complex.

capableweb 4y ago

For me, C-like languages like Golang don't come close to be as minimal as lisp-like languages. I agree that the standard library of Golang is smaller compared to it's contemporaries, but the language itself is not small, there is a bunch of syntax to be learned compared to languages like Clojure, where the actual language is tiny, and the standard library on the bigger side.

crop_rotation 4y ago
A language like scheme is much simpler yes, but scheme or even Common Lisp don't have anywhere near as comprehensive a lib as Golang, which is what you need to create real systems.
- epgui 4y ago
  This probably won’t make sense to most people who haven’t used lisp at work for real work, but… You just really don’t need much to get stuff done with a lisp.
- erik_seaberg 4y ago
  There’s a lot missing from Go’s stdlib, including obvious uses for its builtin types. If you want Common Lisp’s (remove-if-not #'oddp #(1 2 3 4 5)) you have to write a loop from scratch, and then everyone has to read it carefully to learn what it’s doing (and especially what it’s not). Don’t get too excited about having HTTP or JSON built in, we weren’t using those in 1990 and they’ll surely be replaced by 2050.
  - kazinator 4y ago
    Strangely, ANSI CL says that remove-if-not is deprecated. That probably wouldn't be the case if it had been named retain-if or keep-if; the issue is likely the double negative. A function which pares down a sequence to just those elements which match a predicate is very useful; why would you deprecate such a thing.
    - lokedhs 4y ago
      Probably because the idea of the standards group was that you already had REMOVE and COMPLEMENT, so there was no need for it. These days the function is usually called filter, but I'm not sure it was a commonly used term then.
      - kazinator 4y ago

mattbee 4y ago

Your example exposes an edge of Go that speaks to this essay. Yes io.Copy works with any Reader and Writer but dig into the documentation and there's a runtime check for the revised ReaderFrom and WriterTo interfaces that you might also implement for faster performance. It's just something you have to know, otherwise you will not get an optimal copy. Go 1 is right on the edge of being a big language, but what might stop it is that Google don't need it to get any bigger.

ojkelly 4y ago

As much as I’ve been loving Rust, there’s no doubt it’s a hard but rewarding journey to learn it. Go on the other hand, is a language I’m still confident I can teach a junior enough to be useful in an afternoon. The restraint shown by the Go team is admirable in how well they’ve stuck to their vision.

Animats 4y ago

> I think it works because they have spent huge amounts of effort to create a well designed and fairly comprehensive standard library. ... A minimal language that doesn't have resources like Golang to put in the stdlib is just not gonna work. Yes. Rust suffers from this problem. The language is now reasonably solid, but library quality and stability is all over the place. I've been annoying people in the Rust community by saying that it's time to get all widely used crates (over a million downloads, or depended upon by a widely used crate) to version 1.x. After that, no breaking changes without a major version change. Crates with re-exported types from lower levels force groups of crates into lockstep update. The big advantage of Go is that the libraries for doing server-side web stuff are the ones used internally by Google. So they've been thoroughly exercised. The obscure case that comes up once in a trillion transactions probably happened a hundred times in the last hour in a Google server farm.

fbdab103 4y ago
I want a step further than upgrading libraries to 1.0. I really want the Rust foundation to package up the essential libraries (bikeshedding to ensue, but something akin to Python or Go), and release those as a single, annual distribution. Even better if they could standardize the API across all of the packages, ensure minimal unsafe, etc. The `rust_stdlib_v2023` could only depend upon itself, and would be a basis for which other projects could then build from there. It annoys me to no end the huge number of packages I pull in for doing something "simple". It is great that packages can be so small and focused, but now I have a real trust problem. How am I possibly supposed to ensure there are no malicious actors in my dependency tree?
- Animats 4y ago
  There's already a standard library. After that, there's just whatever anybody decided to upload to "crates.io". Nothing in between. Some form of curation and quality control is needed, at least for crates depended upon by other widely used published crates. The Rust foundation's crate manager job is apparently vacant until at least April, so nobody is officially in charge of this. Relevant XKCD: [1] My take on this for game development: [2] [1] https://imgs.xkcd.com/comics/dependency_2x.png https://imgs.xkcd.com/comics/dependency_2x.png [2] https://www.reddit.com/r/rust_gamedev/comments/11b0brr/were_not_really_game_yet/ https://www.reddit.com/r/rust_gamedev/comments/11b0brr/were_...