Shared Go libraries

[mp...@case.edu]

Hi everyone,

I apologize for bursting in here and asking a potentially naive question, but this Google group seems to be the only place for discussion concerning the go language.

One of Go's developer's described it as being a modern C alternative, in that it is a fast, highly scalable, compiled language. I am interested in the language but reluctant to invest a significant amount of time learning and developing in the language. My chief concern is in the creation of static and dynamic libraries. It seems that Go's runtime limits the portability of static libraries and severely hinders the creation of dynamic libraries. One of the greatest appeals of C, for me, is that I can use it to write libraries which I can then wrap into a python, java, etc project. It is my impression that these C libraries are an essential part of what makes these high-level languages so robust and popular.

My question is this- do the developers of Go intend for the language to provide for a low-level foundation upon which high-level languages may build? So far, all of Go's interlanguage support seems to be along the lines of importing C into Go. And if Go will only ever be another end-user of C libraries, then I feel that it may be better to use C for my general library development and keep Go in mind more niche applications.

Any guidance and expertise you can offer is greatly appreciated!

-Matthew

[RickyS]

This could be difficult as Go uses its own garbage collector and has its own non-sharable notion of "Threading".
There is a Cgo package to allow calling back and forth with C code.  http://golang.org/cmd/cgo/
Perhaps Cgo will answer your needs.

[wkharold]

I'm no one of consequence in the go universe but I doubt if the person describing go as a "modern C alternative" was thinking of building libraries that can be wrapped by Python, or Ruby, or Java when they made that statement. If that's what you need to do then by all means stick with C. If you need to build robust, high performance, server-side applications then you could do much worse than go.

Re: shared libraries and dynamic linking I was also nervous about that when I started looking into go, have spent 15 years writing Java code where dynamic code loading is taken for granted. Reading this: http://harmful.cat-v.org/software/dynamic-linking helped me come to terms with go's static linking. Your milage may vary.

... WkH

[Julian Phillips]

On 11/12/2013 23:07, mp...@case.edu wrote:
> Hi everyone,
>
> I apologize for bursting in here and asking a potentially naive
> question,
> but this Google group seems to be the only place for discussion
> concerning
> the go language.

No need to apologise, this is an entirely appropriate question for this
list.

Without wishing to speak to anyone else's intentions, it is my
understanding that whilst there is currently no active pursuit of
supporting such usage - neither is there any animosity towards such
usage. Whilst there are a number of packages around for integration
with high-level languages they do currently focus more on Go being the
primary.

Whilst there is nothing in the language specification that makes it
impossible to write libraries to be used by other languages in Go, it is
certainly not something that is currently easy. I have written an
experimental version of my Go Python bindings that will allow you to
write Python extension modules in Go (http://gopy.qur.me/extensions/),
but it only works with the gccgo toolchain (due to lack of .so support
in the gc toolchain) and there is plenty of icky low-level hackery in
there.

> Any guidance and expertise you can offer is greatly appreciated!

AFAIK, there isn't currently any production ready way to use Go as a
secondary language for high-level languages in the way that you can with
C. I think it may take a while, as there is less incentive to want to
be able to write the bulk of your code in another language than you have
when writing C ... ;) There is also the fact that generally the reason
that a high-level language has C bindings available is that it is itself
implemented in C, so perhaps someone will write a future popular high
level language in Go, and then it would be natural for the low-level
extensions to that language to be written in Go.

I personally would like to have the ability to write production ready
modules for Python in Go, but unless I was to try and find a $DAYJOB
that would be willing to fund it I don't have the time to do more than
poke at it now and then myself.

> -Matthew

--
Julian

[Ian Lance Taylor]

On Wed, Dec 11, 2013 at 3:07 PM, <mp...@case.edu> wrote:
>
> One of Go's developer's described it as being a modern C alternative, in
> that it is a fast, highly scalable, compiled language. I am interested in
> the language but reluctant to invest a significant amount of time learning
> and developing in the language. My chief concern is in the creation of
> static and dynamic libraries. It seems that Go's runtime limits the
> portability of static libraries and severely hinders the creation of dynamic
> libraries. One of the greatest appeals of C, for me, is that I can use it to
> write libraries which I can then wrap into a python, java, etc project. It
> is my impression that these C libraries are an essential part of what makes
> these high-level languages so robust and popular.
>
> My question is this- do the developers of Go intend for the language to
> provide for a low-level foundation upon which high-level languages may
> build? So far, all of Go's interlanguage support seems to be along the lines
> of importing C into Go. And if Go will only ever be another end-user of C
> libraries, then I feel that it may be better to use C for my general library
> development and keep Go in mind more niche applications.

