Some feedback:

1. You really need to remove that picture of Eich. It's just bad. We get it, he's a visionary who wears suits. Please don't downvote me, it's legitimate criticism. It's vain and out of touch. A picture of him is fine but one that is less market-y, more down to earth, isn't trying as hard.

2. The ad-experience-oriented value-add over existing browsers is too low. The vast majority of people just want a fast/stable/free browser to search google and browse Facebook. For the most part they aren't conscious of what browser they are using. When it comes to web-based tracking/advertising they either don't care or don't know to care. It's sad but inescapably true.

Additionally, for those who do care about privacy and/or are aware that their browser is a program they can change, they definitely don't want to pay for an ad-free experience. Why would someone pay for ad-free Brave when they can use ad-free Firefox/Chrome for free? If you're going to argue that they can make money with Brave, how much money are we talking? I'd guess dollars if not cents, is that worth it?

I really hope the Brave team can realize their project is a mistake before learning the hard way. There is definitely a more successful thing out there that they could work on.

Since this really comes down to a question of "who are we appealing to?", I'll throw my two cents in.

I like that picture. I'm glad for once, that someone in the tech sector is wearing a suit. I don't view suits as a reflection of personal quality, but I do like them as a fashion statement.

To be honest, I've never really understood the US motif where wearing a tie and/or suit is equivalent to being dressed up or out of touch with the common man.

School children here (and also in the UK), wear ties and blazers so wearing a tie doesn't feel 'corporate' or stuffy at all to me.

Lots of figureheads in tech wear suits in marketing materials.

Even still, my criticism isn't specifically or especially the suit. That's just a superficial component of the deeper flaw. It's just looks like it's trying too hard, doesn't look natural, feels cringy. I mean, who sits on a bench in a suit by themselves looking ambiguously into the distance while clasping their hands together? It's weird.

Funny, to me this joke promotes of the idea of JavaScript, inconsistent, annoying to read, total trash, etc. Very bad one.

Taiwan is better than China. China is awful.

Complete the loop. Make the browser a tmux client...

I thought about it, but it would bring this outside of the scope of a weekend project :) Besides, gotty might be better suited for that task: https://github.com/yudai/gotty

You have no idea what you're talking about. You're wrong, MyHDL is a proper hardware DSL in Python. You've never used it and you have no idea what you're talking about

Chisel doesn't help. It just converts to verilog. The verilog is then converted by a closed source program to a closed file format that is then uploaded by a closed sourced program to closed fpga hardware.

Compiler will not warn this:

    MovableObject a, b, c;
    b = std::move(a);
    c = std::move(a);

`c` may contain garbage.

BTW the "move trait" (as its called in rust) is a related but orthogonal concept to its borrow checker.

In Rust, moving isn't a trait. It's the default, non-overridable behavior of assignment and argument passing. And everything is movable.

Also C++ is generally as fast as C. If anything, it's faster thanks to increased opportunities for inlining.

Whoever says C++ is slower than C is misinformed and/or overgeneralizing.

Professional C++ programmers know this already though.

Well, much of C++ involves virtual function calls, and those are indeed slower than non-virtual calls. C doesn't have virtual calls, so that is perhaps one reason why C is generally assumed to be faster. That doesn't mean you must use virtual functions in C++; in fact, I don't use inheritance in my own code whatsoever, therefore I avoid the virtual calls but more importantly the restrictions that can creep into a tight OO hierarchy.

And std::function, from what I understand, is generally not as fast as a function pointer, a stored lambda, a function object, since it must do some run-time checks to see how to call what it is storing.

However, every sufficiently complex C program re-invents vtables (or has an even worse generic dispatching system), so you're often no worse off . . .

The only virtual call that you necessarily get with polymorphism is the destructor call.

Whenever you need to make a function virtual in C++, you'd need to store a function pointer in an equivalent C design, somehow.

Are you suggesting that C++ virtual functions have the same overhead as a C function pointer? I've never heard that; with the virtual call, there is the lookup + the invocation; perhaps a C app that stores function pointers in a hash map also has this sort of lookup, is that what you mean?

Vtable lookup in a typical C++ implementation is just loading a fixed offset in an array. In C terms, it's basically doing object->vtable[42]. In C code with function pointers, you're typically performing that exact same operation. You can go slightly faster if you store the function pointer in the object directly, at the cost of increased memory consumption per object if you have more than one function pointer.

Don't forget about the templates too.

A generic collection is usually faster when implemented using templates instead of void*.

Unless you use a DataDraw-like approach, I presume. I can't see templates doing similar amounts of data rearrangements.

You'd be surprised: http://bannalia.blogspot.de/2015/09/c-encapsulation-for-data...

Setting aside the cringe I experience whenever supposed principles of "OOP" are mentioned by the author, that page painfully reminds me of the that old joke about bolting four extra legs onto a dog... Furthermore, both a broader comparison (for more complex data and processing) and the technique I mentioned seems to be absent. However, I suppose it shows how to reclaim at least some benefits of better data arrangement even if the language isn't a good fit.

Did you speak of this "datadraw.sourceforge.net" ? It's the first time I heard of it. Have you used it ?

For a number of reasons, I'm not particularly fond of this specific implementation but I'm seriously considering porting its principles into something else (where they might work even better).

The only reason C++ has increased opportunities for inlining is because C++ often requires code to be placed in header files. If you wrote C in this style, you'd have the same opportunities for inlining, it's just that nobody writes it that way, because we generally prefer separately compiled libraries.

I'd even say it's generally faster because you can use integer as template arguments for enforced constant folding. Typically in video work: make a code path specialized when block width is 8, 16, 32 etc. Something that a C compiler can never do unless you use huge macros.

His logic is wrong. It's not because they are objects, it's because std::sort and friends are function templates. They know what they are calling at compile time. Templates allow for compile-time polymorphism like this.

Because of compile-time polymorphism, you can pass in prvalue function pointers and objects alike and the compiler will be able to inline.

C doesn't have templates, therefore it doesn't have compile-time polymorphism, therefore it's much harder for the compiler to inline.

Compilers like GCC and Clang can inline in some runtime-polymorphism circumstances. See -flto and -fdevirtualize.

> C doesn't have templates, therefore it doesn't have compile-time polymorphism, therefore it's much harder for the compiler to inline.

A C compiler can do the same inlining and optimizing as long as the called function (e.g. qsort) and the function that's pointed-to (e.g. the comparison function) are in the same compilation unit.

C++ templates do not add any magic here, std::sort() is simply faster because it's in a header file and qsort() is not. If you pass a function pointer to a function in a different object file to std::sort, it won't have a lot of advantages over qsort in terms of optimizations/performance (it still does know sizeof(T), though).

Link-time optimization should make standard qsort-type functions perform similarly to std::sort.

'idiomatic C++' != C

Idiomatic C++ is not well defined. There are so many possible ways to write C++ code that you should be skeptical if somebody promotes one version is the true one.