5 ms·

For databases, C/C++ is still the only reasonable choice. For OLAP cubes in particular, you want to keep as much data in memory as possible as efficiently as po

by melted 11y ago

For databases, C/C++ is still the only reasonable choice. For OLAP cubes in particular, you want to keep as much data in memory as possible as efficiently as possible, and drop down to SSE intrinsics where needed. C++ lets you do just that. Frontend can be in any language you like.

pcwalton 11y ago
There are several other languages that have "ability keep as much data in memory as possible as efficiently as possible" and "drop down to SSE intrinsics" as features. C and C++ by no means have a monopoly here.
- melted 11y ago
  How battle tested are those languages? How many outstanding bugs do they have in their compilers and libraries? How good is tooling support? How easy is it to find competent programmers? How well do they interoperate with existing high performance libraries? That's just a small sample of issues you need to consider when starting a serious project. I maintain that it's hard to compete with C/C++ on all of those criteria.
  - pcwalton 11y ago
    Moving the goalposts to "every single advantage C++ might possibly possess" isn't very interesting. The idea that using a new language can only be justified if the language surpasses C++ in every conceivable way is very 1995, pre-PL Renaissance thinking. In reality, you can only choose programming languages by balancing all the factors in question, and C++ has plenty of disadvantages for databases: it's unsafe, it's difficult to learn, compile times are poor, there's no package manager, etc.
    - melted 11y ago
      Says someone who has quite obviously never worked on database engines. Package manager? LOL. What language are you programming in, Ruby?
      - tomjakubowski 11y ago
        pcwalton works on a web browser engine, which I'd say is at least as "complicated" as a database engine. He's already stated the benefits Cargo brings to Servo's development (as compared to working on, say, Gecko) elsewhere. What makes you think a package manager wouldn't be useful for a database engine which may want to, just as an example, provide a web server for queries or administration? [1][2] (Honestly, I'd rather call Cargo a "project manager" , because it does far more than manage packages -- it builds your project and its dependencies, too. Having a completely standard way to build applications and libraries is an enormous win over C++. The discovery and management of a project's packaged dependencies is of secondary importance to me.) [1]: http://docs.basho.com/riak/latest/dev/references/http/ http://docs.basho.com/riak/latest/dev/references/http/ [2]: https://www.rethinkdb.com/docs/administration-tools/ https://www.rethinkdb.com/docs/administration-tools/
        melted 11y ago
        Compared to DBs browser code bases are lax and buggy beyond belief. Want to take a second and a gig of RAM opening a page? Go right ahead. Browser crashes? We're "sorry", wait for next release 2 weeks from now. No multitenancy. No having to deal with data of arbitrary size. No transactions. No writing anything complicated to disk. Etc, etc. You're comparing things that really require completely different levels of rigor, sophistication and engineering skill. Last I checked, BTW, all currently shipping browsers are written in C++.
        pcwalton 11y ago
        Browsers certainly do have to deal with multitenancy (although we don't call it by that name), data of arbitrary size, transactions, and complicated on-disk data structures. In any case, you now seem to be primarily interested in arguing that database programmers are smarter than all other programmers, which, needless to say, is about the most uninteresting conversation we could possibly be having.

by melted 11y ago

pcwalton 11y ago

There are several other languages that have "ability keep as much data in memory as possible as efficiently as possible" and "drop down to SSE intrinsics" as features. C and C++ by no means have a monopoly here.

melted 11y ago
How battle tested are those languages? How many outstanding bugs do they have in their compilers and libraries? How good is tooling support? How easy is it to find competent programmers? How well do they interoperate with existing high performance libraries? That's just a small sample of issues you need to consider when starting a serious project. I maintain that it's hard to compete with C/C++ on all of those criteria.
- pcwalton 11y ago
  Moving the goalposts to "every single advantage C++ might possibly possess" isn't very interesting. The idea that using a new language can only be justified if the language surpasses C++ in every conceivable way is very 1995, pre-PL Renaissance thinking. In reality, you can only choose programming languages by balancing all the factors in question, and C++ has plenty of disadvantages for databases: it's unsafe, it's difficult to learn, compile times are poor, there's no package manager, etc.
  - melted 11y ago
    Says someone who has quite obviously never worked on database engines. Package manager? LOL. What language are you programming in, Ruby?
    - tomjakubowski 11y ago
      pcwalton works on a web browser engine, which I'd say is at least as "complicated" as a database engine. He's already stated the benefits Cargo brings to Servo's development (as compared to working on, say, Gecko) elsewhere. What makes you think a package manager wouldn't be useful for a database engine which may want to, just as an example, provide a web server for queries or administration? [1][2] (Honestly, I'd rather call Cargo a "project manager" , because it does far more than manage packages -- it builds your project and its dependencies, too. Having a completely standard way to build applications and libraries is an enormous win over C++. The discovery and management of a project's packaged dependencies is of secondary importance to me.) [1]: http://docs.basho.com/riak/latest/dev/references/http/ http://docs.basho.com/riak/latest/dev/references/http/ [2]: https://www.rethinkdb.com/docs/administration-tools/ https://www.rethinkdb.com/docs/administration-tools/
      - melted 11y ago
        Compared to DBs browser code bases are lax and buggy beyond belief. Want to take a second and a gig of RAM opening a page? Go right ahead. Browser crashes? We're "sorry", wait for next release 2 weeks from now. No multitenancy. No having to deal with data of arbitrary size. No transactions. No writing anything complicated to disk. Etc, etc. You're comparing things that really require completely different levels of rigor, sophistication and engineering skill. Last I checked, BTW, all currently shipping browsers are written in C++.
        pcwalton 11y ago
        Browsers certainly do have to deal with multitenancy (although we don't call it by that name), data of arbitrary size, transactions, and complicated on-disk data structures. In any case, you now seem to be primarily interested in arguing that database programmers are smarter than all other programmers, which, needless to say, is about the most uninteresting conversation we could possibly be having.