21–30 of 271 posts
Earlier quoted context omitted.
You can also click on the vertical area between slides to go forward/back.
Also known as "easter egg navigation."
But I've just sent a change to add some help text to these pages: https://go-review.googlesource.com/4910
edit: The change is now live. No more easter egg navigation. Yay!
If that is available for general Java code (i.e. uses JNI) and not just for Android, that could be really huge for Go. Writing performance-sensitive low-level code in Java is still fairly painful, wheras Go still isn't great for writing big programs. I can imagine (for example) Hadoop, Lucene/Elasticsearch and PrestoDB all using this.
Earlier quoted context omitted.
http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_l... The linkers in the gc tool chain (5l, 6l, and 8l) do static linking. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces. A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB, inclu…
> A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB diet gcc -o hello hello.c; strip hello 2280 bytes on my system. There are reasons why using glibc results in executables so big, and why it is tolerated (kind of). Those reasons hardly apply to a new language being actively developed. Yet said language produces executables almost twice the size. "Run-time support an…
fmt.Print does use reflection.
Besides, bickering over the size of hello world is pretty pointless; better to compare the size of programs that actually do something.
We do recognise that Go binaries can and should be smaller, but probably not as small as you might hope.
Earlier quoted context omitted.
http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_l... The linkers in the gc tool chain (5l, 6l, and 8l) do static linking. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces. A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB, inclu…
> A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB diet gcc -o hello hello.c; strip hello 2280 bytes on my system. There are reasons why using glibc results in executables so big, and why it is tolerated (kind of). Those reasons hardly apply to a new language being actively developed. Yet said language produces executables almost twice the size. "Run-time support an…
Most of career has been spent doing web programming, so maybe I'm ignorant, but if you have to build Go with a Go binary, instead of C, doesn't this break OSS's value proposition? (obviously I'd have to start with a C compiler, but that feels a bit purer in my mind, as I can start with a pretty bare-bones OS)
To build gcc, you need a C compiler. To build Go, you need a Go compiler. To compile anything you need to start with some kind of compiler.
Earlier quoted context omitted.
http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_l... The linkers in the gc tool chain (5l, 6l, and 8l) do static linking. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces. A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB, inclu…
> A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB diet gcc -o hello hello.c; strip hello 2280 bytes on my system. There are reasons why using glibc results in executables so big, and why it is tolerated (kind of). Those reasons hardly apply to a new language being actively developed. Yet said language produces executables almost twice the size. "Run-time support an…
Statically. Care to check "ldd hello" of your binary?
> In general, pull request culture is not about code review. This is not true. There are many projects on GitHub which do extensive code reviews on pull requests. It may not be as nice as Gerrit for the type of project like Go (where you often have many iterations or the diffs are large). But for many other projects the UI that GitHub provides is sufficient (and arguably more efficient than Gerrit).
> Better bindings for calling Go from Java. If that is available for general Java code (i.e. uses JNI) and not just for Android, that could be really huge for Go. Writing performance-sensitive low-level code in Java is still fairly painful, wheras Go still isn't great for writing big programs. I can imagine (for example) Hadoop, Lucene/Elasticsearch and PrestoDB all using this.
Go is GC'd just like JVM. The only possible benefit -- even if Go catches up at runtime -- is the compact form of memory objects in Go vs Java object. But then again, if you are writing such systems (in either language) you are very likely to spend quite a lot of time in 'unsafe' land.
Earlier quoted context omitted.
> A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB diet gcc -o hello hello.c; strip hello 2280 bytes on my system. There are reasons why using glibc results in executables so big, and why it is tolerated (kind of). Those reasons hardly apply to a new language being actively developed. Yet said language produces executables almost twice the size. "Run-time support an…
> "Run-time support and type information", why is it linked into a an executable that never allocates memory and does no introspection of any kind? fmt.Print does use reflection. Besides, bickering over the size of hello world is pretty pointless; better to compare the size of programs that actually do something. We do recognise that Go binaries can and should be smaller, but probably not as small as you might hope.…