ccommsxx

I don't think you need a good understanding of C++ to appreciate these features per-se. Only if you want to make a statement like "X is an improvement over C++ because of these".

For example, enforced const-ness/immutability, option types and automatic ressource management (RAII) are also already standard in modern/best-practice C++ code. In general I agree that there are a lot of nice languages features that rust currently has which would also be nice to have in the c-family languages.

As far as I understand, there is no accepted formal specification or even single source of truth for what the rust community thinks are the "rust memory safety guarantees". Only a large number of people that have completely convinced each other that "it's better than C++" with little proof and without even clearly defining their own semantics. Please correct me if I'm wrong here (a blog post does not qualify as a specification).

Relevant: https://github.com/rust-lang/rfcs/issues/1447

You took my post as saying "all systems code should be written in C and that should always stay that way because people don't make mistakes". However, that is not at all what I said (also see other replies).

What I said was that one should not blindly make the opposite (false) reverse assumptions, which are that "code should not be written in C/C++ because they are 'unsafe'" or "all code written in 'safe' languages is 'safe'" (both for a hand-wavy definition of safe). The point that I tried to make was that if you do not have a good understanding of C++, you're probably not qualified to comment on the matter of some alternative being safer/better than it or not. And also that just blindly repeating other's opinions is not a path to understanding in this case.

I realize that the linked article didn't say or do that, but my comment was clearly not directed at the author of the post, but at the community of this forum (just look around in this thread to find some of the group-think I'm referring to).

Again, the assertion that all code written in rust is automatically "safe" (let alone correct) is false unless you say what precisely you mean with "safe" in very specific terms. While there are some ways in which rust is "safe" while c-family languages are not, these cases are _subtle_ and you _will_ have to understand modern C++ first to see what they are.

But yes, rust could turn out to become a new widely accepted standard for systems programming some day and depending on whether you believe that or not, it might make sense to "invest" your time into it.

> Spend the next 5 years learning the ins and outs of C++, [..,] Spend a single month learning Rust. Play with it for another month or even two just to be sure. Hopefully after the 3rd month, they'll be 100% certain that their code won't break [...] Rust gives me the confidence to "compile once, run safe everywhere".

See, this is exactly the fallacy that I am criticizing. I think the belief that "C++ is too hard to learn but one could become a good systems programmer in rust in a few months" is - frankly - misguided. I think that in order to become a good systems programmer in rust, you _will_ have to know all of your systems basics (i.e. you should already be able to code in C for starters) and then some more. But sadly this seems to be the spin that their marketing is pushing also.

Personally, I found practical rust (that interfaces with actual system libraries - think openssl) to be more or less on par with good C++11 with RAII memory and ressource management in terms of practical memory safety. Having somebody writing rust code without a basic understanding of things like ressource management and threading is just as bad as having them writing "unsafe" C(++) code.

I hope I'm not feeding the trolls here.

Well, I agree with you on practically everything you said.

Just for the record, I never intended to imply that somebody should not criticize their tools until they fully mastered them and I certainly don't claim to have done so. I just (tried to) say that I don't like it when others recite opinions from some blog post without even a basic understanding of the issues at hand as I find it leads to a very superficial discourse. I also didn't mean to imply that new projects should be done in C/C++ for the sake of historical reasons or something similar.

In fact, I actually recently started working on a new project, written in rust (!) in an industrial setting. Part of the reason for my original comment is that I found there was _a lot_ of cult in content related to rust, in their marketing material and on rust-related posts on HN. While I really like some parts of the language, this aspect of the rust community is really turning me off at the moment and I hope it will get better over time.

I feel you're missing my point. The article doesn't mention rust but my comment was phrased in the context of the current rust craze on HN.

As I said, I agree with you and the author that all of us do inevitably make mistakes. I also agree that the c-family of languages makes it somewhat more easy to shoot yourself in the foot in a bad way than others. I'm not saying innovation on safe languages is bad, or that using safe languages is bad.

My disagreement with you and the sibling is probably on the point of whether one can learn something useful about the limitations and pitfalls of c-family languages by reading a single-page all-opinion post about it. You and the sibling appear to believe so, I do not. I don't think we will come to a complete agreement on this, but I certainly understand and respect your and sibling's view.

The worst thing about these kinds of articles is the troves of junior programmers that never touched systems programming with a stick before but will read this on hackernews today and sit in the office tomorrow lecturing seasoned coders how they´re dumb for not having seen the light and using an unsafe language.

This is how stupid cargo cult gets made, guys. It's easy to repeat some talking points that you found on the rust homepage or another internet forum, but doing that does not make you an enlightened programmer!

Do c/c++ for 10 years, like the author, and then you're qualified to comment about the topic. If you're new to this, try to put your time into actually learning about these topics and not just blindly repeating other peoples opinions. Please don't say things like "c/c++ is unsafe and should not be used" without understanding it first. And try to consider for a moment that a humongous part of the critical software in the world is written in it. It is the industry standard for all things embedded and low level. Consider that maybe the reason for that is not that everybody outside of hacker news is stupid.