I would be happy to see this feature in Go, and in fact there are some
partial implementations already. Off the top of my head, the issues
to be worked out are how to handle initialization, what symbols to
make available, what should happen when there are multiple Go shared
libraries in an executable image, and how to handle signal handlers.
If somebody could produce a design for these issues--something that is
useful, more than "whatever happens to work"--that would help
enormously.

Ian

[Rolf Lampa]

On Thursday, December 12, 2013 2:08:13 AM UTC+1, Ian Lance Taylor wrote:

On Wed, Dec 11, 2013 at 3:07 PM,  <mp...@case.edu> wrote:
>
> My question is this- do the developers of Go intend for the language to
> provide for a low-level foundation upon which high-level languages may

> build? <...>

I would be happy to see this feature in Go, and in fact there are some

partial implementations already.  <...>

If it were possible today I'd write several new subsystems in Go before this evening, for use with the (MDA) framework I use for Delphi.

// Rolf Lampa

[Brad Fitzpatrick]

Shared libraries and an embedding API (so C code can initialize the Go world) is an ongoing topic.

See:

https://code.google.com/p/go/issues/detail?id=256

https://code.google.com/p/go/issues/detail?id=4848

https://docs.google.com/a/golang.org/document/d/1QcMuZYgEHLBQSGcFXT7YwUkvI1hRxxvXWjOo6MQ_F9k/edit

posts to golang-dev from Elias Naur

etc

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[egon]

If you need immediately start using dynamic libraries then, I would say pass it for now... and I think Rust can do that, although I'm not convinced in it's maturity, yet...

But, if you have time available for learning, I would seriously recommend learning Go. For me, the Go style and approaches have soaked into other languages as well, so it has made me into a better developer. Essentially I've implemented a minimal version of "chan" for Delphi, just to make my concurrent stuff simpler. Also when Go (hopefully eventually) gets support for dynamic libraries you can start immediately using it.

+ egon

[rolf...@gmail.com]

On 2013-12-12 09:44, egon wrote:
> Essentially I've implemented a minimal version of "chan" for Delphi,

Cough, cough... did I just read that? Cough.

(I'm just now sitting here reading up on Indy.) Can you tell me more
about 'chan' f�r Delphi? :)

// Rolf Lampa

[egon]

By minimal, I mean a thread safe blocking queue with go-esque interface. In other words I'm need to use Delphi 7 and couldn't find an implementation for that. If you use Delphi that support generics then there are better things for it (OmniThreadLibrary)...The interface for my chan looks something like:

  IChan = interface

    // closes the channel

    procedure Close;

    function IsClosed: Boolean;

    // puts an item to the queue, waits until it can, raises exception when closed

    procedure Put(const AObject: TObject);

    function TryPut(const AObject: TObject): Boolean;

    // wait for an item, raises an exception when closed and still waiting

    function Take: TObject;

    // for trying to take a value without waiting, raises an exception when closed

    function TryTake(out AObject: TObject): Boolean;

    // for writing while loops that consume until channel is closed

    function Next(out AObject: TObject): Boolean;

  end;

So nothing much... I haven't put time into implementing select and limited num, of items mode... because currently I can manage without them.

+ egon

On Thursday, December 12, 2013 12:28:59 PM UTC+2, Rolf Lampa wrote:

On 2013-12-12 09:44, egon wrote:
> Essentially I've implemented a minimal version of "chan" for Delphi,

Cough, cough... did I just read that? Cough.

(I'm just now sitting here reading up on Indy.)  Can you tell me more

about 'chan' f�r Delphi? :)

// Rolf Lampa

[Rolf Lampa]

This is a charming idea! :) 

Thanks for sharing. I actually also use D7 for now since the framework I use is pre-unicode so I can't use my XE2.

// Rolf Lampa

[mp...@case.edu]

Wow, thank you to everyone for so many helpful replies! I think I will use C for the project at hand, but will definitely return to Go for more exploration. The most important aspect of any language, in my opinion, is a wonderful community, and Go clearly is off to a good start in that respect!

Many thanks,
Matthew