Stream: t-lang

Topic: Rust at a larger scale.

Charles Lew (Apr 21 2020 at 04:36, on Zulip):

This is just me thinking aloud. Most crates are currently carefully manually designed by the author, with carefully designed ownership and borrowing correspondence for values, types, and function boundaries, which is awesome.

Lokathor (Apr 21 2020 at 04:39, on Zulip):

I'm with you so far.

Charles Lew (Apr 21 2020 at 04:39, on Zulip):

However I'm thinking about something in larger scale. In data processing applications and many other applications, we are often processing data following some kind of external specification, written in schema or some other form. These specifications are sometimes very large. Examples are MS OOXML specifications and many others.

Lokathor (Apr 21 2020 at 04:40, on Zulip):

For that you'd probably use a "type that is less typed". For example, an general XML tree type instead of having a specific type for a specific XML DTD.

Charles Lew (Apr 21 2020 at 04:40, on Zulip):

Yes, exactly.

Charles Lew (Apr 21 2020 at 04:41, on Zulip):

However, to achieve ergonomics the more specialized API needs to be created. It's no fun for downstream crates to deal with the general types.

Lokathor (Apr 21 2020 at 04:41, on Zulip):

woahhh that's a bit of a leap maybe

Charles Lew (Apr 21 2020 at 04:43, on Zulip):

Imagine i'm writing a docx format report generator, with a xml dom library and xml writer library, theorically it's enough.

Charles Lew (Apr 21 2020 at 04:44, on Zulip):

There's a lot of schema information that should be mapped to API surface.

Lokathor (Apr 21 2020 at 04:45, on Zulip):

And focusing on your exact needs lets you cut a lot of corners. For example you don't need to support 100% of XML to parse a lot of XML description files, you can usually get away with like a 200 line module that as a super simple API.

Charles Lew (Apr 21 2020 at 04:47, on Zulip):

Yes, that's right. However it seems to me it's just delaying the problem, "i'll add what i need now and leave the rest to the future".

Lokathor (Apr 21 2020 at 04:48, on Zulip):

having every feature ever in every crate ever is just a way to summon code bloat.

Lokathor (Apr 21 2020 at 04:48, on Zulip):

There's a lot of reasons people don't like rand, and one of them is "I can't even tell how to make the dumb thing go"

Charles Lew (Apr 21 2020 at 04:51, on Zulip):

I think you're right, but there're different scenarios. I think in many businesses you can't tell the customer "i'll add the missing features when you need it", things like that.

Lokathor (Apr 21 2020 at 04:53, on Zulip):

Well, sure, in most businesses you can say "I'll add the missing feature never.", but maybe more nicely somehow, like "We value your feedback and will work to improve on our core mission".

Charles Lew (Apr 21 2020 at 04:55, on Zulip):

Oh, i mean sometimes the delivery is one-shot. The source code and maintenance will be transferred to another party when it's "code complete".

Charles Lew (Apr 21 2020 at 04:56, on Zulip):

Maybe that's not a recipe for awesome software, but it's reality sometimes.

Lokathor (Apr 21 2020 at 04:57, on Zulip):

Sure, there's a lot of scenarios. If you're trying to attract users then having more features is good. If you're trying to finish on time then focus is good. And many places in between.

Charles Lew (Apr 21 2020 at 05:04, on Zulip):

So in short, i think i'm seeking ways for "mass production" of rust code, that will enable its use in more business scenarios.

Charles Lew (Apr 21 2020 at 05:05, on Zulip):

Designs and tools to deal with the "uninteresting but large part" of the system.

Last update: Jun 05 2020 at 23:15UTC