4 ms·

When people say Go is a simple language, they mean that Go, the literal language, is simple. Some people are also claiming that the programs written in Go are s

by strken 6y ago

When people say Go is a simple language, they mean that Go, the literal language, is simple. Some people are also claiming that the programs written in Go are simple, that the ecosystem is simple, or that using Go is easy, and those people are probably wrong. However, Go the language is actually simple. Here is the Go spec: https://golang.org/ref/spec https://golang.org/ref/spec. Firefox's print dialogue tells me it's 105 pages long. You can read the spec in an afternoon and digest most of it. Here is the ECMAScript 11.0 spec (known as JavaScript to its friends): https://262.ecma-international.org/11.0/ https://262.ecma-international.org/11.0/. Firefox's print dialogue tells me it's 1181 pages long. Here's the Java SE 16 spec: https://docs.oracle.com/javase/specs/jls/se16/jls16.pdf https://docs.oracle.com/javase/specs/jls/se16/jls16.pdf. It's 844 pages long. I can't post the C++20 spec because it's an ISO standard and it costs $399AUD for the privilege of reading it, but it's 1853 pages long in PDF form: https://www.iso.org/standard/79358.html https://www.iso.org/standard/79358.html. On a factual level, Go is a simple language, but so is the language Brainfuck, which has a sort-of-spec that's 9 pages long: https://github.com/brain-lang/brainfuck/blob/master/brainfuck.md https://github.com/brain-lang/brainfuck/blob/master/brainfuc.... Simplicity is not ease of use.

nicoburns 6y ago
> When people say Go is a simple language, they mean that Go, the literal language, is simple. Perhaps. But what use is a language that is simple if it doesn't make it simpler to use or easier to learn? I think most people who claim that Go is simple are claiming the latter, because the former is mostly uninteresting. It's good for IDE support I guess.
- strken 6y ago
  It's a tradeoff. You get a simple language without a lot of surprising features, but sometimes code is very verbose; sometimes problems that would be trivial in other languages require unfortunate solutions like cgo, reflection, strange hacks[0], or code generation; and sometimes the "sensible" opinionated ecosystem doesn't fit how you want to work. [0] https://golang.org/pkg/sort/#example_ https://golang.org/pkg/sort/#example_
- eikenberry 6y ago
  Pencil is a simpler medium than oil paints, but that doesn't make it any easier to do a good portrait with it. Saying its a simple language is expressing a trait of the language that some people may like or find they have an affinity for. People seem to get stuck with the idea that programming languages can only be compared via objective criteria where as we seem to use these sorts of signals to help each other find mediums we like.
pjmlp 6y ago
The C++ standard includes the standard library. If you want a fair comparisasion, include the standard library for the other languages.
- LukeShu 6y ago
  Working from a freely available draft of the C++ 2017 spec: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n465... In total, it's 1622 pages. Without the cross-references and the index it's only 1486 pages. Also excluding the standard library, it's 520 pages. There, the fair comparison is: Go: 105 pages C++17: 520 pages
  - pjmlp 6y ago
    Sure, thanks for putting in the effort. By the way, Java, Python and .NET ones top the C++ one.
