9 ms·

Simplicity and the ideas Go left behind

79 points by calavera 12y ago

threeseed 12y ago
> until you realize that Oracle isn’t interested in supporting Java on anything other than Intel hardware. Oracle does support the JVM on embedded hardware. It's right here: http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/index.html http://www.oracle.com/technetwork/java/embedded/embedded-se/... Also since when was Oracle the only JVM vendor. There are plenty of others that support different hardware: http://en.wikipedia.org/wiki/List_of_Java_virtual_machines http://en.wikipedia.org/wiki/List_of_Java_virtual_machines And finally since when has the choice been between slow, interpreted languages and fast, compiled ones ? Plenty of options exist in the space between.
codexon 12y ago
I was using Go recently and I ran into some simplicity issues. It is not straightforward to create a map of net.IPs or manipulate netmasks. You will have to copy to and from a separate array/integer.
- bsder 12y ago
  Congratulations. Welcome to why you don't use Go. Lack of generic access to data structures is one of their bigger fails. However, they don't see it that way. One point of Go was to prevent needing to describe things before being able to compile it. Most things that people regard as "failures" in Go were deliberate choices to enable large codebases.
  - deleted 12y ago
    [deleted]
  - misframer 12y ago
    No, that's not why you don't use go. What the parent comment is dealing with is the fact that you can't have maps keyed by a net.IP, which is implemented as a []byte. Byte slices are not valid keys. This isn't really about generics.
    - chorizos22 12y ago
      What?. A map key type should be parameterized type. Ergo, it is about generics.
    - peterfirefly 12y ago
      It is very much about polymorphism and generics.
