Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simplicity and the ideas Go left behind

sourcegraph.com

Post reply on HN
Print view View original

41–50 of 91 posts

Re: Simplicity and the ideas Go left behind

#41

Post by SixSigma »

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.

Re: Simplicity and the ideas Go left behind

#42

Post by crawshaw »

Daishiman wrote: post #35
davecheney wrote: post #26

Earlier quoted context omitted.

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.

This is my own personal opinion on core dev's position and no one else's, but to me generics and dependency management have always been the pink elephant in the room. I can wait for features; I'm patient. But the downright refusal of Go's core team to even begin to address this issue is not just a technical problem, but a communications one. This is clearly big for a lot of people, and I have yet to see any serious r…

Several members of the Go team have put a lot of time into studying and prototyping various implementations of generics.

If you look through the mailing list archives you will find many emails from Ian Lance Taylor on the topic.

Re: Simplicity and the ideas Go left behind

#43

Post by qznc »

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" 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.

Re: Simplicity and the ideas Go left behind

#44

Post by justincormack »

qznc wrote: post #43

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 " 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…

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.

Re: Simplicity and the ideas Go left behind

#45

Post by MichaelGG »

misframer wrote: post #24
codexon wrote: post #3

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.

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.

Why isn't a byte slice a valid key? If anything, there should be a pretty straightforward equality check on an array of bytes.

Re: Simplicity and the ideas Go left behind

#46

Post by Ironballs »

SirWart wrote: post #4

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 complicat…

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.

Re: Simplicity and the ideas Go left behind

#47

Post by justincormack »

SixSigma wrote: post #41

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 fro…

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.

Re: Simplicity and the ideas Go left behind

#48

Post by xorcist »

panic wrote: post #14
iopq wrote: post #13

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 `Opt…

Exactly. If simplicity were the most important thing, we'd all be writing code in Forth or some sort of macro assembler.

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.

Re: Simplicity and the ideas Go left behind

#49

Post by kapilvt »

dengnan wrote: post #7
Mikeb85 wrote: post #6

Earlier quoted context omitted.

Probably something to do with Docker...

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/ 1. https://labix.org/mgo Edit: format.

Also 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 (imho the best one out there.)

goamz -> 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 (imho the best one out there.)

Re: Simplicity and the ideas Go left behind

#50

Post by SixSigma »

justincormack wrote: post #47
SixSigma wrote: post #41

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 fro…

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.

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

Post reply on HN