5 ms·

Looking back over the D forums, D implementers have been promising to support shared libraries since at least 2006, and as far as I can tell, none of the major

by jnbiche 13y ago

Looking back over the D forums, D implementers have been promising to support shared libraries since at least 2006, and as far as I can tell, none of the major D compilers support it yet. D is a very nice language, but without shared libary support in Linux or Windows, its use to me as a low-level alternative to Python or Lua is limited. Go clearly is interested in static-only compilation, and they've said as much. Rust is still too alpha to use for serious projects, and to be frank I find it carries much of the complexity that turns me off from C++ (I really wanted to like Rust). Meanwhile, I've found Nimrod can happily handle shared library support, meaning I can easily make nice extensions for Python and Lua. Nimrod is just as fast as D, and probably a bit faster than Go and Rust. Syntax is very nice for Pythonistas, and it has a very full standard library. I've also noticed that Nimrod is getting some very good exposure here on HN, and people smarter than I am are starting to play around with it (in addition to the people smarter than I am who invented it and brought it to this level). In the end, the only new low-level language without big company support may turn out to be the winner here.

simendsjo 13y ago
Shared libraries work on gnu/linux (since 2.063..?), they just haven't been announced (the devs want some "beta" testing first I seem to remember). EDIT: Ok, since 2.064
WalterBright 13y ago
Shared libraries are now supported on Linux as of 2.064. Other platforms to follow.
- jnbiche 13y ago
  That's great to hear, congratulations on getting that done. I think a lot of us in communities like Python and Ruby are really interested in an alternative to C/++ for writing extensions.
  - pjmlp 13y ago
    Have a look at PyD and CeleriD. http://pyd.dsource.org/ http://pyd.dsource.org/
- deleted 13y ago
  [deleted]
