7 ms·

Honestly, I never knew the size of the divide (or that it existed) between the enterprise development community and the open source development community. I've

Honestly, I never knew the size of the divide (or that it existed) between the enterprise development community and the open source development community. I've only now started to notice it as I pay attention to Rust's build systems get designed, and other details around the Rust community evolve. I find it fascinating that lessons aren't being learned from build systems which are built in the enterprise like Bazel, Pants, etc (honestly, I'm disappointed one of those two wasn't just adopted by the Rust community - unclear but I think they didn't know about them?). Similarly, notice how "Java shops" have for many years enforced ever increasingly complex build pipelines (Javadoc, Junit, JaCoCo, Findbugs, ...). But these tools are slow, end up with long standing bugs when versions bump, and generally end up limited. I find it fascinating however, that only two of the above steps (Docs, Tests) are first class in Rust. Why only those two? Why not learn from the whole Java build pipeline? Why does the compiler's test infra not spit out metadata about lines/branches covered? Why is clippy, like Findbugs, separate from the compiler? Isn't "better code" by definition better for everyone. It should be relatively easy for these to be built into the compiler. While some like test coverage data is really hard to get as separate tool (especially when optimizations are on). However, Rust developers have valid points like "separation of concerns". Its hard to argue with them, after all we are only on the sidelines, they are actually in the thick of it. But again, there just seems to be a divide, and its interesting to see which features/lessons are adopted, vs which features/lessons are "not worth the trouble". FWIW (my stab at a reason for this divide), I think its largely a problem of peers. In the enterprise, you work with great developers and you work with not so great developers. Most of these are fresh college/code-bootcamp developers but there are some rare bad experienced developers. At least in the field of building languages (maybe open source in general) you get to be very selective. Essentially, you only get peers who are experts (even if some of them do start off making changes while in college or without any formal education - also keep in mind the selection bias of people curious and motivated to help a project they aren't being paid for). Compounded with few strict deadlines, this basically means everyone is on their A-game all the time. eg. "Why would you need metrics about how many lines+branches of code are tested? and you want to potentially fail the build if it doesn't meet some threshold?? Some things are hard to test! Shouldn't the implementor get to decide how much testing is the appropriate amount of testing?" P.S. Please, anyone, correct me where I'm wrong. I too am on only one side of this divide.

__s 10y ago
I'm on both sides, & I wish on the enterprise side we had what Python has (bugs.python.org & rietveld & good DVCS). But my enterprise experience is at a place with a dozen people & we use very few tools. It's a C# shop mostly
dathinab 10y ago
I think the answer for many of your questions is "available resources", Mozilla has only limited resources for rust and while rust has a very nice community driving rust, it is a big difference to e.g. google which probably has more paid developers on the Bazel build system than Mozilla on the whole programming language... So instead of choosing a large feature set at the beginning and the box it through, they choose to have a more thin compiler, standard library etc. but make it extendable, so that it can be extended and integrate with other systems. Also you should not forget that Rust is still very young for a programming language so cargo is everything but done. Cargo is more a unified interface combining the compiler and the crates package repository than a full fledged build system. Given the available resources and time for building rust, I thing choosing to (for now) not include a fist class rust coverage system, debugger etc. is a sane choice, especially because all this things are available as external tools (debugger=gdb, coverage=kcov, etc.). Also there are discussions/issues about enabling the integration with "enterprise" build systems, they just currently don't have a high priority and happen mostly in the background. So it's probably just a matter of time until you can use rust with a "enterprise" build system like Bazel. Wrt. clippy integration in rust, it is mostly about keeping the compiler smaller and easier to maintain. Through it should be noted, that all "important" lints are in rustc, clippy just provides more useful ones. By keeping both projects separated it is possible to iterate both of them independent of the other. Which can be quite useful in open source development. Also don't enterprise systems also have a separate linter? (And no "better code" is not better code for every one, as the definition for what good code is can change quite a bit depending on the person, e.g. wrt. variable shadowing) Lastly I don't think your reasoning about peers holds, you don't really have the choice to be selective about people working on the project, at last not if you have open source project on the scale of rust. Through you might be able to have more strict requirements for code quality. Nevertheless given how rustc catches a lot of possible bugs, and how to community is, I would be surprised if there would not be some less experienced programmers contributing to the compiler. But then at last Mozilla also uses rust in production, so some parts have deadlines and even if not it's quite different for them then a `A-game`classification. Also it's not so, that you can't have metrics about lines/branch coverage, failed the build on certain thresholds, etc. It's just not necessary a build-in feature, through available nevertheless. Also it would be really strange if a programming language / build tool would decide which amount of coverage is ok, it's something the project manager/programmer has to decide (once) and then configure the build tool to enforce it (I most likely did misunderstood you on the last line ;-) ). Ups, I wrote much to much. TL;TR: 1) rust has less (programmer) resources 2) it's still young, tools like cargo, or the testing API are everything but complete. Through they do there job good enough for now.

__s 10y ago

I'm on both sides, & I wish on the enterprise side we had what Python has (bugs.python.org & rietveld & good DVCS). But my enterprise experience is at a place with a dozen people & we use very few tools. It's a C# shop mostly

dathinab 10y ago

I think the answer for many of your questions is "available resources", Mozilla has only limited resources for rust and while rust has a very nice community driving rust, it is a big difference to e.g. google which probably has more paid developers on the Bazel build system than Mozilla on the whole programming language... So instead of choosing a large feature set at the beginning and the box it through, they choose to have a more thin compiler, standard library etc. but make it extendable, so that it can be extended and integrate with other systems. Also you should not forget that Rust is still very young for a programming language so cargo is everything but done. Cargo is more a unified interface combining the compiler and the crates package repository than a full fledged build system. Given the available resources and time for building rust, I thing choosing to (for now) not include a fist class rust coverage system, debugger etc. is a sane choice, especially because all this things are available as external tools (debugger=gdb, coverage=kcov, etc.). Also there are discussions/issues about enabling the integration with "enterprise" build systems, they just currently don't have a high priority and happen mostly in the background. So it's probably just a matter of time until you can use rust with a "enterprise" build system like Bazel. Wrt. clippy integration in rust, it is mostly about keeping the compiler smaller and easier to maintain. Through it should be noted, that all "important" lints are in rustc, clippy just provides more useful ones. By keeping both projects separated it is possible to iterate both of them independent of the other. Which can be quite useful in open source development. Also don't enterprise systems also have a separate linter? (And no "better code" is not better code for every one, as the definition for what good code is can change quite a bit depending on the person, e.g. wrt. variable shadowing) Lastly I don't think your reasoning about peers holds, you don't really have the choice to be selective about people working on the project, at last not if you have open source project on the scale of rust. Through you might be able to have more strict requirements for code quality. Nevertheless given how rustc catches a lot of possible bugs, and how to community is, I would be surprised if there would not be some less experienced programmers contributing to the compiler. But then at last Mozilla also uses rust in production, so some parts have deadlines and even if not it's quite different for them then a `A-game`classification. Also it's not so, that you can't have metrics about lines/branch coverage, failed the build on certain thresholds, etc. It's just not necessary a build-in feature, through available nevertheless. Also it would be really strange if a programming language / build tool would decide which amount of coverage is ok, it's something the project manager/programmer has to decide (once) and then configure the build tool to enforce it (I most likely did misunderstood you on the last line ;-) ). Ups, I wrote much to much. TL;TR: 1) rust has less (programmer) resources 2) it's still young, tools like cargo, or the testing API are everything but complete. Through they do there job good enough for now.