The State of Go • Hacker News Board

Re: The State of Go

#21

Post by iokevins » Wed, May 27, 2015, 4:04 AM UTC

nickysielicki wrote: post #10

melling wrote: post #2

Nice little change in syntax. m := map[Point]string{ Point{29.935523, 52.891566}: "Persepolis", Point{-25.352594, 131.034361}: "Uluru", Point{37.422455, -122.084306}: "Googleplex", } may now be written as: m := map[Point]string{ {29.935523, 52.891566}: "Persepolis", {-25.352594, 131.034361}: "Uluru", {37.422455, -122.084306}: "Googleplex", }

I came into the comments to say that I very much dislike this change. I much prefer the extra syntax to not really knowing what '{29.935523, 52.891566}' actually means.

They seem to say you may choose to continue specifying it, as you prefer (?)

Re: The State of Go

#22

Post by chadzawistowski » Wed, May 27, 2015, 4:08 AM UTC

ecnahc515 wrote: post #8

giaour wrote: post #3

Shared libraries? I thought "no DLLs" was one of the major design philosophies of Go.

One of the major design philosophies was ease of deployment, DLLs generally complicate that process, but for many purposes, they're a necessary tool. Interop with existing libraries is certainly a worthy enough feature to add to the Go toolchain, and it's an optional feature, so ease of deployment is still a primary concern, but if you need DLLs, this is available.

Furthermore, the years they spent where dynamic linking were not allowed incubated the culture -- even though dynamic linking is now allowed, it really will be a special case!

Re: The State of Go

#23

Post by giaour » Wed, May 27, 2015, 4:10 AM UTC

chenzhekl wrote: post #9

giaour wrote: post #3

Shared libraries? I thought "no DLLs" was one of the major design philosophies of Go.

This feature may be prepared for building shared libraries for C. After all, Using shared libraries is popular in C world.

It might also make it possible to write Node/PHP/Ruby/Python libraries in Go instead of C++. I've been looking at Rust for that use but the ability to compile Go to a C archive throws in back in the running.

Re: The State of Go

#24

Post by [deleted] » Wed, May 27, 2015, 4:10 AM UTC

chenzhekl wrote: post #9

giaour wrote: post #3

Shared libraries? I thought "no DLLs" was one of the major design philosophies of Go.

This feature may be prepared for building shared libraries for C. After all, Using shared libraries is popular in C world.

[deleted]

Re: The State of Go

#25

Post by russell_h » Wed, May 27, 2015, 4:10 AM UTC

giaour wrote: post #3

Shared libraries? I thought "no DLLs" was one of the major design philosophies of Go.

That has generally been true as far as Go packages are concerned, but by default the binaries that Go generates still dynamically link against any C libraries - in particular just about any Go binary will break in the absence of a compatible libc.

I don't know the background on this choice, but I've spoken to a few Go shops that have complained about memory usage when running a bunch of different Go binaries on the same machine, so hopefully this will help there.

Re: The State of Go

#26

Post by mholt » Wed, May 27, 2015, 4:17 AM UTC

nkozyra wrote: post #6

"Go 1.5 provides support for Android and experimental support for iOS." Tell me more ...

`gomobile install` to build an APK and install it on a device. Cool.

Re: The State of Go

#27

Post by [deleted] » Wed, May 27, 2015, 4:20 AM UTC

[deleted]

Re: The State of Go

#28

Post by zak_mc_kracken » Wed, May 27, 2015, 4:22 AM UTC

melling wrote: post #2

Nice little change in syntax. m := map[Point]string{ Point{29.935523, 52.891566}: "Persepolis", Point{-25.352594, 131.034361}: "Uluru", Point{37.422455, -122.084306}: "Googleplex", } may now be written as: m := map[Point]string{ {29.935523, 52.891566}: "Persepolis", {-25.352594, 131.034361}: "Uluru", {37.422455, -122.084306}: "Googleplex", }

I'm puzzled about the asymmetry of the syntax. What's the reason behind

    map[Point]string

as opposed to something more symmetrical?

Re: The State of Go

#29

Post by frik » Wed, May 27, 2015, 4:28 AM UTC

Shared library support, thanks!

Re: The State of Go

#30

Post by frik » Wed, May 27, 2015, 4:33 AM UTC

chadzawistowski wrote: post #22

ecnahc515 wrote: post #8

Earlier quoted context omitted.

One of the major design philosophies was ease of deployment, DLLs generally complicate that process, but for many purposes, they're a necessary tool. Interop with existing libraries is certainly a worthy enough feature to add to the Go toolchain, and it's an optional feature, so ease of deployment is still a primary concern, but if you need DLLs, this is available.

Furthermore, the years they spent where dynamic linking were not allowed incubated the culture -- even though dynamic linking is now allowed, it really will be a special case!

Special case?