The thing is, I'm not even saying the author is wrong (I don't think he is). I'm just saying that circulating these kinds of opinion posts here and then applauding each other for being such brilliant rust fanboys is not helpful.

Actually I remembered now that the last time I worked with the MySQL protocol (~2014) I had a similar problem: Some of our servers were still running an old version of MySQL so the client had to be backwards compatible. However, this old version of MySQL also used the "old mysql password" authentication which was found to be unsafe/broken at some point. So the MySQL guys deleted the documentation on how the old scheme worked and replaced it with a notice saying that it is insecure. Tough luck if you still had to support/implement it. The same thing has apparently happened here. Not only is the documentation gone, it's actually gone without a trace on the official website.

Turns out that all of this stuff has apparently been deleted from the official docs some time ago, so that's probably why you didn't find it :) (see sibling comment).

When I did a quick google to pull up the docs that I knew I had read when I implemented the mysql client I found & linked you to a non-official, old copy of the mysql docs from back then.

You can still find the docs for COM_QUERY result on the net though: https://github.com/cwarden/mysql-proxy/blob/master/doc/proto...

I can see what parents issue was now :) I had a look at the doxygen and all the goold old protocol documentation seems to be deleted/missing from the "official" documentation website. How come -- I found it really useful?

- https://dev.mysql.com/doc/dev/mysql-server/8.0.0/page_protoc...

- https://dev.mysql.com/doc/dev/mysql-server/8.0.0/page_protoc...

Take a closer look at the MySQL documentation. You dont have to reverse engineer anything - it's all there and documented (source: wrote a client impl based on the docs)

http://imysql.com/mysql-internal-manual/client-server-protoc...

http://imysql.com/mysql-internal-manual/connection-phase.htm...

http://imysql.com/mysql-internal-manual/com-query.html

etc

50GB of files in the 50KB-inf range can be at most 10e5 files, not 10e7. (10e7 would be 5TB of 50KB files)

But how? Where is the opt-in? Is including the javascript from ampproject.org considered an opt-in to give gogole a license to republish your copyrighted content?

There is no notice or terms and conditions/license or any kind of other legal agreement that I found on the amp website. [EDIT: actually the code on github is licensed as Apache 2: https://github.com/ampproject/amphtml]

So I don't understand how this works legally. You surely don't automatically sign over your copyright to somebody else by including their javascript library in your page?

I don't really get what you're trying to say.

Are you defending the fact that you benchmarked whats essentially a "function() { return 1; }", called that a "database operation" and then proceeded to claim to have achieved a level of performance "not possible with other databases"? Can you really not see how that is wrong on more than just one level?

Or are you saying it's okay because other "javascript database" vendors are also cheating in their benchmarks?

Look not to sound harsh but since you're claiming the "80mm ops/sec" as a technical achievement "not possible with other databases" I found it to be fair to actually review the benchmark you linked. What you're benchmarking for the "read" is this:

    benchmark(function(){
      gun.val(ok);
    });

It appears your benchmark is basically testing how fast you can do a simple javascript function call which has nothing to do with any database operation whatsoever? How is that useful?

The benchmark doesn't reflect the performance of your gun database more than it reflects the performance of _any javascript application_. The only thing that is being benchmarked here is the javascript interpreter. Seriously, this is like somebody claiming their database runs at 4 billions ops/sec because that is how many instructions the CPU can perform.

Given how much effort you (clearly) put into your marketing and the way you worded this as a "cached read" I think you probably know all of this though -- so here's a plea: Please don't pull these kinds of completely dishonest stunts (you even put the BS numbers in the title of this submission). You just make others in the javascript [database] space look bad by association. Cheating on benchmarks will not convince anybody but the most junior web developers.

source (hopefully I'm wrong ;) ): https://github.com/amark/gun/blob/master/test/ptsd/perf.js#L...

   We're getting even better numbers on other devices:

   Android phone, ~5M ops/sec.
   Macbook Air, Chrome, ~30M ops/sec.
   Macbook Pro, Chrome Canary, ~80M ops/sec.
   Lenovo netbook, IE6, ~100K ops/sec

   [...]

   These numbers represent a breakthrough in performance not possible with other databases. 

from https://github.com/amark/gun/wiki/100000-ops-sec-in-IE6-on-2...

I've been waiting for a comment on why re-hosting verbatim copies of the original content by google is not considered copyright infringement? How come there seems to be no discussion on this at all?

looks like this contains a bunch of creative commons (CC-BY-SA) content ripped from wikipedia without proper attribution. please add the missing attribution

https://it.wikipedia.org/wiki/File:Pixel_geometry_01_Pengo.j...

https://en.wikipedia.org/wiki/Chroma_subsampling#/media/File...

etc