Hacker News new | comments | show | ask | jobs | submit login

A big non-safety selling point of Rust for me is a systems language with the tooling and ecosystem of a modern dynamic language. Dependency management and composition is a necessary part of complex programs, but a tedious, painful timesink in almost all systems languages. While CMake and similar tools improved the situation for C++, it's still an enormous pain and a barrier to sharing and reusing code. You are often forced to re-invent the wheel -- complete with your own bugs and maintenance obligation -- simply because getting a dependency to be built and detected cross-platform may be an even larger cost.

Cargo is a wonder. It's more limited in scope than something like CMake, but for the vast majority of use cases that are just pulling in a library or binding from the same language, it's spectacular.

Related to this, having an opinionated lint built into the tooling creates a common, readable dialect for the ecosystem. This is especially important for verbose syntax languages like Rust or C++. There are C++ libraries I can't understand simply because special snowflake formatting combined with complex template syntax renders it illegible.




> A big non-safety selling point of Rust for me is a systems language with the tooling and ecosystem of a modern dynamic language.

I've reached this point from the opposite direction, as a frustrated Rubyist: I really crave the nice things that come from having a statically typed, compiled "systems" language, but I'm not prepared to lose the kind of tooling and ecosystem that I currently have with Ruby to get them.


Last time I checked cargo was still not handling external dependencies and the packages were simply wrapping system-wide dependencies, that you have to manage yourself. Same problem as with all CPAN-derived package managers.


This only applies if you are using system libraries. Most libraries do not rely on external dependencies. Regardless, cargo is build tool for Rust, not a replacement for your distribution's package manager. If you want to build a library that's fully static then use the musl target and build your external dependencies with musl. If you want distribution integration then use a makefile or other tool.


It is intentionally not handling external dependencies. That's not what it's for. Many libraries and wrappers will compile the library if missing on the system (eg: rust-curl as a practical example will compile curl and statically link it if needed).


CPAN did it exactly like that, many packages also bundled C libraries, etc. It's a very fragile mess and a mistake package managers refused to learn from CPAN. It is especially pronounced once you have a CI/CD system, forces you to pretty much abandon such package managers and only use them to explore/discover new packages.


>forces you to pretty much abandon such package managers and only use them to explore/discover new packages

Given the unbelievable popularity of Rubygems.org, PyPI, and NPM, I think this is an unfounded assertion. Furthermore, Rust programmers aren't afraid to rewrite libs in Rust when a widespread external dependency becomes annoying, e.g. with FreeType: https://www.reddit.com/r/rust/comments/44btaz/introducing_ru...


It's up to the implementer of the wrapper; some will compile a version if they can't find one on the system, for example.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: