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

51–60 of 91 posts

Re: Simplicity and the ideas Go left behind

#51

Post by MichaelGG »

davecheney wrote: post #26
Daishiman wrote: post #12

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, desp…

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.

But isn't that effectively what the core team did indeed say? They just dismissed everyone's implementations of generics as having a downside, couldn't come up with anything better, then just left it at that. (Edit: This is just my knowledge from a while ago. There's some mailing list thread where every existing way to do generics is dismissed for one reason or another, and well, Go still doesn't have that one feature.)

Also, "Sans runtime"? When did that happen? Last I heard, Go had a fairly substantial runtime to it, making it unsuitable for many places, and not trivially possible to just link right into any old program. And without a runtime, it'd be hard to have a GC, eh?

I think you meant "Statically linked", and nothing at all about runtimes. Rather large difference. FWIW, you can statically link many things, including C#. Which is how C# is deployed e.g. in bestselling iOS apps (and running on iOS has gotta be far from being "tied to the hip" of Windows).

(As a comparison, Rust is actually what is generally meant by "sans runtime", as in you can just call right into a Rust function without setting up anything else (just don't like, call panic or something).)

Re: Simplicity and the ideas Go left behind

#52

Post by Padding »

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…

So how would one implement Erlang-like functionality in Plan9, where the code of a server can be hotswapped while still keeping all existing sockets to the clients open?

Re: Simplicity and the ideas Go left behind

#53

Post by masklinn »

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…

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

Re: Simplicity and the ideas Go left behind

#54

Post by justincormack »

SixSigma wrote: post #50
justincormack wrote: post #47

Earlier quoted context omitted.

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

Ok, here is strace of date(1), which is dynamically linked, on Alpine Linux which uses Musl libc not glibc.

execve("/bin/date", ["date"], [/* 16 vars */]) = 0

mprotect(0x7777dcd5a000, 4096, PROT_READ) = 0

mprotect(0xdc2d89a3000, 4096, PROT_READ) = 0

arch_prctl(ARCH_SET_FS, 0xdc2d89a4268) = 0

set_tid_address(0xdc2d89a4298) = 2439

clock_gettime(CLOCK_REALTIME, {1424769563, 611556639}) = 0

open("/etc/localtime", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = 3

fstat(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0

mmap(NULL, 118, PROT_READ, MAP_SHARED, 3, 0) = 0x7777dcd57000

close(3) = 0

ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0

writev(1, [{"Tue Feb 24 09:19:23 UTC 2015", 28}, {"\n", 1}], 2Tue Feb 24 09:19:23 UTC 2015 ) = 29

close(1) = 0

close(2) = 0

exit_group(0) = ?

+++ exited with 0 +++

Re: Simplicity and the ideas Go left behind

#55

Post by codexon »

MichaelGG wrote: post #45
misframer wrote: post #24

Earlier quoted context omitted.

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.

My thoughts exactly

Re: Simplicity and the ideas Go left behind

#56

Post by 0x434D53 »

MichaelGG wrote: post #45
misframer wrote: post #24

Earlier quoted context omitted.

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.

A slice is not an array of bytes. That's exactly the point.

See http://blog.golang.org/go-slices-usage-and-internals to get a basic understanding

Re: Simplicity and the ideas Go left behind

#57

Post by SixSigma »

justincormack wrote: post #54
SixSigma wrote: post #50

Earlier quoted context omitted.

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

Ok, here is strace of date(1), which is dynamically linked, on Alpine Linux which uses Musl libc not glibc. execve("/bin/date", ["date"], [/* 16 vars */]) = 0 mprotect(0x7777dcd5a000, 4096, PROT_READ) = 0 mprotect(0xdc2d89a3000, 4096, PROT_READ) = 0 arch_prctl(ARCH_SET_FS, 0xdc2d89a4268) = 0 set_tid_address(0xdc2d89a4298) = 2439 clock_gettime(CLOCK_REALTIME, {1424769563, 611556639}) = 0 open("/etc/localtime", O_RDONL…

That is worlds apart.

Re: Simplicity and the ideas Go left behind

#58

Post by SixSigma »

Padding wrote: post #52
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…

So how would one implement Erlang-like functionality in Plan9, where the code of a server can be hotswapped while still keeping all existing sockets to the clients open?

fork, I guess. Plan9 uses files so there is nothing special about sockets.

Re: Simplicity and the ideas Go left behind

#59

Post by Padding »

bsder wrote: post #11
kmontrose wrote: post #9

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# i…

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.

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.

Re: Simplicity and the ideas Go left behind

#60

Post by lmm »

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 are bad design as soon as a library has a security flaw. Remember when there was a double free in zlib and Apple had to release a 1.3GB patch to update everything that linked it in statically - and even that only fixed the problem for Apple-official programs, not for anything the user had installed?
Post reply on HN