Re: [GENERAL] C++ port of Postgres

I'm sure this wasn't your intent, but the tone of your response is part
of why people don't get involved with Postgres development...

On 8/16/16 10:39 AM, Aleksander Alekseev wrote:
> Well, well, well. Another C vs C++ holly war, really?

Please note that you're the only person in the entire thread that's said
anything to the effect of a holy war...

> Who are these "folks"? How many more developers it would attract
> _exactly_, not potentially?

As someone else (Robert?) said, there's a decent chance of it attracting
some, and it should be rather non-invasive, so why not try?

> One again, which "people"? I've seen people complained that there is
> not enough code reviewers and testers. I doubt very much its something
> C++ will help with.

Will it suddenly draw 20 people? Probably not. But if the community
actually welcomes the effort Joy put forth and encourages him then we've
very likely gained at least one more; maybe several.

OTOH, if the community takes the stance of "WTF WHY DO WE NEED THIS?!",
we've just driven Joy and anyone else that's a C++ fan away.

When it comes specifically to reviewing and testing, you need to provide
some kind of reason for people to do that grunt work. A big form of that
is supporting people who want to change something about Postgres. (It's
certainly possible to get non-hackers to help with this stuff, but
that's a different discussion entirely.)

> And I wrote a blog post (in Russian) [1] in 2016 why nobody should (if
> they can) write a new code in C++. In my opinion Rust looks way more
> promising. However I personally prefer to wait like 5 years before
> using a new and shiny technology. This is also something I blogged
> about (in Russian [2], translation [3]).

I agree that Rust is more interesting than C++. I think it'd be great if
we supported it as well, but I don't know how practical that would
actually be. Note I said support, not use... it's going to be far more
challenging to make Rust (or even C++) a requirement to build Postgres.
Maybe we'll eventually go that route, after demonstrating the
significant benefits that would need to exist to make that work
worthwhile. It's going to be FAR easier to demonstrate that if the
native project at least supports using it, vs needing a complete fork.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461