- misframer 12y ago
  net.IP is implemented as a []byte. Byte slices are not valid keys (you can't use the "==" operator). An alternative would be to use [16]byte as your map keys and then subslice the array for net.IP.
  - MichaelGG 12y ago
    Why isn't a byte slice a valid key? If anything, there should be a pretty straightforward equality check on an array of bytes.
    - codexon 12y ago
      My thoughts exactly
    - 0x434D53 12y ago
      A slice is not an array of bytes. That's exactly the point. See http://blog.golang.org/go-slices-usage-and-internals http://blog.golang.org/go-slices-usage-and-internals to get a basic understanding
      - MichaelGG 12y ago
        OK so I've read it. Slices sound exactly like one would guess, using the word from other languages. A view into an array. So exactly why are they not suitable for equality? Even that article starts with "Slices are analogous to arrays in other languages". Please elaborate on this basic thing.
        0x434D53 12y ago
        For an array (which are value types in go) you have the obvious element-wise equality. For slices? Also element-wise? Even with different capacities? If the refer to the same window in the underlying array? Is there a need to copy the slice for inserting it to the map? Probably yes, because otherwise you could mutate the key from outside. But then it would be inconsistent to assignment (slices are reference types). I have no idea how this could be done concisely.
- TheDong 12y ago
  That is not a simplicity issue. "Something that is simple may take longer to write and might be more verbose" -- from the article. In a simple language, there should not be functions that do exactly what you want to do; that would be a sign of the language being complex and featureful, which are enemies of simple. (and yes, this is a bit tongue-in-cheek)
  - rtpg 12y ago
    Even in a simple language, simple things should be simple. Granted, it's easy to make complex things sound simple, but the example given seems simple.
SirWart 12y ago
One thing that I've appreciated now that I've spent a decent amount of time writing Go as an individual developer is that it's much easier to jump into open source code and make small improvements and fixes because the language is very "context-free." When you're reading code, the control flow is always spelled out, property accesses never magically invoke getters, and it's generally hard to make things too complicated. There are things that annoy me but the downside is almost always bounded.
- Ironballs 12y ago
  Code readability is the original intent behind striving for simplicity. Though I find some of the design choices a bit frustrating, e.g., generics, lack of min/max; for each design choice I disagree with there are dozens of other choices I do agree with. Structural typing, built-in concurrency, a rich standard library, the syntax, the list goes on. There is a certain brutal elegance to the way the Go standard library is designed, it is really easy to read and comprehend. It took me less than half an hour to make sense how the net/http server was implemented. This doesn't only apply to the standard library: because the language style is standardized--there are no coding styles, there is just a coding style--other libraries or programs are very easy to understand. If the program architecture is easy to understand, it doesn't require any significant domain expertise to understand. Languages aren't supposed to be cargo cults, though some culture can be nice, let's not kid ourselves: programming languages are means to to an end. Go is pragmatic, it gets things done, it is a tool, and most importantly, it doesn't get in the way of design or architecture. You are free to build programs in any style or way you want. Ultimately, languages are just expressions of grander designs that are far more important than arguments for and against a particular syntax or language feature.
fineIllregister 12y ago
>He currently works at Canonical, where part of his work involves porting Go to ARM 64. That's interesting. Has Canonical stated what their interest in Go is?
- Mikeb85 12y ago
  Probably something to do with Docker...
  - dengnan 12y ago
    IIRC, Canonical joined the go community around 2010/2011 when docker has not been created. They are actually one of the early adopters of Go. Some major projects from Canonical using Go are juju[0], mgo[1], etc. 0. https://juju.ubuntu.com/ https://juju.ubuntu.com/ 1. https://labix.org/mgo https://labix.org/mgo Edit: format.
    - georgemcbay 12y ago
      Also go-qml
      - threeseed 12y ago
        Interesting. Perhaps Go becomes the language for Ubuntu Phone apps ?
        NateDad 12y ago
        I believe that is an intended purpose of go-qml, yes.
    - kapilvt 12y ago
      Also lxd https://github.com/lxc/lxd https://github.com/lxc/lxd and in the course of juju, canonical wrote client libraries for quite a few clouds as they didn't exist at the time. openstack -> https://github.com/go-goose/goose https://github.com/go-goose/goose (imho the best one out there.) goamz -> http://github.com/go-amz/go-amz http://github.com/go-amz/go-amz (many forks of this one, aws is going to use a different auto gen'd one for forthcoming official go sdk) azure -> https://launchpad.net/gwacl https://launchpad.net/gwacl (imho the best one out there.)
kmontrose 12y ago
This oversells golang's simplicity I think. Not a lot, but enough to rub me the wrong way a tiny bit. --- > Go programs are built from just their source, which includes all the information needed to fully build the program. Still have to deal with GOPATH, vendor your dependencies, and have everything a `go generate` comment wants to invoke. It's certainly better than makefiles, but it's hardly just the source. > C# is joined at the hip with Windows. Objective-C and Swift are for Apple. Java and Scala and Groovy might benefit from JVM bytecode and its independence… until you realize that Oracle isn’t interested in supporting Java on anything other than Intel hardware. C# has Mono, you can use Objective-C with gcc, the JVM has a bajillion implementations. I suppose Swift is more or less unportable at the moment. 1 out of 4 ain't great. > Go is helping pioneer a command-line renaissance that reintroduces a generation of programmers to the idea of writing tools that fit together like segments in a pipe (the original Unix philosophy). This never went away. Heck we were going over this in college, which for me was in Scheme, Java, C, and C#.
- bsder 12y ago
  I like the fact that the Go guys continue to avoid talking in detail about Rust and Clojure. That tells me that the don't think they can win the comparison.
  - Padding 12y ago
    Who can win against lisp anyways? The reasons we aren't seeing more lisp/clojure are not technical/objective ones but attitude, social and nework factors - which are just as relevant though.
  - NateDad 12y ago
    The core goals behind Rust and Clojure are very different from those behind Go. This article/presentation would not be appropriate for those languages. I don't think anyone would say that Rust or Clojure are simple languages, or that simplicity is a core goal for them. Rust's core goals are performance, memory safety, and lack of race conditions (AFAICT). And clojure is a LISP which puts it in its own category, really. It's like saying a jeep can't compare to a ferrari or a minivan - other than having 4 wheels, they're really not at all designed to do the same kinds of things... Sure, maybe driving to the corner store they're all pretty much the same, but which do you want in 8" of mud? Which do you want in a car chase on the highway? Which do you want to bring your 4 kids to soccer practice?
Daishiman 12y ago
This answer is slightly infuriating: > Q: Lack of generic collection classes like in Java’s Guava library?A: For 90% of cases, slices and maps do what you need. For the other 10%, you might consider whether your package should own the logic of those special containers, instead of using an external package. I read this as: "We're not willing to put in the hard work on thinking of a decent generics implementation, despite decades of working solutions with a myriad of choices in tradeoffs, so you'll have to do the hard work of integrating a dozen different collections libraries and who knows how many different, after-the-fact, mediocre strategies to the generics issue, each slighly off, all of them conceptually incomplete somehow, and with the slight bugs that come from not having a well-trodden path for an essential component of most programming languages."
- davecheney 12y ago
  I am not a member of the Go team, just a contributor. I represent only my own opinions, please don't put words into my mouth.
  - TheDong 12y ago
    He is not putting words in your mouth, he's stating his own interpretation. No sane person would read "I read this as" and assume that this is in fact exactly what the speaker said, nor should any speaker assume "I read this as" is meant as a defamation or misquote. In addition, you being a contributor not a core team member does not change what you said in the least. A language's design, even if it seems like there's a tight core, is ultimately decided in part by all contributors and the community around it as well.
    - davecheney 12y ago
      The use of the opening phrase "We're not willing ... " implies that the OP interpreted my statements as a policy of the wider Go team. I have no knowledge of any such policy and represent only myself on stage. You can think what you like about my statements, just don't generalise them to anyone else.
  - 12y ago
iopq 12y ago
Consider the following: it is actually more difficult to code in a language that's simple Why? Because a more feature-complete language allows you to ELIMINATE the concept of `nil` through an `Option` type. An `Option` type is an `enum` that consists of either `Some(x)` or `None`. That means it is always checked. You can never accidentally use a value that is `None` because the type checker would not let you use `Option<T>` instead of `T` itself. The code snippets on the websites are far from simple. You HAVE TO remember to do `if err != nil` in every single function. A more advanced type system would actually make this a requirement. So what is more important, the simplicity of the language or lack of bugs?
- panic 12y ago
  Exactly. If simplicity were the most important thing, we'd all be writing code in Forth or some sort of macro assembler.
  - WalterBright 12y ago
    It's true that assembler is actually pretty simple. It's just that the simple instructions combine in hard to understand ways.
  - xorcist 12y ago
    You could have said Lisp instead, and it's not hard to find people making that case. It's a tradeoff between designing your own complex building blocks or having very complex tools with thousands of them ready-made. I won't pretend to have an easy answer, but I do know I personally prefer when people err on the side of simpler tools.
- nexneo 12y ago
  Go depends on tools to check correctness that type system doesn't cover. Check, http://blog.golang.org/error-handling-and-go http://blog.golang.org/error-handling-and-go and https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck
  - nostrademons 12y ago
SixSigma 12y ago
It is interesting that the OP things that static binaries is related to being born in Google. The thing is that Plan9 doesn't have shared libraries, all binaries are statically linked. And the reason for this is that plan9 is a networked operating system, needing to load multiple files at runtime would severely harm startup time for a binary. Run trace on a Linux binary and see the slew of "file not found" errors from syscalls looking for shared libs at startup and then imagine each one of these is taking place over a 9600 baud connection. Good design realises benefits that authors never needed to consider.
- justincormack 12y ago
  Static binaries used to be common, the normal way of doing stuff. People tend to think that package management killed them, but it was actually glibc which cannot make proper static binaries as it insists on dynamic functionality for some functions, such as name resolution. Now we have Musl libc there may well be a revival in static binaries from C applications, and the C-derived ecosystem.
  - SixSigma 12y ago
    As a demonstration I traced date(1) on CentOS. Here are the file accesses, if you are running diskless, each of these needs a round trip to the file server. (except the final 3, of course) access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=54185, ...}) = 0 close(3) = 0 open("/lib64/librt.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@!\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=43880, ...}) = 0 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\356\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1921176, ...}) = 0 close(3) = 0 open("/lib64/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340]\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=142640, ...}) = 0 close(3) = 0 open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=99158576, ...}) = 0 close(3) = 0 open("/etc/localtime", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0 fstat(3, {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0 read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\7\0\0\0\7\0\0\0\0"..., 4096) = 3661 lseek(3, -2338, SEEK_CUR) = 1323 read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\10\0\0\0\0"..., 4096) = 2338 close(3) = 0 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 write(1, "Tue Feb 24 08:57:58 GMT 2015\n", 29) = 29 close(1) = 0
qznc 12y ago
I'd argue that in most cases "easy > simple" with the definitions of Rich Hickey. Easy means you understand it quickly. Simple means it uses few concepts. Go doesn't want to use the concept of generics. However, if your code uses "List<IP>" instead of "List", it is easier to understand, because it additionally tells you it is about IPs. Python is a language which tries to be easy by resembling pseudo code. If you really want simple, you could as well use SML, TCL, or Lua.
- justincormack 12y ago
  Indeed Lua came to mind with his "Dave can’t think of any language in his lifetime that didn’t start out with simplicity as a core goal. Yet he can’t think of any language in his lifetime that didn’t eventually become more complex and “powerful”." quote - it has stayed simple and removed features.
- masklinn 12y ago
  > If you really want simple, you could as well use SML, TCL, or Lua. And if you truly want simple, you use Smalltalk, Scheme or Forth.
  - kazagistar 12y ago
    I dunno about smalltalk, but Scheme and Forth start off simple until a programmer writes tens of thousands of lines of code, at which point it gets harder to read and follow the code exactly.
    - qznc 12y ago
      No matter how much convoluted code your write, it is still a "simple language". Your code however is not necessarily simple or easy.
      - masklinn 12y ago
        That tends to be the flip side of the "simple language". And at least the 3 languages quoted are so simple that they must provide the tools for building new abstractions (which are the tools for building the language in the first place), so you can cut down on code by building a reusable toolbox of abstractions. Go is complex enough that they can get away without that, and even get praised for pushing the complexity to userland code and providing no way for users to manage that complexity.
swah 12y ago
Would we be better off if the big Apache projects were written in Go instead of Java? Would that have been harder (starting today, say)?

79 points by calavera 12y ago

> until you realize that Oracle isn’t interested in supporting Java on anything other than Intel hardware. Oracle does support the JVM on embedded hardware. It's right here: http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/index.html http://www.oracle.com/technetwork/java/embedded/embedded-se/... Also since when was Oracle the only JVM vendor. There are plenty of others that support different hardware: http://en.wikipedia.org/wiki/List_of_Java_virtual_machines http://en.wikipedia.org/wiki/List_of_Java_virtual_machines And finally since when has the choice been between slow, interpreted languages and fast, compiled ones ? Plenty of options exist in the space between.

codexon 12y ago

I was using Go recently and I ran into some simplicity issues. It is not straightforward to create a map of net.IPs or manipulate netmasks. You will have to copy to and from a separate array/integer.

bsder 12y ago
Congratulations. Welcome to why you don't use Go. Lack of generic access to data structures is one of their bigger fails. However, they don't see it that way. One point of Go was to prevent needing to describe things before being able to compile it. Most things that people regard as "failures" in Go were deliberate choices to enable large codebases.
- deleted 12y ago
  [deleted]
- misframer 12y ago
  No, that's not why you don't use go. What the parent comment is dealing with is the fact that you can't have maps keyed by a net.IP, which is implemented as a []byte. Byte slices are not valid keys. This isn't really about generics.
  - chorizos22 12y ago
    What?. A map key type should be parameterized type. Ergo, it is about generics.
  - peterfirefly 12y ago
    It is very much about polymorphism and generics.
misframer 12y ago
net.IP is implemented as a []byte. Byte slices are not valid keys (you can't use the "==" operator). An alternative would be to use [16]byte as your map keys and then subslice the array for net.IP.
- MichaelGG 12y ago
  Why isn't a byte slice a valid key? If anything, there should be a pretty straightforward equality check on an array of bytes.
  - codexon 12y ago
    My thoughts exactly
  - 0x434D53 12y ago
    A slice is not an array of bytes. That's exactly the point. See http://blog.golang.org/go-slices-usage-and-internals http://blog.golang.org/go-slices-usage-and-internals to get a basic understanding
    - MichaelGG 12y ago
      OK so I've read it. Slices sound exactly like one would guess, using the word from other languages. A view into an array. So exactly why are they not suitable for equality? Even that article starts with "Slices are analogous to arrays in other languages". Please elaborate on this basic thing.
      - 0x434D53 12y ago
        For an array (which are value types in go) you have the obvious element-wise equality. For slices? Also element-wise? Even with different capacities? If the refer to the same window in the underlying array? Is there a need to copy the slice for inserting it to the map? Probably yes, because otherwise you could mutate the key from outside. But then it would be inconsistent to assignment (slices are reference types). I have no idea how this could be done concisely.
TheDong 12y ago
That is not a simplicity issue. "Something that is simple may take longer to write and might be more verbose" -- from the article. In a simple language, there should not be functions that do exactly what you want to do; that would be a sign of the language being complex and featureful, which are enemies of simple. (and yes, this is a bit tongue-in-cheek)
- rtpg 12y ago
  Even in a simple language, simple things should be simple. Granted, it's easy to make complex things sound simple, but the example given seems simple.

SirWart 12y ago

One thing that I've appreciated now that I've spent a decent amount of time writing Go as an individual developer is that it's much easier to jump into open source code and make small improvements and fixes because the language is very "context-free." When you're reading code, the control flow is always spelled out, property accesses never magically invoke getters, and it's generally hard to make things too complicated. There are things that annoy me but the downside is almost always bounded.

Ironballs 12y ago
Code readability is the original intent behind striving for simplicity. Though I find some of the design choices a bit frustrating, e.g., generics, lack of min/max; for each design choice I disagree with there are dozens of other choices I do agree with. Structural typing, built-in concurrency, a rich standard library, the syntax, the list goes on. There is a certain brutal elegance to the way the Go standard library is designed, it is really easy to read and comprehend. It took me less than half an hour to make sense how the net/http server was implemented. This doesn't only apply to the standard library: because the language style is standardized--there are no coding styles, there is just a coding style--other libraries or programs are very easy to understand. If the program architecture is easy to understand, it doesn't require any significant domain expertise to understand. Languages aren't supposed to be cargo cults, though some culture can be nice, let's not kid ourselves: programming languages are means to to an end. Go is pragmatic, it gets things done, it is a tool, and most importantly, it doesn't get in the way of design or architecture. You are free to build programs in any style or way you want. Ultimately, languages are just expressions of grander designs that are far more important than arguments for and against a particular syntax or language feature.

fineIllregister 12y ago

>He currently works at Canonical, where part of his work involves porting Go to ARM 64. That's interesting. Has Canonical stated what their interest in Go is?

Mikeb85 12y ago
Probably something to do with Docker...
- dengnan 12y ago
  IIRC, Canonical joined the go community around 2010/2011 when docker has not been created. They are actually one of the early adopters of Go. Some major projects from Canonical using Go are juju[0], mgo[1], etc. 0. https://juju.ubuntu.com/ https://juju.ubuntu.com/ 1. https://labix.org/mgo https://labix.org/mgo Edit: format.
  - georgemcbay 12y ago
    Also go-qml
    - threeseed 12y ago
      Interesting. Perhaps Go becomes the language for Ubuntu Phone apps ?
      - NateDad 12y ago
        I believe that is an intended purpose of go-qml, yes.
  - kapilvt 12y ago
    Also lxd https://github.com/lxc/lxd https://github.com/lxc/lxd and in the course of juju, canonical wrote client libraries for quite a few clouds as they didn't exist at the time. openstack -> https://github.com/go-goose/goose https://github.com/go-goose/goose (imho the best one out there.) goamz -> http://github.com/go-amz/go-amz http://github.com/go-amz/go-amz (many forks of this one, aws is going to use a different auto gen'd one for forthcoming official go sdk) azure -> https://launchpad.net/gwacl https://launchpad.net/gwacl (imho the best one out there.)

kmontrose 12y ago

This oversells golang's simplicity I think. Not a lot, but enough to rub me the wrong way a tiny bit. --- > Go programs are built from just their source, which includes all the information needed to fully build the program. Still have to deal with GOPATH, vendor your dependencies, and have everything a `go generate` comment wants to invoke. It's certainly better than makefiles, but it's hardly just the source. > C# is joined at the hip with Windows. Objective-C and Swift are for Apple. Java and Scala and Groovy might benefit from JVM bytecode and its independence… until you realize that Oracle isn’t interested in supporting Java on anything other than Intel hardware. C# has Mono, you can use Objective-C with gcc, the JVM has a bajillion implementations. I suppose Swift is more or less unportable at the moment. 1 out of 4 ain't great. > Go is helping pioneer a command-line renaissance that reintroduces a generation of programmers to the idea of writing tools that fit together like segments in a pipe (the original Unix philosophy). This never went away. Heck we were going over this in college, which for me was in Scheme, Java, C, and C#.

bsder 12y ago
I like the fact that the Go guys continue to avoid talking in detail about Rust and Clojure. That tells me that the don't think they can win the comparison.
- Padding 12y ago
  Who can win against lisp anyways? The reasons we aren't seeing more lisp/clojure are not technical/objective ones but attitude, social and nework factors - which are just as relevant though.
- NateDad 12y ago
  The core goals behind Rust and Clojure are very different from those behind Go. This article/presentation would not be appropriate for those languages. I don't think anyone would say that Rust or Clojure are simple languages, or that simplicity is a core goal for them. Rust's core goals are performance, memory safety, and lack of race conditions (AFAICT). And clojure is a LISP which puts it in its own category, really. It's like saying a jeep can't compare to a ferrari or a minivan - other than having 4 wheels, they're really not at all designed to do the same kinds of things... Sure, maybe driving to the corner store they're all pretty much the same, but which do you want in 8" of mud? Which do you want in a car chase on the highway? Which do you want to bring your 4 kids to soccer practice?

Daishiman 12y ago

This answer is slightly infuriating: > Q: Lack of generic collection classes like in Java’s Guava library?A: For 90% of cases, slices and maps do what you need. For the other 10%, you might consider whether your package should own the logic of those special containers, instead of using an external package. I read this as: "We're not willing to put in the hard work on thinking of a decent generics implementation, despite decades of working solutions with a myriad of choices in tradeoffs, so you'll have to do the hard work of integrating a dozen different collections libraries and who knows how many different, after-the-fact, mediocre strategies to the generics issue, each slighly off, all of them conceptually incomplete somehow, and with the slight bugs that come from not having a well-trodden path for an essential component of most programming languages."

davecheney 12y ago
I am not a member of the Go team, just a contributor. I represent only my own opinions, please don't put words into my mouth.
- TheDong 12y ago
  He is not putting words in your mouth, he's stating his own interpretation. No sane person would read "I read this as" and assume that this is in fact exactly what the speaker said, nor should any speaker assume "I read this as" is meant as a defamation or misquote. In addition, you being a contributor not a core team member does not change what you said in the least. A language's design, even if it seems like there's a tight core, is ultimately decided in part by all contributors and the community around it as well.
  - davecheney 12y ago
    The use of the opening phrase "We're not willing ... " implies that the OP interpreted my statements as a policy of the wider Go team. I have no knowledge of any such policy and represent only myself on stage. You can think what you like about my statements, just don't generalise them to anyone else.
- 12y ago

iopq 12y ago

Consider the following: it is actually more difficult to code in a language that's simple Why? Because a more feature-complete language allows you to ELIMINATE the concept of `nil` through an `Option` type. An `Option` type is an `enum` that consists of either `Some(x)` or `None`. That means it is always checked. You can never accidentally use a value that is `None` because the type checker would not let you use `Option<T>` instead of `T` itself. The code snippets on the websites are far from simple. You HAVE TO remember to do `if err != nil` in every single function. A more advanced type system would actually make this a requirement. So what is more important, the simplicity of the language or lack of bugs?

panic 12y ago
Exactly. If simplicity were the most important thing, we'd all be writing code in Forth or some sort of macro assembler.
- WalterBright 12y ago
  It's true that assembler is actually pretty simple. It's just that the simple instructions combine in hard to understand ways.
- xorcist 12y ago
  You could have said Lisp instead, and it's not hard to find people making that case. It's a tradeoff between designing your own complex building blocks or having very complex tools with thousands of them ready-made. I won't pretend to have an easy answer, but I do know I personally prefer when people err on the side of simpler tools.
nexneo 12y ago
Go depends on tools to check correctness that type system doesn't cover. Check, http://blog.golang.org/error-handling-and-go http://blog.golang.org/error-handling-and-go and https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck
- nostrademons 12y ago

SixSigma 12y ago

It is interesting that the OP things that static binaries is related to being born in Google. The thing is that Plan9 doesn't have shared libraries, all binaries are statically linked. And the reason for this is that plan9 is a networked operating system, needing to load multiple files at runtime would severely harm startup time for a binary. Run trace on a Linux binary and see the slew of "file not found" errors from syscalls looking for shared libs at startup and then imagine each one of these is taking place over a 9600 baud connection. Good design realises benefits that authors never needed to consider.

justincormack 12y ago
Static binaries used to be common, the normal way of doing stuff. People tend to think that package management killed them, but it was actually glibc which cannot make proper static binaries as it insists on dynamic functionality for some functions, such as name resolution. Now we have Musl libc there may well be a revival in static binaries from C applications, and the C-derived ecosystem.
- SixSigma 12y ago
  As a demonstration I traced date(1) on CentOS. Here are the file accesses, if you are running diskless, each of these needs a round trip to the file server. (except the final 3, of course) access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=54185, ...}) = 0 close(3) = 0 open("/lib64/librt.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@!\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=43880, ...}) = 0 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\356\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1921176, ...}) = 0 close(3) = 0 open("/lib64/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340]\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=142640, ...}) = 0 close(3) = 0 open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=99158576, ...}) = 0 close(3) = 0 open("/etc/localtime", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0 fstat(3, {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0 read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\7\0\0\0\7\0\0\0\0"..., 4096) = 3661 lseek(3, -2338, SEEK_CUR) = 1323 read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\10\0\0\0\0"..., 4096) = 2338 close(3) = 0 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 write(1, "Tue Feb 24 08:57:58 GMT 2015\n", 29) = 29 close(1) = 0

qznc 12y ago

I'd argue that in most cases "easy > simple" with the definitions of Rich Hickey. Easy means you understand it quickly. Simple means it uses few concepts. Go doesn't want to use the concept of generics. However, if your code uses "List<IP>" instead of "List", it is easier to understand, because it additionally tells you it is about IPs. Python is a language which tries to be easy by resembling pseudo code. If you really want simple, you could as well use SML, TCL, or Lua.

justincormack 12y ago
Indeed Lua came to mind with his "Dave can’t think of any language in his lifetime that didn’t start out with simplicity as a core goal. Yet he can’t think of any language in his lifetime that didn’t eventually become more complex and “powerful”." quote - it has stayed simple and removed features.
masklinn 12y ago
> If you really want simple, you could as well use SML, TCL, or Lua. And if you truly want simple, you use Smalltalk, Scheme or Forth.
- kazagistar 12y ago
  I dunno about smalltalk, but Scheme and Forth start off simple until a programmer writes tens of thousands of lines of code, at which point it gets harder to read and follow the code exactly.
  - qznc 12y ago
    No matter how much convoluted code your write, it is still a "simple language". Your code however is not necessarily simple or easy.
    - masklinn 12y ago
      That tends to be the flip side of the "simple language". And at least the 3 languages quoted are so simple that they must provide the tools for building new abstractions (which are the tools for building the language in the first place), so you can cut down on code by building a reusable toolbox of abstractions. Go is complex enough that they can get away without that, and even get praised for pushing the complexity to userland code and providing no way for users to manage that complexity.

swah 12y ago

Would we be better off if the big Apache projects were written in Go instead of Java? Would that have been harder (starting today, say)?