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

Something like four years ago I wrote a command-line tool in Rust to interact with a service I wrote (not in Rust). Then I left that company for a new job.

At a recent happy hour, I learned that despite nobody there having much of a clue about Rust, they were able to clone the repo, build it, and run it based on a short wiki page I left behind. I thought that was really cool, and a great validation of the care the Rust project takes around dependency management and backwards compatibility.




One of the more attractive things about Rust for me is that I can easily write portable code. I distribute Windows binaries for a certain Rust project and they've kept working despite the fact I haven't tested on Windows in years.

I'm not sure I would even know how to build any of my C/C++ projects on Windows.


The most important layer in dependency management, I've found, is always in the systems code and what resources it consumes. If you get a handle on that, the rest is addressed with a well-targeted interface to the systems code, which the application uses uniformly. This interface can even take the form of a transpiled language.

And to the degree that Rust is effective, it lets a greater portion of the systems code be managed by a common interface. It remains as painful as most when it comes to binding external C code.

(I do think Zig is really promising in this regard by aiming to absorb C more comprehensively.)


> they've kept working despite the fact I haven't tested on Windows in years.

How do you know? :)

Cross-compilation, avoiding the need to build on many different systems, is great - but I’d still want to test on all those systems.


As a Windows user, I see the other side of this, and it is usually true. It is easy to run in CI, maybe that’s part of it.

I’m not sure exactly how it’s the case, but I’ve been thinking about it a lot lately; I had a convo on HN last week about this...


It’s not hard to cross compile for windows with mingw. As long as you’re not using something like gtk.


It's not just building, it's also stuff like path handling (think of the wrapper everyone writes around _wfopen), argv expansion, etc.

Also the face that I could compile it on Linux doesn't help me document how people on Windows are supposed to compile it.


I find it interesting, regardless of language, that this was seen as out of the ordinary for your company in this day and age. Tells me a lot.


Oh yeah? What knowledge have you walked away from my context-free anecdote newly in possession of?


That it's out of the ordinary for someone to be able to just pick up a repo/service/project at your company and just go with maybe only a few sentences in a wiki to bootstrap them.

I'm a big fan of git clone, make setup, make style workflow where there is no other work. That this was a wow factor for your coworkers, again, tells me a lot.


Well, this actually seems to be pretty common at smaller companies (that they don't prioritize portability and out-of-the-box usability for internal tools and services), and this wasn't even nominally a software company. I did a lot of work there to try and improve these problems, mostly having nothing to do with Rust, but it was a thankless job.

My observation working at (much) larger, software-oriented companies is that things are better mostly because they have a lot of people working on tools like build systems and commit-blocking linters. Individual engineers on large teams, when incentivized toward pure velocity, still seem to ignore code quality and stewardship to the greatest degree they can get away with.

edit: These are meant as generalizations. Obviously some of us care, despite the industry's best attempts to beat it out of us.


You know cmake exists because "make && make install" by isn't usually that easy, anything beyond a small CLI has a lot of dependencies, and breaks with minor version changes?


I do know that. I don't know why you have to configure anything. For configurable project we make projects that contain the specific configs and wrap the common cmake. For instance "windows phone" wrapping the base app.

This also makes me ponder how you can do CI (builds) if you have to manually configure things. Or do you bake all that into the build config


That's funny, I also have a Rust CLI I left behind at my previous company which interacts with a service not in Rust. I just checked and it seems like it's still going.


Sounds like both of us found the same excuse to write some Rust at work. ;)


I started a new project in Go this year and I have the same hope for the future. So far Go has been pretty good in that regard.


This article does not inspire confidence in the matter (in particular the part covering the breaking change introduced in time while one could not decide on package version) but one would expect things to improve with time: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...


Why do you have that hope? Did you copy your dependencies (I assume you have) in a vendor directory you include In your project? If not, what happens if someone decides to remove the code of your dependency from e.g. GitHub?


It should still be on GOPROXY, but yeah, if (very) long-term usability is important and the project isn't being maintained then vendoring is better.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: