Hacker News Reader

Comment by danpalmer | Hacker News Reader

While these are nice tips, I'm not sure that I learnt much about organising large Rust codebases. I'm not very familiar with Rust, but the tip of not putting things in mod/lib seems similar to not putting code (other than visibility/aggregation) in `__init__.py` – something I'd advocate for on any Python codebase of any size. The directory structure tips seem ok.

As for versioning dependencies together at the top level, again I'm unfamiliar with Rust, but this tip seems too specific. I've seen large codebases where having different dependency versions was fairly important or even a core use-case. It's nice if it's possible, but the bigger the codebase the more this will necessarily come into question.

I'd love to see more detail about things like the design of internal APIs that works well for large Rust codebases, approaches to ownership that help scale the codebase, approaches to testing that work or don't work in Rust specifically.

View on HN

Not clear why Docker and "make" should be involved, except that he likes them. Cargo and git can do the job. A build usually produces a single executable, so "packaging" isn't that much of an issue.

There's much that could be said on this subject. How much should be made visible via "mod.rs" and "lib.rs" files? How much lock granularity is appropriate? Should projects be composed of loosely coupled crates? How much should be global? Anything? How do you deal with the problem that if A owns B, B can't reference A? How do you deal with breaking changes to low-level public crates?

The article doesn't say much about any of that. A good article on this subject would be helpful.

I thought it explained Docker and Make pretty well, but to reiterate:

You can use a Dockerfile to provide a Dev container. If you aren't familiar with those it basically lets IDEs open your project inside a Docker image without you having to faff around with Docker. This can give you a reproducible dev environment and make getting dependencies easier for new devs.

You don't need it if your only dependency is Rust, but that may not be the case for larger projects. E.g. I have one that needs OCaml, and that is an absolute nightmare to install (worse than Python!) so I made a Dev container that had it preinstalled.

He suggests Make so that you have common commands written down in a place where people actually run them (i.e. not a README where they are likely to rot). This helps new contributors discover how to do common tasks. This isn't using Make as a build system, just as a command runner. You could equally use Just or even shell scripts if you really hate Windows users... and yourself.

Hope that helps!

If you need containers to build, then you need containers to deploy. While containers are good for getting devs started with development, they should not be the only dev/testing environment.

> If you need containers to build, then you need containers to deploy

That's not true. I've seen plenty of projects that set up a complex build pipeline made up of scripting languages and wrappers that are a pain to install, but the final product doesn't need any of that to run.

For instance, NodeJS web projects can require all manner of transpilers, minimisers, and what have you, but the end result is often a few large text files that will run in any browser if just served as static files.

If you use containers to build, you may as well use containers to deploy, but you don't need to deploy using containers at all. Just copy the compiled end product out of your dev container.

Nobody is suggesting that.

A few years ago I bought the book written by the same author. A few chapters in, and I now filter out anything written by Kerkour.

This time I missed who the author is and started reading. A few paragraphs in, and I’m scrolling to the bottom to see, who the author is — yep, they did it again.

I have a suspicion, the author might be a recent graduate with only Rust in their belt and not much experience in the industry, trying to quickly climb the career ladder pretending they are something else.

Did what again? This seems like solid advice to me. What specifically do you disagree with?

Well, the advice to not use lib and mod is a sound one. I realized that too. Workspaces – definitely, although, that's borderline useful, because it's hard for me to imagine someone growing their Rust codebase without knowing about this feature. Other tips continue the downward trend.

It's hard to disagree with these tips, because they argue for general good (although devcontainer is a controversial one, imo). But anyone with minimal hands-on experience likely already knows all of that.

Honestly, reading this article the second time I think my initial comment might've been too harsh. Maybe I've been salty after remembering that book by the author I didn't like But I still stand by my words, that the article turned out somewhat superficial and not insightful.

> As for versioning dependencies together at the top level, again I'm unfamiliar with Rust, but this tip seems too specific. I've seen large codebases where having different dependency versions was fairly important or even a core use-case. It's nice if it's possible, but the bigger the codebase the more this will necessarily come into question.

What you can do in your toml files is, in the top level you give the "workspace version" of every dependency, and then in the projects you tell them to use either workspace version or some other specific version. That way, most of your projects will use the same, while you can change the few that need a specific one.

The suggestions are purely about file paths, and don't affect the code. It's like advising "symlink __init__.py as __myproject_init__.py". The author opens files via search, doesn't want to have multiple files with the same name.

Declaring dependencies in the workspace ensures that the same version is used by every library you're writing. Versions are generally deduplicated anyway, but workspace makes it easier to bump versions and configure defaults in one place.

kerkour is basically a spam blog.

Reply on news.ycombinator.com