[HN Gopher] Postgres: The next generation
___________________________________________________________________
Postgres: The next generation
Author : mooreds
Score : 217 points
Date : 2023-10-10 14:08 UTC (8 hours ago)
(HTM) web link (redmonk.com)
(TXT) w3m dump (redmonk.com)
| dist-epoch wrote:
| > Who is going to be doing the work in 2043?
|
| ChatGPT. It won't matter anyway since we won't be around to worry
| about this question.
| DrDroop wrote:
| I've done a little bit of postgres work with the help of pgrx and
| I can recommend it as a platform to build data solutions. Another
| great resource has been the CMU channel:
| https://www.youtube.com/@CMUDatabaseGroup
| gavinray wrote:
| pgrx unfortunately has essentially zero documentation or
| samples on use outside of extensions.
|
| For instance, say you want to write a new Table Access Method
| handler. There are bindings to TableAM stuff in the core pg-sys
| SDK but no docs or examples on using it in Rust.
| throwjabdb wrote:
| TL;DR PostgreSQL are aging and Neon os hiring and training
| juniors instead of existing commiters so the developer base
| grows.
| choffman wrote:
| Article says Postgres launched in 1986. Wikipedia says 1996.
| fanf2 wrote:
| The POSTGRES project at Berkeley started in 1986, the open
| source successor became PostgreSQL in 1996.
| tristan957 wrote:
| > The implementation of POSTGRES began in 1986
|
| https://www.postgresql.org/docs/current/history.html
|
| Postgres started as a project at Berkeley.
| craigkerstiens wrote:
| So many thoughts on this. The community has definitely ebbed and
| flowed, on this for a while. A few varying pieces of insight with
| no intention other than to share a bit more on the PG community.
| And I'm sure some current and former colleagues already in
| comment threads are going to correct me on nuance of a lot of
| this.
|
| For several years there were no new committers at all. In recent
| years the team has tried to be a little more intentional about
| adding new ones and culling those no longer involved.
|
| About 15 years there was a phase of letting a lot of younger
| people earn their commit bit. I can recall 3 people by name that
| all got a commit bit before the age of 25, and they may have
| actually all been under 22. One of those three shortly after
| moved on to work outside of the Postgres community, another
| quietly was busy on other things for over 10 years before coming
| back, and the third was actively involved going forward. I
| suspect there was some unease of folks getting a commit bit and
| then sort of falling off a cliff so it slowed for a few years on
| adding new folks. Edit - sounds like it was less age driven but
| maybe still slightly related to some folks falling off that there
| was a slow down in new committers - tldr - you're not getting a
| commit bit right out of college for Postgres.
|
| What to me would be interesting but likely hard to gather is what
| age to people become a committer to Postgres. It wouldn't
| surprise me if the average age of getting a commit bit is closer
| to 45 than not. Many folks contributing come to Postgres after
| other systems work or just don't consider contributing to they're
| a bit more seasoned because it feels intimidating-I mean patches
| sent on a mailing list who does that any more? Postgres thats
| who.
| gavinray wrote:
| The thing about becoming a PG contributor is that the barrier
| to entry is fairly high.
|
| I love Postgres so much I have a PG tattoo, but from the
| perspective of the two ways you can contribute:
|
| - As a random user, in your free time: There's not a ton of
| "Good first issue" type tickets. Where you can ease your way
| into PG dev by working on something that doesn't require you to
| have context on many parts of the PG architecture and at least
| a little historical knowledge on why things are written the way
| they are. Also, it can be a bit intimidating to have your
| patches reviewed by the likes of Tom or Andres.
|
| - As a developer for a paid PG company like EDB/PG Pros/Crunchy
| etc: It's a sort of Catch-22 scenario here, where it's
| difficult to get hired as a junior without having previous PG
| hacking experience, but the path to doing that is not the
| easiest thing in the world.
|
| If I was going to work somewhere that wasn't $CURRENT_CO, it'd
| be somewhere doing PG work, but there's not a lot of viable
| avenues/inroads there.
| hlinnaka wrote:
| PostgreSQL isn't that special as a codebase. Every codebase
| has its quirks, every project has its own processes and
| there's a learning curve. When you switch to a new job as a
| software engineer, you pick it up. PostgreSQL is no
| different: you can hire an engineer to work on PostgreSQL.
|
| I'm not sure how well that path works in growing new
| contributors, though. In a usual company setting, the goals
| are better defined, and the company is in control. Once you
| reach the goals, mission accomplished. With an open source
| project it's more nebulous. Others might have different
| criteria and different priorities. You are not in control.
| Choosing the right problems to work on is important.
|
| Other storage or database projects would be a good source of
| new contributors. If you have worked on another DBMS, you're
| already familiar with the domain, and the usual techniques
| and tradeoffs. But to stick around, you need some internal
| desire to contribute, not just achieve some specific goals.
| harikb wrote:
| The biggest hurdle I see is that it is a C project,
| unfortunately something we can do nothing about. It is so
| much harder to trust a random code not have to have serious
| implications for the database. It will take ages for someone
| to get comfortable with the pg-code-base way of handling
| errors, basic string manipulation, memory alloc/free etc.
|
| I want to highlight the difference in "making a non-core
| contribution" to "understanding database internals". I am
| highlighting it is not the latter, but the former that is the
| first hurdle.
|
| I wanted to reuse builtin pg code to parse the printed
| statements from logs - I ended up writing a parser (in a
| non-C language) myself which was faster.
| gavinray wrote:
| Couple of points in this post, so will address a few of
| them: "(Paraphrased) C is bad, and it takes
| forever to pick up the PG-specific C idioms"
|
| There's probably not a productive conversation to be had
| about C as a language. I will say that as of C23, the
| language is not quite as barebones as it used to be and
| incorporates a lot of modern improvements.
|
| On the topic of PG-specific C -- there are a handful of
| replacements for common operations that you use in PG.
| Things like "palloc/pfree", and the built-in macros for
| error and warning logging, etc.
|
| I genuinely don't think it would take a motivated party
| more than a day or two to pick all of these up -- there
| aren't that many of them and they tend to map to things
| you're already used to. "I wanted to reuse
| builtin pg code to parse the printed statements from logs -
| I ended up writing a parser (in a non-C language) myself
| which was faster."
|
| It's true that the core PG code isn't written in a modular
| way that's friendly to integration piecemeal in other
| projects (outside of libpq).
|
| For THIS PARTICULAR case, the pganalyze team has actually
| extracted out the parser of PG for including in your own
| projects:
|
| https://github.com/pganalyze/libpg_query
| zxexz wrote:
| libpg_query is a godsend of a library. I spent a lot of
| time writing a custom parser before I found it - was very
| happy to replace the whole thing. A major boon was the
| fingerprinting ability - one of my needs was to track
| query versions in metadata.
| craigkerstiens wrote:
| I disagree on this. Yes it's C. But I've heard people
| comment "I don't like writing C, but I don't mind Postgres
| C".
|
| The bigger hurdle which Peter mentioned in another thread
| is simply building up enough expertise with the system and
| having the right level of domain expertise.
| stouset wrote:
| > Yes it's C. But I've heard people comment "I don't like
| writing C, but I don't mind Postgres C".
|
| While "Postgres C" might be wonderful, in practice
| learning the project's unique idioms is yet another
| hurdle for newcomers to overcome.
| eatonphil wrote:
| Every project has unique idioms. Let alone ones that are
| 30+ years old.
|
| Idioms are a baked in cost of learning to contribute to
| any project.
| fanf2 wrote:
| I found that I learned a lot when trying to write a logical
| decoding plugin. So I guess if you are a user of Postgres and
| there's some small friction you could reduce by writing a
| plugin, it's a good way to get started. Scratch your own
| itch, you don't have to publish the results :-)
| andrenotgiant wrote:
| I have the honor of working with a Postgres ~committer~
| _contributor_ who was just over 25 when they first contributed!
| The story about their first commit is great:
|
| They were testing SQL behavior for Materialize and thought to
| check that both systems handle interval functions identically.
| Being thorough, they tried something like:
| select interval '0.5 months 2147483647 days';
|
| You can try it yourself on dbfiddle[0] Instead of erroring,
| Postgres returned a bogus value `{"days":-2147483634}` you can
| read why here[1]
|
| So naturally they decided to fix it in Postgres, which is why
| they contributed and why it's handled properly in 15+ [2]
|
| [0] https://www.db-fiddle.com/f/ijT76fsmL99bHvXxhAtf7j/0 [1]
| https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...
| [2] https://www.db-fiddle.com/f/i3KikCb72AN1EZpywErZvr/1
| koolba wrote:
| > I have the honor of working with a Postgres committer ...
|
| That's not a committer, that's someone who submitted a patch
| that got committed. A committer is the one who actually
| applies the patch and can push the branch into the mainline
| repo. Committers decide if something is worthy of being
| merged.
|
| Now that aside, yes this plus reviewing patches to get a
| wider feel for the codebase is how you eventually become a
| committer.
|
| Best way to eat an elephant is one bite at at time.
| andrenotgiant wrote:
| Ahh thanks for clarifying - now I better understand the
| significance of the OP's point about the rarity of younger
| COMMITTER's.
| craigkerstiens wrote:
| This is a common source of confusion for a ton of folks.
| Anyone can submit a patch, but commit bits are reserved for
| a much smaller list. The attitude is something like you
| commit it, you maintain it-so if bugs come in you'll spend
| your time fixing those for whatever time it takes vs.
| working on the next shiny feature that you're excited about
| for the next release.
|
| There was sort of a fuzzy "major" contributors
| (https://www.postgresql.org/community/contributors/) which
| were people that contributed major features and then a list
| of other contributors. Depending on who you talk to this is
| either dated or a pretty close attempt at reflection of
| reality but not perfect. In recent years they expanded the
| contributors to include others that were contributing in
| non-code ways though it's still a decent place to find
| people contributing to major feature sets.
|
| Of course this is not to be confused with the core team-
| which is more like a steering committee. But not so much
| steering committee of code and feature sets.
| dist-epoch wrote:
| How much bigger (in lines of code) is Postgres now versus the
| one from 15 years ago?
|
| Maybe it was more approachable for a 22yo then, you could
| figure out more of it.
|
| Also, C was a standard language back then, today the kids are
| more likely to program in Rust than in C.
| anarazel wrote:
| > How much bigger (in lines of code) is Postgres now versus
| the one from 15 years ago?
|
| I was curious as well and wrote a, very crude, script to
| measure it: for t in $(git tag -l|grep -E
| 'REL.*_0$|REL[67]_[0-4]$'|grep -v REL2);do echo -ne "$t\t";
| git ls-tree -r $t --object-only |xargs git show |grep -a -v
| '^\s+$'|wc -l;done REL6_1 270033 REL6_2
| 320297 REL6_3 386532 REL7_0
| 630771 REL7_1 843219 REL7_2
| 986991 REL7_3 1363668 REL7_4
| 1492418 REL8_0_0 1649775 REL8_1_0
| 1702325 REL8_2_0 1806170 REL8_3_0
| 2017685 REL8_4_0 1924918 REL9_0_0
| 2011704 REL9_1_0 2225796 REL9_2_0
| 2290872 REL9_3_0 2405598 REL9_4_0
| 2487304 REL9_5_0 2527906 REL9_6_0
| 2632559 REL_10_0 2534653 REL_11_0
| 2771914 REL_12_0 2697892 REL_13_0
| 2822066 REL_14_0 2980221 REL_15_0
| 3054963 REL_16_0 3351147
|
| This is counting non-empty lines. It's definitely not a good
| measure of overall code size, as it includes things like
| regression tests "expected" files. But as that's true for all
| versions, it should still allow for a decent comparison.
|
| 8.3.0 was released 2008-02-01, with 2M non-empty lines, we're
| now at 3.4M.
| pcthrowaway wrote:
| I suspect you'd get much more useful results by checking
| out the version tags and running `cloc` -
| https://github.com/AlDanial/cloc
| samaysharma wrote:
| I don't have the data for the average age, but I was recently
| in a conversation around how long does it take to become a
| committer since getting involved in Postgres by writing code
| for it.
|
| So, I wrote a couple git commands like below [1] to figure out
| when someone was first named in a commit message vs when they
| made their first commit (as a committer) for the last 10 people
| who became committers.
|
| The average time of involvement was ~8.9 years (just comparing
| month / year), with the lowest being ~6.5 years.
|
| Obviously one could do better analysis but my goal was just to
| get an approximate understanding.
|
| [1] git log --grep 'Name' --format=%cs | sort | head -1
|
| git log --author 'Name' --format=%cs | sort | head -1
| wkoszek wrote:
| My aspirational goal is to be in a position to retire early and
| hack on Postgres full-time, it's so interesting. It has
| networking, storage, data, algorithms etc.
|
| C is less of a problem tbh. Postgres has good code style and its
| pretty consistent. The complexity of the internals is, and having
| a small community may infer the speed in which people help you.
| nikita wrote:
| You can work full time for someone as a Postgres committer.
| 1500100900 wrote:
| Unless you're Tom, you'll have to work on tickets assigned to
| you by some manager.
| samaysharma wrote:
| That's not really true any more.
|
| I personally know several Postgres contributors /
| committers who have a very high amount of control on what
| projects they work on.
| pjungwir wrote:
| I am hoping to be part of that "Next Generation"---although I'm
| already 46. I'm sure there are others a bit younger.
|
| My last talk at PGCon tried to fill some of the gaps around what
| you must know to hack on Postgres, especially the Executor Phase
| and TupleTableSlots. I'm not the most qualified, but sometimes it
| takes a learner to know what learners need. Just the other day I
| wrote a table of contents for a book about how to contribute to
| Postgres. I figure it would sell at least ten copies. Maybe a
| serial publication online would be better. Curious if anyone
| would be interested in either of those?
|
| For now Postgres is more like a hobby for me, but if someone is
| hiring to do open source Postgres contributions full time, I'm
| open to a chat. ;-)
| craigkerstiens wrote:
| Just coming to say hi Paul! I recall you being very excited and
| getting the email after you submitted your first patch and
| loved it.
|
| I think a ton of the current set of "next generation" came to
| Postgres a good bit later. Even Tom himself will tell you he
| did some stuff with images for a few years which undersells
| himself (tiff, jpg, png - in some form involved in creation of
| each of those), then found this Postgres thing and started
| working on it.
| pjungwir wrote:
| Craig, you really made me feel welcome in the Postgres
| community. Maybe people have. It's such an amazing group.
| Thanks for all the pg advocacy you've done!
| fanf2 wrote:
| I get the impression that publishing the work in progress
| online can be a good way to market the book, eg
| https://www.cl.cam.ac.uk/~rja14/book.html
|
| Some publishers allow early-access readers to help with
| reporting mistakes https://nostarch.com/early-access-program
| gavinray wrote:
| If you haven't already, you might be interested in reaching out
| to PG contributor Andrey Borodin.
|
| He does a lot of content focused around how to get started
| contributing to Postgres and is very friendly + interested in
| speaking with other PG enthusiasts.
|
| He might be open to collaboration or offering some helpful
| advice =)
|
| For example: https://www.youtube.com/watch?v=rihfAnd_leM
|
| You can reach him either via email (x4mmm@<repeat-the-
| previous>.ru) or Twitter (@x4mmmmmm)
| andatki wrote:
| Thanks. This looks great!
| pjungwir wrote:
| Thank you!
| biehl wrote:
| I would be happy to have a look at your book drafts.
| pjungwir wrote:
| Thank you! May I keep you in mind once I have something? My
| email is in my profile, so maybe send me a note. (I don't see
| yours.)
| biehl wrote:
| I sent you a note and added my email to my profile. Best of
| luck with the writing.
| davidthewatson wrote:
| +1 I'll buy your book. What's it called?
| pjungwir wrote:
| Thank you! It's just a table of contents. :-) And there is a
| book about temporal data I want to write first. . . . But
| it's awesome to hear someone is interested.
|
| EDIT: to plug a couple other independent-author Postgres
| books on my short-term reading list, these look awesome (but
| not quite the same focus):
|
| - https://postgrespro.com/community/books/internals
|
| - https://theartofpostgresql.com/
| tristan957 wrote:
| I am a new contributor to Postgres as of 5 months ago. I turn 27
| later this month. While I haven't contributed too much of value,
| I have a few commits here and there with plans to do other
| things, like make it easy to build Postgres extensions with Meson
| and hopefully drop the autotools build of Postgres ASAP. You
| might also catch me in the pgbouncer or pgvector repositories
| very soon.
|
| The story of how I came to contribute to Postgres is that I got
| tired of working at a software consultancy where I had worked for
| 3 years, 2 years during college, 1 year full-time. I had always
| more envisioned myself as an open-source systems software guy. I
| found a job at Micron working on an open-source storage engine.
| It kind of felt like luck to have found that job to be honest,
| but I felt like the job description was written for me, so I
| applied. I worked on that project for 2.5 years and loved it.
| Unfortunately, Micron laid off my entire team back at the end of
| February. I began searching for a job, and eventually received an
| offer from MongoDB to work on the C/C++ drivers, but that was
| rescinded. Then, I really started to lean into my network, and
| one guy I knew from #mesonbuild on Libera.Chat/Matrix worked on
| Postgres, so I messaged him and asked if there were any positions
| open in the Postgres space for someone with my background that he
| might be aware of. He told me that Neon was hiring, so I sent an
| application to work on their storage engine, but in the initial
| interview, my eventual manager thought that I would fit better in
| the new Postgres team they were forming, which would contribute
| upstream to Postgres. I am very appreciative to Neon for taking a
| chance on me.
|
| The topic of this blog post is interesting because it just came
| up during some discussions with other young Postgres contributors
| at PGConf NYC. Some points that we brought up:
|
| - It is hard to get patches looked at, even small ones. With
| better name recognition in the community, comes more patch
| reviews it seems, which is most likely the case in most projects,
| but still, it is a circular issue.
|
| - The organization of the Postgres mailing list is not very good.
| You are forced to drink from the firehose that is pgsql-hackers,
| whereas the LKML is organized into various subsystems. Modern
| code forges have value in that you can subscribe to certain tags
| on PRs/issues, which isn't the case with the current state of
| pgsql-hackers.
|
| - Adding things to a commitfest is a little burdensome. The only
| way to get a patch through the entire Postgres CI is adding it to
| the commitfest, and even then, you have to be proactive about
| checking it, or hope that a committer will tell you to look at
| the CI failure.
|
| - Bug reports are also sent to a mailing list (pgsql-bugs). There
| is no equivalent to the Linux bugzilla for Postgres for instance.
|
| - Patches are sent as attachments to emails, and not necessarily
| git-format-patched either, whereas the LKML uses git-send-email
| exclusively from what I can tell.
|
| All in all, it kind of seems like tooling in the Postgres
| contributor community works best for those that have been
| ingrained in it for 15+ years, which I guess is the case for most
| things. I don't want this to turn into a "Use GitHub/GitLab"
| post. Let it be known that I actually think email is the superior
| way to communicate about patches, but the tooling around the
| mailing list could improve. Everything seems very disjoint.
| SourceHut, I think, has done a good job of making mailing list
| development more approachable for the everyday contributor.
| Issues, mailing lists, CI/CD, and repositories are all connected
| to each other. There aren't separate services like they currently
| are for Postgres.
|
| This comment is probably worth a blog post of its own at some
| point, but I'll end it here. If you are also new to contributing
| to Postgres, perhaps we can share experiences. Email me at
| tristan <at> neon.tech or tristan <at> partin.io. Another
| Postgres contributor that I talked to thought it might be useful
| to have monthly meetings among non-committer contributors where
| we can talk about the patches we are working or have posted in
| order to get reviews from peers.
| candiddevmike wrote:
| I wonder if C codebases are going to have problems finding
| maintainers in the future. Postgres has commercial backing and
| inertia, but it seems like we are lacking a pipeline of
| (proficient) C developers.
| OJFord wrote:
| I doubt it, universities basically choose between C & Java as
| the main if not only teaching language. Sure the former might
| evolve into C++, but it somewhat inherently starts as C, and I
| suspect you didn't mean 'C developers' to exclude people with
| C++ experience anyway?
|
| An organisation worried about it can easily hire grads/juniors
| with a corresponding proficiency, and ensure that they still
| have that by the time they're seniors by employing them to work
| in C.
| packetlost wrote:
| If people are worried about Postgres, they should be _more_
| worried about Linux maintainership.
| piaste wrote:
| There are many more billion-dollar companies that rely on
| the Linux kernel than there are that rely on Postgres.
| packetlost wrote:
| I mean, fair.
| hedora wrote:
| I'm guessing this won't be a major problem. I don't know any
| proficient Rust or C++ developers that are not also proficient
| C developers.
|
| I do wonder when even more C code bases are going to start
| seeing modules ripped out and replaced with Rust.
|
| This is already happening with Linux, curl, and with C++ stuff
| like Chrome, many MS products, Amazon S3, etc, etc. The biggest
| explicit holdout I know of is OpenBSD, and that's because
| they're trying to keep the bootstrap / base install toolchain
| small.
| rafaelmn wrote:
| I'm not proficient at C++ but I have written a decent amount
| of it (although not in years)
|
| While I'm sure I'd be able to pick up on the style of the
| project, it would take a lot of time. Large scale C looks
| completely different to C++. No RAII, no classes, virtual
| dispatch, smart pointers. Containers are completely
| different, templates/generics only via preprocessor.
|
| I think C requires a lot more conventions and experience to
| get correct code than C++, and especially Rust.
| petergeoghegan wrote:
| > Postgres has commercial backing and inertia, but it seems
| like we are lacking a pipeline of (proficient) C developers.
|
| It's difficult to get into Postgres development, but that has
| little to do with C expertise. The hard part is having the
| right domain expertise. Building up general familiarity with
| the system just takes a long time.
| anarazel wrote:
| (postgres hacker)
|
| Yes, I think that will be the case. Obviously not a
| scientifically measured, by I think we're already seeing that
| average C skills for new contributors are lower than what they
| used to be - of course that might just be my slowly greying
| beard speaking. So far I think people just "learn on the job",
| but how much delta that bridge I am not sure.
|
| I think eventually we'll have to make it easier to use some
| other language in parts of the system (e.g. in-core data type
| implementations). But realistically I think that's still a bit
| off.
| koolba wrote:
| > ... I think we're already seeing that average C skills for
| new contributors are lower than what they used to be - of
| course that might just be my slowly greying beard speaking.
|
| That's definitely true. Just like everything else, actual
| experience matters and the C-share of public codebases (out
| of the total set) is less and less every year. So while
| someone may have studied the docs and overall language
| mechanics, he'd be less likely to have actually worked on a
| different C code base. Even less so for people who have
| worked on _portable_ C software.
|
| > I think eventually we'll have to make it easier to use some
| other language in parts of the system (e.g. in-core data type
| implementations). But realistically I think that's still a
| bit off.
|
| There is an elegance to having the C structs directly match
| the data layout. But I suppose that it's only elegant if your
| mind has been wired from the start to think about byte
| alignment and word sizes. Coming from the world of
| interpreted languages with dynamic objects as bags of
| properties, I bet it's nowhere near as magical.
| eatonphil wrote:
| > There is an elegance to having the C structs directly
| match the data layout.
|
| Doesn't this ability significantly depend on the system
| (and also becomes less relevant when you have variable
| length data)?
| jmull wrote:
| Are there fewer C programmers than their used to be?
|
| Are they getting generally dumber for some reason?
|
| I get that younger devs often don't have the low-level
| background older devs necessarily have, but all of the useful
| skills are learnable (and they have less bad things to unlearn,
| too). All good devs, of any age, have learned to learn what
| they need when they need it. I don't think anything has changed
| there.
|
| I think the issue is more that key positions in these more
| prominent well established projects are usually filled and
| haven't been opening up.
| wg0 wrote:
| Now this might be idiotic take but isn't C easier and simpler
| to learn than Rust? Even Typescript's type system is pretty
| complicated compared to C.
|
| Or I might have revealed my ignorance about how much
| complicated C is.
| steveklabnik wrote:
| Brainfuck is easier and simpler to learn than C. That doesn't
| mean that writing an application in Brainfuck is easier than
| writing one in C.
|
| "which is easier to learn" is basically an inherently
| subjective concept at this point, we as a field do not have
| an objective way to answer this question, except for extreme
| cases like the one I am drawing above. For any "real"
| language, it is much, much, much less clear-cut.
| swatcoder wrote:
| In some future, of course, but that future is _decades_ away. C
| is a living language with no shortage of active users and a
| learning curve that 's not very steep for systems programmers
| working in other language.
|
| It can feel daunting to today's web and application developers
| who are used to an opaque curtain between themselves and the
| underlying system architecture, but systems programmers using
| C++, Rust, etc already work behind that curtain (but with
| thicker gloves). They've often worked with C in the past, at
| least in education or experiment, and can ramp up on the
| footgun quirks with some intentional study when taking it up
| professionally.
|
| There are arguments against picking C for some _new_ systems
| projects, but -- outside a lack of systems programmers more
| broadly -- there 's no pressing concern around finding
| maintainers for what already exists.
___________________________________________________________________
(page generated 2023-10-10 23:00 UTC)