Hacker News Reader

The examples you gave (DB, JSON, etc) are big enough that there would be decent support for those in Rust. But, your concern is definitely valid for more niche requirements. If your primary concern is availability, stability, maturity etc of a language's ecosystem, then IMHO, you should not choose a language as new as Rust. Rust is currently in the "early adopter" phase, and it is going to go through the same issues (and excitement) that most early adopters do in any field.

I hope this was downvoted by mistake, because it's true that Rust is still in early-adopter territory. It's only been stable for three months! :P

Sadly I have seen people get downvoted just because tell the truth . This is really sad for me because we are in HN , we should not have see this kind of bias in place like HN.

p.s. I love rust.

p.s.2 . It is completely logical and most of agree rust is in early adopt stage.

    Although I find Rust very appealing I still see C++ as the better option, mostly 
    because I fear that Rust would lack good suppport libraries (e.g. for talking to 
    DBs, generating/parsing data formats such as JSON or for generating cryprographic 
    hashes) and that I would end up implementing many of those myself. As of today, 
    many Rust wrapper libraries (e.g. for BerkeleyDB) seem to be written by a single 
    author, which makes me wonder about their stability and maturity even more.

Rust is in its very beginning[1]. Only time can tell if it will have a rich set of support libraries that are stable and mature.It has one big advantage over C and C++ in this regard.

It has a central repository for all the support libraries.

I always found it difficult to assess the stability and maturity of libraries for C or C++ found on the internet. Of course there are the standards, like libpng or zlib, and you know they must be good because so many projects use them. For more exotic tasks you are on your own. With a central repository, you can at least estimate the popularity of a certain library. crates.io shows a download count for example. Also many other popular languages have one

   Java     Maven
   Perl     CPAN
   TeX      CTAN
   PHP      PECL, PEAR
   Python   PyPI 
   Ruby     RubyGems 
   R        CRAN 
   Node.js  npm 
   Lua      LuaRocks 
   Haskell  Hackage

[1] I know that Graydon started it over 5 years ago, but from user standpoint Rust is more a child of 2015.

[2] https://crates.io/

Package managers have their own problems. Unless they are curated well they lead to many libraries that all claim to do the same thing. I wont name any specific examples, but using some of the above takes a fair amount of judgement in how rock solid the package is.

I, for my part, think I'm still better off with a central repository with problems than without one.

For Java there are commercial curated Maven repositories and I'm not aware of anything like that for C/C++. So Cargo can be an enabler for Rust in big corp.

The closest thing for C and C++ is probably Debian's apt repositories and the like from other distros. Just search for any package starting with lib-, then look for the ones with the most results in apt-cache rdepends.

I think a better design would be a p2p system with crates.io being a tracker and official seeder.

It's a nice approach in theory. Not so great in practice.

Whether we like it or not most developers are hired by a company. And for most medium to large companies there is no way they are going to let a P2P system go through their firewall.

Many don't even allow developers to access official repositories which is why products like Nexus (repository proxy) exist.

The standard clients don't need to seed by default. Provided there are organizations willing to seed, they could share the costs between themselves.

That is a problem with or without package managers. Maybe package managers should start doing PageRank style sorting and return results in the order of how popular they are?

Just for the sake of nitpicking:

For PHP PEAR is dead. Packagist is the de facto central repository for packages.

One advantage of Rust is its excellent C FFI. So as long as your dependencies have a C interface, you should be fine.

The library support already seems quite excellent; the Cargo ecosystem seems to have most of what I want covered. And for anything that isn't covered, Rust has an exceptionally good FFI layer, so you can just call any available C library directly.

It's not by any means a conservative, "safe" choice (in the business sense); you'd be choosing an early-stage language, with everything that implies. But I think it's a reasonable choice for a new project starting today. And the community around it is incredible.

There are certainly library deficiencies, but we do have good Postgres bindings, and multiple JSON generating/parsing crates.

Young ecosystems: lots of opportunity, but 'opportunity' also means pain for those on the other side of the chasm...

I can't answer personally, but these might help:

https://doc.rust-lang.org/book/ffi.html

https://www.reddit.com/r/rust/comments/3axeu8/whats_the_stor...

I guess the answer is that it depends on what libraries you'll need.

Experiment and report back! It's entirely possible that the single-author libs are already stable, and simply don't require the work of more contributors because the language makes it easy to get things right & robust the first time. (I don't have experience with Rust, so I'm not saying this is so - just that it's possible).

We encountered this issue because we use MongoDB as our primary database and there was no driver available. I wrote a really nice (if I say so myself) wrapper [1] around the C driver, which really wasn't that much work. I think in general anything you can think of can be used by integrating with a C library.

[1] https://github.com/thijsc/mongo-rust-driver

Mongo has been paying a few interns to write a driver, actually. They presented at the last NYC meetup, and I've been doing code review.

Whenever a new language popup, I always wonder 1) who us it 2) why they use it 3) what they use it for

Hopefully more people share their stacks on http://www.stackbus.com/ (FYI, I build it) so that it help others to decide better.

> Although I find Rust very appealing I still see C++ as the better option, mostly because I fear that Rust would lack good suppport libraries

You don't need everything be pure Rust. Just use C libraries to fill in the gaps.

What do you mean by "speed", and what is your primary working language?