krakensden 13y ago
Go supports shared C libraries- people have linked it against things like SDL and GTK+. I'm not so sure it's really necessary for new things. Disk and memory are now cheap and plentiful enough that most of the advantages of shared libraries don't outweigh the advantages of static ones.
- _pmf_ 13y ago
  One advantage of shared libraries is that applications that link against them benefit from bugfixes when the system updater updates the library. (Well, it might also cause regressions, obviously.)
  - gngeal 13y ago
    ...which is of zero importance to the primary users of Go, i.e., Google, as they have a unified code base. But nobody prevents the Gccgo people from implementing their implementation differently. (It's just that for Google, this is really not a pressing issue.)
    - pjmlp 13y ago
      > ...which is of zero importance to the primary users of Go, i.e., Google, as they have a unified code base. And this is why Android will never get official Go support. - Android only uses dynamic loading - The Android team does not seem to care about Go - The Go team is religiously against dynamic loading So I bet D and Rust compilers will be able to support Android, before Google will support Go in the Android SDK.
      - kibwen 13y ago
        Rust already supports Android, thanks to the efforts of Samsung.
        pjmlp 13y ago
        Thanks for the heads up, I thought it was still not fully there from the mailing list traffic. Do you have any pointers about it?
dbaupp 13y ago
> Nimrod is just as fast as D, and probably a bit faster than Go and Rust Note that Rust is/can be as fast as D/C/C++.
pcwalton 13y ago
> Rust is still too alpha to use for serious projects, and to be frank I find it carries much of the complexity that turns me off from C++ (I really wanted to like Rust). Could you elaborate? I personally think that Rust carries no complexity that we didn't need to get the job done, and we're still simplifying the language (for example, removing conditions and glob imports), but I'm certainly open to hearing other ways that the language could be simplified. > Nimrod is just as fast as D, and probably a bit faster than Go and Rust. I think that for numerics all four languages will be roughly on par (although Go will be a bit slower if you're using 6g/8g, as they don't do much optimization), but for memory management the performance characteristics are quite different. Rust doesn't rely on garbage collection or reference counting for safe memory management, unlike all the others (although you can opt out in D, at the cost of safety). So I don't think you can really make an unqualified statement like that in all cases.
- jnbiche 13y ago
  >Could you elaborate? A major source of complexity, in my opinion, are the different pointers: owned pointers, managed pointers, borrowed pointers (mutable and immutable), each with its own syntax and rules for use. And all three seem to be everywhere. I actually understand pointers in C (mostly!), yet I struggle to remember all the use cases for pointers in Rust. Here's the tutorial on just borrowed pointers: http://static.rust-lang.org/doc/master/tutorial-borrowed-ptr.html http://static.rust-lang.org/doc/master/tutorial-borrowed-ptr... I'm sure I could understand learn the rules given some time, but now that I've played around with D and Nimrod, I'm wondering why I should. I can get excellent performance without using pointers, yet I can access a pointer if I absolutely need one. >So I don't think you can really make an unqualified statement like that. I agree that unqualified statements about the relative performances of language implementations are tenuous, and so I retract that statement. But it's clear that Nimrod can reach ballpark C++/Rust/Go speeds, even without GC specifically turned off, based on both my own usage and this benchmark: 1. http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/ http://togototo.wordpress.com/2013/08/23/benchmarks-round-tw... Now, it's quite possible that we're not getting optimal performance out of Rust because we're not writing idiomatic Rust, but this hurdle is at least partly a function of my first point. EDIT: I should add that I think Rust may well find itself in a very strong position among systems and embedded programmers, given the fine control and safety it offers. But for your average programmer just looking for a faster language to use when Python or Ruby won't suffice, Nimrod (and D with shared library support) is a very nice alternative.

by jnbiche 13y ago

simendsjo 13y ago

Shared libraries work on gnu/linux (since 2.063..?), they just haven't been announced (the devs want some "beta" testing first I seem to remember). EDIT: Ok, since 2.064

WalterBright 13y ago

Shared libraries are now supported on Linux as of 2.064. Other platforms to follow.

jnbiche 13y ago
That's great to hear, congratulations on getting that done. I think a lot of us in communities like Python and Ruby are really interested in an alternative to C/++ for writing extensions.
- pjmlp 13y ago
  Have a look at PyD and CeleriD. http://pyd.dsource.org/ http://pyd.dsource.org/
deleted 13y ago
[deleted]

krakensden 13y ago

Go supports shared C libraries- people have linked it against things like SDL and GTK+. I'm not so sure it's really necessary for new things. Disk and memory are now cheap and plentiful enough that most of the advantages of shared libraries don't outweigh the advantages of static ones.

_pmf_ 13y ago
One advantage of shared libraries is that applications that link against them benefit from bugfixes when the system updater updates the library. (Well, it might also cause regressions, obviously.)
- gngeal 13y ago
  ...which is of zero importance to the primary users of Go, i.e., Google, as they have a unified code base. But nobody prevents the Gccgo people from implementing their implementation differently. (It's just that for Google, this is really not a pressing issue.)
  - pjmlp 13y ago
    > ...which is of zero importance to the primary users of Go, i.e., Google, as they have a unified code base. And this is why Android will never get official Go support. - Android only uses dynamic loading - The Android team does not seem to care about Go - The Go team is religiously against dynamic loading So I bet D and Rust compilers will be able to support Android, before Google will support Go in the Android SDK.
    - kibwen 13y ago
      Rust already supports Android, thanks to the efforts of Samsung.
      - pjmlp 13y ago
        Thanks for the heads up, I thought it was still not fully there from the mailing list traffic. Do you have any pointers about it?

dbaupp 13y ago

> Nimrod is just as fast as D, and probably a bit faster than Go and Rust Note that Rust is/can be as fast as D/C/C++.

pcwalton 13y ago

> Rust is still too alpha to use for serious projects, and to be frank I find it carries much of the complexity that turns me off from C++ (I really wanted to like Rust). Could you elaborate? I personally think that Rust carries no complexity that we didn't need to get the job done, and we're still simplifying the language (for example, removing conditions and glob imports), but I'm certainly open to hearing other ways that the language could be simplified. > Nimrod is just as fast as D, and probably a bit faster than Go and Rust. I think that for numerics all four languages will be roughly on par (although Go will be a bit slower if you're using 6g/8g, as they don't do much optimization), but for memory management the performance characteristics are quite different. Rust doesn't rely on garbage collection or reference counting for safe memory management, unlike all the others (although you can opt out in D, at the cost of safety). So I don't think you can really make an unqualified statement like that in all cases.

jnbiche 13y ago
>Could you elaborate? A major source of complexity, in my opinion, are the different pointers: owned pointers, managed pointers, borrowed pointers (mutable and immutable), each with its own syntax and rules for use. And all three seem to be everywhere. I actually understand pointers in C (mostly!), yet I struggle to remember all the use cases for pointers in Rust. Here's the tutorial on just borrowed pointers: http://static.rust-lang.org/doc/master/tutorial-borrowed-ptr.html http://static.rust-lang.org/doc/master/tutorial-borrowed-ptr... I'm sure I could understand learn the rules given some time, but now that I've played around with D and Nimrod, I'm wondering why I should. I can get excellent performance without using pointers, yet I can access a pointer if I absolutely need one. >So I don't think you can really make an unqualified statement like that. I agree that unqualified statements about the relative performances of language implementations are tenuous, and so I retract that statement. But it's clear that Nimrod can reach ballpark C++/Rust/Go speeds, even without GC specifically turned off, based on both my own usage and this benchmark: 1. http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/ http://togototo.wordpress.com/2013/08/23/benchmarks-round-tw... Now, it's quite possible that we're not getting optimal performance out of Rust because we're not writing idiomatic Rust, but this hurdle is at least partly a function of my first point. EDIT: I should add that I think Rust may well find itself in a very strong position among systems and embedded programmers, given the fine control and safety it offers. But for your average programmer just looking for a faster language to use when Python or Ruby won't suffice, Nimrod (and D with shared library support) is a very nice alternative.