- derefr 6y ago
  Eh, that's a bit problematic — there's no standardization in what's in a standard library. Some languages have stdlibs that just contain "stuff everybody needs" — stuff every app or library written in the language will use (common data structures, concurrency primitives, etc.), such that anyone who "knows the language" would also be expected/required to know (or at least know of) those components, if they have any hope of being productive in the language. But other languages have huge stdlibs, that include a bunch of stuff that almost nobody is even aware of, such that most developers won't actually need to know about it in order to effectively maintain other people's code in the language. These are essentially just weird niche libraries that happen to ship with the runtime for some reason. Examples of weird niche libraries that are technically "stdlib": • PHP has an Ingres driver built in. That's Ingres, the predecessor to Postgres. • Ruby ships with a CJK character-normalization CLI utility. • Erlang/OTP has "Megaco" (http://erlang.org/doc/apps/megaco/megaco_intro.html http://erlang.org/doc/apps/megaco/megaco_intro.html) — an H.248 media gateway daemon library. Admittedly, languages do tend to gradually factor these weird niche bits out into separate packages. (Ruby just moved almost all of its stdlib into ecosystem packages in 3.0. Some ecosystem packages are just now install-by-default — but maybe won't be in the future.) Also, the behavior of these weird niche bits is not usually specified as part of the language's spec... but that doesn't mean much, as often, these languages don't even have specs. In those cases, the reference implementation is the spec — and so, if the reference impl includes these libs, "the language" includes these libs.
simiones 6y ago
Well, to be fair, the Go spec is missing several parts of the language, such as finalization, thread safety (the memory model, sync points or other happens-before relationships), goroutine memory/stack usage, anything to do with go modules. Still, even if they added these, it would likely stay significantly shorter than even Java.
- remus 6y ago
  > finalization, thread safety (the memory model, sync points or other happens-before relationships), goroutine memory/stack usage, anything to do with go modules I dont think it affects your point but those are implementation details rather than features of the language itself. Obviously it's still important to understand the language implementation so you can make reasonable guesses about performance etc. when you're programming.
  - kibwen 6y ago
    The point is that other language specifications do include these things, which makes comparing their length to the Go specification inaccurate.
  - simiones 6y ago
    With the exception of goroutine memory/stack usage perhaps, these are not implementation details - they are core parts of the semantics of the language (especially since asynchronicity is a fundamental aspect of the language through goroutines). For example, is this piece of code correct? x := 7 go func() { if x == 7 { fmt.Println("x = 7") } else { fmt.Println("x != 7") } }() x = 8 What are its possible valid outputs? (for the record, as far as I know this is incorrect code in Go, as atomic access is not guaranteed for any variable, so not only could this print any of the two outputs, it could also observe invalid values for x) What about this code: x := 7 c := make(chan struct{}, 0) go func() { if x == 7 { fmt.Println("x = 7") } else { fmt.Println("x != 7") } c<-struct{}{} }() <-c x = 8 Can you tell from the language spec whether this code is safe, and what it's output will be? (~~it's not safe, as far as I know~~ reading the memory model[0], I believe it is safe). [0] https://golang.org/ref/mem https://golang.org/ref/mem
hajile 6y ago
I'd point out that ES5 spec contains the core of the JS language in 258 pages. Following the JS spec alone, it would probably be hard to find any code on the entire internet before 2015 that wouldn't run on your implementation (even though it would undoubtedly run slower). In contrast, if you followed only the go spec, ZERO go code out there would actually run because it doesn't include the rest of the language and core features.

by strken 6y ago

nicoburns 6y ago

> When people say Go is a simple language, they mean that Go, the literal language, is simple. Perhaps. But what use is a language that is simple if it doesn't make it simpler to use or easier to learn? I think most people who claim that Go is simple are claiming the latter, because the former is mostly uninteresting. It's good for IDE support I guess.

strken 6y ago
It's a tradeoff. You get a simple language without a lot of surprising features, but sometimes code is very verbose; sometimes problems that would be trivial in other languages require unfortunate solutions like cgo, reflection, strange hacks[0], or code generation; and sometimes the "sensible" opinionated ecosystem doesn't fit how you want to work. [0] https://golang.org/pkg/sort/#example_ https://golang.org/pkg/sort/#example_
eikenberry 6y ago
Pencil is a simpler medium than oil paints, but that doesn't make it any easier to do a good portrait with it. Saying its a simple language is expressing a trait of the language that some people may like or find they have an affinity for. People seem to get stuck with the idea that programming languages can only be compared via objective criteria where as we seem to use these sorts of signals to help each other find mediums we like.

pjmlp 6y ago

The C++ standard includes the standard library. If you want a fair comparisasion, include the standard library for the other languages.

LukeShu 6y ago
Working from a freely available draft of the C++ 2017 spec: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n465... In total, it's 1622 pages. Without the cross-references and the index it's only 1486 pages. Also excluding the standard library, it's 520 pages. There, the fair comparison is: Go: 105 pages C++17: 520 pages
- pjmlp 6y ago
  Sure, thanks for putting in the effort. By the way, Java, Python and .NET ones top the C++ one.
derefr 6y ago
Eh, that's a bit problematic — there's no standardization in what's in a standard library. Some languages have stdlibs that just contain "stuff everybody needs" — stuff every app or library written in the language will use (common data structures, concurrency primitives, etc.), such that anyone who "knows the language" would also be expected/required to know (or at least know of) those components, if they have any hope of being productive in the language. But other languages have huge stdlibs, that include a bunch of stuff that almost nobody is even aware of, such that most developers won't actually need to know about it in order to effectively maintain other people's code in the language. These are essentially just weird niche libraries that happen to ship with the runtime for some reason. Examples of weird niche libraries that are technically "stdlib": • PHP has an Ingres driver built in. That's Ingres, the predecessor to Postgres. • Ruby ships with a CJK character-normalization CLI utility. • Erlang/OTP has "Megaco" (http://erlang.org/doc/apps/megaco/megaco_intro.html http://erlang.org/doc/apps/megaco/megaco_intro.html) — an H.248 media gateway daemon library. Admittedly, languages do tend to gradually factor these weird niche bits out into separate packages. (Ruby just moved almost all of its stdlib into ecosystem packages in 3.0. Some ecosystem packages are just now install-by-default — but maybe won't be in the future.) Also, the behavior of these weird niche bits is not usually specified as part of the language's spec... but that doesn't mean much, as often, these languages don't even have specs. In those cases, the reference implementation is the spec — and so, if the reference impl includes these libs, "the language" includes these libs.

simiones 6y ago

Well, to be fair, the Go spec is missing several parts of the language, such as finalization, thread safety (the memory model, sync points or other happens-before relationships), goroutine memory/stack usage, anything to do with go modules. Still, even if they added these, it would likely stay significantly shorter than even Java.

remus 6y ago
> finalization, thread safety (the memory model, sync points or other happens-before relationships), goroutine memory/stack usage, anything to do with go modules I dont think it affects your point but those are implementation details rather than features of the language itself. Obviously it's still important to understand the language implementation so you can make reasonable guesses about performance etc. when you're programming.
- kibwen 6y ago
  The point is that other language specifications do include these things, which makes comparing their length to the Go specification inaccurate.
- simiones 6y ago
  With the exception of goroutine memory/stack usage perhaps, these are not implementation details - they are core parts of the semantics of the language (especially since asynchronicity is a fundamental aspect of the language through goroutines). For example, is this piece of code correct? x := 7 go func() { if x == 7 { fmt.Println("x = 7") } else { fmt.Println("x != 7") } }() x = 8 What are its possible valid outputs? (for the record, as far as I know this is incorrect code in Go, as atomic access is not guaranteed for any variable, so not only could this print any of the two outputs, it could also observe invalid values for x) What about this code: x := 7 c := make(chan struct{}, 0) go func() { if x == 7 { fmt.Println("x = 7") } else { fmt.Println("x != 7") } c<-struct{}{} }() <-c x = 8 Can you tell from the language spec whether this code is safe, and what it's output will be? (~~it's not safe, as far as I know~~ reading the memory model[0], I believe it is safe). [0] https://golang.org/ref/mem https://golang.org/ref/mem

hajile 6y ago

I'd point out that ES5 spec contains the core of the JS language in 258 pages. Following the JS spec alone, it would probably be hard to find any code on the entire internet before 2015 that wouldn't run on your implementation (even though it would undoubtedly run slower). In contrast, if you followed only the go spec, ZERO go code out there would actually run because it doesn't include the rest of the language and core features.