9 ms·
Shared libraries? I thought "no DLLs" was one of the major design philosophies of Go.
by giaour 11y ago
Shared libraries? I thought "no DLLs" was one of the major design philosophies of Go.
- vezzy-fnord 11y agoI was surprised too given the Plan 9 culture's rejection of dynamic linking. However, this will probably deprecate or diminish the RPC and code generation techniques for implementing plugin architectures.
- pjmlp 11y agoYet Limbo uses it everywhere.
- sacado2 11y agoYet Limbo is used nowhere. Now that's a paradox ! ;)
- pjmlp 11y agoDidn't you get the memo? It got revamped into Go after a conversation with Oberon-2. :)
- mseepgood 11y agoRobert Griesemer is the Oberon guy in the Go team. He worked for Wirth on Oberon at ETH Zürich.
- pjmlp 11y agoAnyone on the Oberon world should know that. :) I was lucky enough to be able to use Native Oberon back in the day.
- nickpsecurity 11y agoYou can still use it: A2 Bluebottle. I proposed it as a solution to the paranoia of "NSA et al subverted everything! What can we use now and to bootstrap better stuff!?" (raises hand) The well-documented, portable, simple OS and toolchain written by people with no interest in subversion available online for free? Not quite an Ubuntu but more usable than most things people were proposing (eg microcontrollers with hand-written Forth lol). I also thought Modula-2 or Oberon might make a good target for high level languages such as ML or Haskell if we're doing end-to-end safety arguments: one's claims can build on the others.
- ecnahc515 11y agoOne 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.
- pcwalton 11y agoIn particular, you've gotta have DLLs if you want to deploy on Android.
- chadzawistowski 11y agoFurthermore, 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!
- frik 11y agoSpecial case?
- chadzawistowski 11y agoI only meant in an architectural sense. Most Go apps will be standalone, statically linked. Dynamic linking will only be for interop circumstances rather than something everyone does.
- chenzhekl 11y agoThis feature may be prepared for building shared libraries for C. After all, Using shared libraries is popular in C world.
- giaour 11y agoIt 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.
- deleted 11y ago[deleted]
- russell_h 11y agoThat 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.
- NateDad 11y agoThere was a big push from the linux distros as the maintainers had anneurisms thinking they'll need to rebuild hundreds of Go applications when/if a big bug is found in the Go standard library. They also don't like the idea of having N copies of the code for the standard library in N Go applications. Personally, I find that kind of thinking to be a relic of the past when memory and disk space were expensive and compilation took a long time. Sure, if you're running on a raspberry pi, a few megs here and there might actually matter... but even my phone has 2gigs of RAM and 32gigs of disk space.
- groks 11y ago> ...a relic of the past when memory and disk space were expensive ... a few megs here and there might actually matter... The nature of the modern computer is that cpu speed has increased more than memory speed, so if your data doesn't fit into cache your cpu will be do nothing quickly. Even with shared libraries, this phenomena has such an impact that the Linux kernel now has a memory de-duplication feature (mostly for VMs): https://lwn.net/Articles/306704/ https://lwn.net/Articles/306704/
- 4ad 11y agoThis has NOTHING to do with shared libraries vs. statically-linked code. The size of the binary is completely irrelevant when considering if the code fits in the CPU cache. What's important is the size of code that actually executes. Dynamic linking changes nothing.
- twoodfin 11y agoI'm not sure what you mean. Absent some deduplication wizardry by the OS, if I have 60 processes using the "same" statically linked copy of libfoo, that's 60 copies of libfoo's instructions and static data fighting for cache and real memory. Dynamic linking & decades-old virtual memory technology cull that to a single copy.
- mappu 11y agoThe debian snapshot archive is over 30TB. Some single packages take up to 10 hours to build (although all other packages can be built in parallel if you have enough EC2 credit).