FAQ
I wrote a little post about my planning to create a team to can build
libraries of low-level for graphics, audio and input. Anthough it will be
built in Rust due to its memory model, I want that it can be used in Go too
through a wrapper like can be done in C, and although it cann't be done
now, it is possible and the Rust team will add a mechanism to allow it.
So Go developers also could use it; don't forget that I use both languages
and I'm interested in use them from Go too.

I would thank whatever comment related to the questions that I wrote in the
post. Thanks!

http://redd.it/15q9ph
https://gist.github.com/4419687 (This is the post)

--

Search Discussions

  • Bryanturley at Jan 1, 2013 at 4:00 am

    On Monday, December 31, 2012 12:11:51 PM UTC-7, Archos wrote:
    I wrote a little post about my planning to create a team to can build
    libraries of low-level for graphics, audio and input. Anthough it will be
    built in Rust due to its memory model, I want that it can be used in Go too
    through a wrapper like can be done in C, and although it cann't be done
    now, it is possible and the Rust team will add a mechanism to allow it.
    So Go developers also could use it; don't forget that I use both languages
    and I'm interested in use them from Go too.

    I would thank whatever comment related to the questions that I wrote in
    the post. Thanks!

    http://redd.it/15q9ph
    https://gist.github.com/4419687 (This is the post)
    Defiine low level multimedia library.

    --
  • Archos at Jan 1, 2013 at 8:00 am
    I mean low-level functions, used to access to graphics, audio and input
    devices. There will be high-level functions over the another ones, but
    that's the beginning.

    El martes, 1 de enero de 2013 04:00:29 UTC, bryanturley escribió:
    On Monday, December 31, 2012 12:11:51 PM UTC-7, Archos wrote:

    I wrote a little post about my planning to create a team to can build
    libraries of low-level for graphics, audio and input. Anthough it will be
    built in Rust due to its memory model, I want that it can be used in Go too
    through a wrapper like can be done in C, and although it cann't be done
    now, it is possible and the Rust team will add a mechanism to allow it.
    So Go developers also could use it; don't forget that I use both
    languages and I'm interested in use them from Go too.

    I would thank whatever comment related to the questions that I wrote in
    the post. Thanks!

    http://redd.it/15q9ph
    https://gist.github.com/4419687 (This is the post)
    Defiine low level multimedia library.
    --
  • Bryanturley at Jan 1, 2013 at 9:36 am

    On Tuesday, January 1, 2013 2:00:33 AM UTC-6, Archos wrote:
    I mean low-level functions, used to access to graphics, audio and input
    devices. There will be high-level functions over the another ones, but
    that's the beginning.

    Well anyone that wants to do that seriously is going to use an existing
    library. You aren't planning on implementing say opengl or openal over
    again completely in go are you?
    Would take a while to replicate ffmpeg or similar non-hardware related
    multimedia libraries as well.

    I think even with rust they will just use the system opengl since webgl
    maps onto it intentionally and writing your own opengl implementation for
    dozens of gpu's is an army of fulltime jobs.

    There might be some room for an input library though, but why would a go
    user want to use a rust library when they could just use a native go
    library or a c library?

    And why did they name the language rust? Rust makes me think of decaying
    machinery and tetnis.

    --
  • Krzysztof Kowalczyk at Jan 1, 2013 at 9:09 am
    By all means go for it.

    However, from the point of view of Go developer who needs such
    functionality, there are plenty of such libraries in C that can already be
    used from Go and some of them have Go wrappers today:
    http://go-lang.cat-v.org/library-bindings

    Even when there is a Rust code that can be exposed as a dll (and I don't
    think it's possible today), it won't be a good solution on technical
    merits.

    Rust, just like Go, needs its own runtime. Even the smallest Rust code will
    need that runtime and just like doing fmt.Printf() in Go baloons the
    executable size because it pulls a big part of Go's standard library, doing
    anything non-trivial in Rust will do the same, so you'll end up with a huge
    overhead of Rust runtime for relatively small functionality.

    And you'll double function call overhead. I assume Rust code will just wrap
    existing C code on each platform (unless you plan to rewrite OpenGL in
    Rust) so Go code will call a Rust function which will call C function
    instead of just calling C function.

    Also, to quote your post: "the libraries will be developed in Rust because
    its memory model provides a lot more power and flexibility than Go which is
    necessary for libraries of low level" implies that such code cannot be done
    in Go, which is false. Go has unsafe and ability to write assembly code for
    the pieces that cannot be written in Go, so there's everything you need for
    low-level bindings and plenty of such bindings exist.

    Finally, Rust is developed by Mozilla with the explicit goal of using it to
    develop a cross-platform web browser. What does a moder web browser needs?
    A performant graphics, sound and ui libraries. Those kinds of libraries
    will be the first ones to be written by Mozilla itself and they already
    have plenty of developers that are experts in those domains.

    -- kjk
    On Mon, Dec 31, 2012 at 11:11 AM, Archos wrote:

    https://gist.github.com/4419687
    --
  • Archos at Jan 1, 2013 at 11:05 am
    El martes, 1 de enero de 2013 09:09:32 UTC, Krzysztof Kowalczyk escribió:
    By all means go for it.

    However, from the point of view of Go developer who needs such
    functionality, there are plenty of such libraries in C that can already be
    used from Go and some of them have Go wrappers today:
    http://go-lang.cat-v.org/library-bindings
    1. Those C libraries have different licenses and some of them are no
    suitable to be used in some projects, i.e. OpenAL is using GNU LGPL

    http://connect.creativelabs.com/openal/OpenAL%20Wiki/Platforms.aspx

    2. They have been built by different people. The advantage of building a
    SDK from scratch is that you have a consistent API for all libraries, the
    same license, and the same rules for all documentation. Just like you can
    see in the Go's standard library.

    Even when there is a Rust code that can be exposed as a dll (and I don't
    think it's possible today), it won't be a good solution on technical
    merits.

    Rust, just like Go, needs its own runtime. Even the smallest Rust code
    will need that runtime and just like doing fmt.Printf() in Go baloons the
    executable size because it pulls a big part of Go's standard library, doing
    anything non-trivial in Rust will do the same, so you'll end up with a huge
    overhead of Rust runtime for relatively small functionality.
    They need to make that libraries that aren't dependent on the rust
    scheduler can be written independent of it. This is somewhat tricky because
    that basically means that they become vulnerable to security
    vulnerabilities resulting from stack overflow, but they can probably come
    up with some solution to that.

    And you'll double function call overhead. I assume Rust code will just wrap
    existing C code on each platform (unless you plan to rewrite OpenGL in
    Rust) so Go code will call a Rust function which will call C function
    instead of just calling C function.
    I'm not going to wrap C code, else all those libraries will be built from
    scratch in Rust. I know it is a lot of work but I'm very perseverant to get
    what I want.

    Also, to quote your post: "the libraries will be developed in Rust because
    its memory model provides a lot more power and flexibility than Go which is
    necessary for libraries of low level" implies that such code cannot be done
    in Go, which is false. Go has unsafe and ability to write assembly code for
    the pieces that cannot be written in Go, so there's everything you need for
    low-level bindings and plenty of such bindings exist.
    To get the same kind of fine-grained memory management in Go, you have to
    manually allocate and manage []byte slices. This gets tedious, and you end
    up losing most of the benefits of static typing as well.

    Finally, Rust is developed by Mozilla with the explicit goal of using it
    to develop a cross-platform web browser. What does a moder web browser
    needs? A performant graphics, sound and ui libraries. Those kinds of
    libraries will be the first ones to be written by Mozilla itself and they
    already have plenty of developers that are experts in those domains.
    They're interested in that too, in that it'd obviously be good if
    components of Firefox could be written in Rust someday. But today, to
    create its browser engine, Servo, they are using bindings to C libraries.

    On Mon, Dec 31, 2012 at 11:11 AM, Archos <raul...@sent.com <javascript:>>wrote:

    --
  • Bryanturley at Jan 1, 2013 at 5:27 pm

    On Tuesday, January 1, 2013 5:05:47 AM UTC-6, Archos wrote:

    El martes, 1 de enero de 2013 09:09:32 UTC, Krzysztof Kowalczyk escribió:
    By all means go for it.

    However, from the point of view of Go developer who needs such
    functionality, there are plenty of such libraries in C that can already be
    used from Go and some of them have Go wrappers today:
    http://go-lang.cat-v.org/library-bindings
    It is just that most of these things are tied to specific pieces of
    hardware. OpenGL for instance can be done completely in software but there
    are pieces of hardware that perform those functions faster than the main
    cpu.
    And if you try to define an api different from an industry standard you are
    going to have a very hard fight.
    And as I said earlier the rust guys want WebGL since they are making a web
    browser, and not stacking that on top of normal OpenGL would be crazy since
    they are so related.
    I think before the lowest level libraries can change we need to inspire the
    hardware developers to move away from c, and that is going to take some
    doing since C is still the language for doing low level things.
    Not to mention these low level drivers have to interact with OS kernels
    written in C.

    >

    --
  • Archos at Jan 1, 2013 at 7:59 pm
    There is not serious competition in the graphics world so there is space for
    another player.

    DirectX is a propietary library specific to Windows so I'm not going to
    wrapping
    around it because I would be sold to a library of closed code where
    Microsoft
    could remove some APIs in new versions of Windows, like it has already
    happened.

    OpenGL is commercially unviable to use it on Windows, due to the fact that
    OpenGL just doesn't works on most machines by default.

    Then, the great failure of building libraries over open specifications is
    that
    every company finishes developing what they want; you only have to see how
    has
    been implemented HTML and CSS in the different browsers. This would be
    solved
    whether they there would be worked in the same C libraries. Cooperation vs
    Isolation.

    In addition, there are some issues with the Khronos Group:

    + API developers are not game developers. The API developers of an open
    standard
    need to be communicating with the community instead of make it with hardware
    vendors.

    + There was a total stop of communication on all levels regarding all
    topics, it
    was impossible to reach members of the group.

    So I'm not going to repeat the same error. When you have a library fully
    developed and documented that works in the main platforms then the
    developers
    will be happy.


    El martes, 1 de enero de 2013 17:26:57 UTC, bryanturley escribió:

    On Tuesday, January 1, 2013 5:05:47 AM UTC-6, Archos wrote:


    El martes, 1 de enero de 2013 09:09:32 UTC, Krzysztof Kowalczyk escribió:
    By all means go for it.

    However, from the point of view of Go developer who needs such
    functionality, there are plenty of such libraries in C that can already be
    used from Go and some of them have Go wrappers today:
    http://go-lang.cat-v.org/library-bindings
    It is just that most of these things are tied to specific pieces of
    hardware. OpenGL for instance can be done completely in software but there
    are pieces of hardware that perform those functions faster than the main
    cpu.
    And if you try to define an api different from an industry standard you
    are going to have a very hard fight.
    And as I said earlier the rust guys want WebGL since they are making a web
    browser, and not stacking that on top of normal OpenGL would be crazy since
    they are so related.
    I think before the lowest level libraries can change we need to inspire
    the hardware developers to move away from c, and that is going to take some
    doing since C is still the language for doing low level things.
    Not to mention these low level drivers have to interact with OS kernels
    written in C.
    --
  • Patrick Mylund Nielsen at Jan 1, 2013 at 8:03 pm
    As far as I can tell, this is not related to Go at all. Please keep it
    on-topic.

    On Tue, Jan 1, 2013 at 2:59 PM, Archos wrote:

    There is not serious competition in the graphics world so there is space
    for
    another player.

    DirectX is a propietary library specific to Windows so I'm not going to
    wrapping
    around it because I would be sold to a library of closed code where
    Microsoft
    could remove some APIs in new versions of Windows, like it has already
    happened.

    OpenGL is commercially unviable to use it on Windows, due to the fact that
    OpenGL just doesn't works on most machines by default.

    Then, the great failure of building libraries over open specifications is
    that
    every company finishes developing what they want; you only have to see how
    has
    been implemented HTML and CSS in the different browsers. This would be
    solved
    whether they there would be worked in the same C libraries. Cooperation vs
    Isolation.

    In addition, there are some issues with the Khronos Group:

    + API developers are not game developers. The API developers of an open
    standard
    need to be communicating with the community instead of make it with
    hardware
    vendors.

    + There was a total stop of communication on all levels regarding all
    topics, it
    was impossible to reach members of the group.

    So I'm not going to repeat the same error. When you have a library fully
    developed and documented that works in the main platforms then the
    developers
    will be happy.


    El martes, 1 de enero de 2013 17:26:57 UTC, bryanturley escribió:
    On Tuesday, January 1, 2013 5:05:47 AM UTC-6, Archos wrote:


    El martes, 1 de enero de 2013 09:09:32 UTC, Krzysztof Kowalczyk escribió:
    By all means go for it.

    However, from the point of view of Go developer who needs such
    functionality, there are plenty of such libraries in C that can already be
    used from Go and some of them have Go wrappers today:
    http://go-lang.cat-v.**org/library-bindings<http://go-lang.cat-v.org/library-bindings>
    It is just that most of these things are tied to specific pieces of
    hardware. OpenGL for instance can be done completely in software but there
    are pieces of hardware that perform those functions faster than the main
    cpu.
    And if you try to define an api different from an industry standard you
    are going to have a very hard fight.
    And as I said earlier the rust guys want WebGL since they are making a
    web browser, and not stacking that on top of normal OpenGL would be crazy
    since they are so related.
    I think before the lowest level libraries can change we need to inspire
    the hardware developers to move away from c, and that is going to take some
    doing since C is still the language for doing low level things.
    Not to mention these low level drivers have to interact with OS kernels
    written in C.
    --
    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedDec 31, '12 at 7:11p
activeJan 1, '13 at 8:03p
posts9
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase