fredmorcos

Okay, so I came from C and this part really put me off. Why? Because I like saying what I mean, and meaning what I say. Nothing hidden, nothing implicit. And C, as opposed to C++, does not allow you to say something you don't mean.

Here is one C++ example, without looking for the signature of f(), there's no way to tell the answer. So essentially two pieces of identical code with identical input values and no external side effects can still give you different output. Ah C++, the garbage that you are.

  int x = 5;
  f(x);
  // WHAT IS THE VALUE OF X HERE?

  int x = 5;
  f(x);
  // WHAT IS THE VALUE OF X HERE?

So why is Rust any better in this regard? Because at the end of the day, Rust deals with actual concrete types and values, the only thing references are good for is being references: they sometimes save you some copying and let you refer to stuff and that's pretty much it. So the "ref1 == ref2" operation is a deep equality check and not a "does ref1 point to the same object as ref2" check. Because sometimes objects in different places in memory can be semantically equal. So it's okay for obj1 to mean obj1, &obj1 to mean obj1, &&obj1 to mean obj1, etc...

If you need raw pointers like you need in C, because you know the objects you want to compare are singletons, then you can always cast using

  &obj as *const Obj

or

  &mut obj as *mut Obj

But that's an escape hatch.

BTW, this auto-dereferencing you're experiencing is part of the Deref trait if you ever want to overload it. But that's, in my own opinion, an escape hatch as well.

All in all, unless you're doing very specific things, try to write your code in high-level semantics (meaning using these deep-equality rather than pointer-equality semantics), and then benchmark and find out which parts are hurting your performance. Rust allows you to do that and still get between very-reasonable-and-very-good speed.

> This is a funny comment.

Funny would be an understatement.

> Oh, did you believe all checks needed to make Rust memory safe is done at compile time? Well that's too bad.

Actually yes. You can write all the programs you want without runtime borrow checking, but it's inconvenient. Runtime borrow checking happens _only_ when you use cells.

So basically there's no speedup.

> But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths and boring.

You mean like memory and resource management code? Oh wait.. you use a garbage collected language. lol

> You're comment

Need to thank you though, for adding value.

> Of course they are, its not your data that people don't like. They aren't downvoting the post, they are downvoting you.

Exactly my point.

> You have made no points today

Sure I did. One of them is right in your comment :)

> But notice how you still post and the downvote brigade still obliterates your score.

And even posts with actual data are being downvoted :)

This only goes to show just how subjective and emotional this community has become, where everyone just wants to share "but in my opinion" or "but in my experience" without having to back up any of their arguments, or even have any of their arguments or claims challenged and questioned and called out.

This essentially turns concrete, testable claims into happy dreaming about technology. And that's really what this has become: everyone sharing their idea of what something should be and presenting it as fact.

I guess I've made a very good point today!

> The claim is testable, in theory.

It's not feasible to test in any practical way.

You said it yourself:

> If what you're trying to convey is that abstract reasoning based on fundamental principles without any consideration of real-world complications is a superior approach to determining what's true, well, I reject that.

Enjoy :)

So it's not what I said it's just how I said it.

Really? Because when it comes to something testable, like in this case either running a test of yes vs /dev/zero or looking at the source code of everything involved, there isn't any uncertainty that OP's statement is obviously incorrect.

The only uncertainty is OP's use of "back then", "from memory", "maybe", "could have", etc... without providing any evidence to support their statement.

OP's own comment shows that /dev/zero is faster: https://news.ycombinator.com/item?id=14544002

I responded in the terms you were using, hoping that it would become clearer to you.

> It is not obviously incorrect that one time a Pinto beat a Tesla

Yes it is, because OP forgot to mention the Tesla was dragging a bunch of rocks and the Pinto was dropped off a cliff. So was I supposed to have the power to read OP's memories and go back in time to check whether they provided us with all the information we needed to check their claims? No, I worked with exactly what's in the comment.

So without catering to your language/terms you use: it is obviously incorrect. Even OP's own comment later in the thread (on a modern system though, mind you) shows that: https://news.ycombinator.com/item?id=14544002

> I really don't see how it's "obviously incorrect" when yes only needs to make system calls for writing, whereas /dev/zero needs to make system calls for both reading and writing. Furthermore you're assuming that both are highly optimized, whereas it's entirely conceivable that /dev/zero is less optimized.

When you're "only writing", there is a counterpart that needs to read, and you have to wait for that, same as /dev/zero. It's more conceivable /dev/zero is more optimized than yes: you know, because of how pipes and streams are an essential part of a UNIX or UNIX-like system.

> If what you're trying to convey is that abstract reasoning based on fundamental principles without any consideration of real-world complications is a superior approach to determining what's true, well, I reject that.

I agree with that. But the original comment only gives us few options to check for its validity, and some of those are not feasible.

1. Actually finding all those systems, version-specific, combinations of userspace tools, setting them up and running the tests on hardware that was at OP's hand "back then": Not feasible.

2. Reasoning abstractly would tell us quickly that the original comment is plain wrong.

3. Running the tests on a modern system (some default linux install or whatever) shows that (2) is even more probably correct.

> You're free to spout your vitriol just like the people downvoting you into oblivion are free to use their downvote ability to express their dislike with your attitude. Free speech means you're free to express your ideas, it does not mean everyone else is forced to listen to them.

Did I disagree with that anywhere? Do you have a reference comment by me to point to?

> It's hard for me to view your comment as anything other than flamebait.

Ok.

> You're calling out someone in an aggressive tone, "You don't even know what you're talking about! Bah-humbug!"

I said I don't think they know what they're talking about. Without any of the shenanigans you portray here.

> and then crying crocodile tears that other people are "being mean" to you.

What? Where did I claim anyone is being mean to me? I made my argument to everyone who asked why I was being combative.

So again, do you have a reference comment by me to point to?

> You admit that you don't have enough details to know exactly what they're referring to, yet you're confident enough to call their personal experience "obviously incorrect"?

I didn't admit to not having enough details. You have two tools:

1. Reasoning about the abstractions and implementations of how yes and /dev/zero work: the claims become obviously incorrect, even their own tests later in the thread show that on a "modern system".

2. Actually running the tests they claim (which would prove them correct): no freaking way to do that. Even they do not offer any numbers to back their own claims because everything in the argument is a maybe or a remember or a might or a may have.

> People's personal experiences can be interesting, and that adds to the conversation.

People claiming their personal experiences are fact without proving anything is hugely problematic. Remember that woman claiming her child got autism due to vaccines? Remember that US president claiming a child got autism due to vaccines?

I remember seeing the earth as flat when I was working as an astronaut on the ISS. Go check my "personal experiences".

I hope you see what I'm trying to convey here.

> in my experience, you're incorrect about the speed of reading from /dev/zero

> Instead you picked a fight

So I harshly pointed out that they're mistaken. Then it was pointed out to me that I wasn't being nice. So I responded by showing why I didn't feel the need to be nice and provided my reasoning for it.

Since it seems to be too much trouble, here is the post I'm getting the "imaginary" quotes you refer to from: https://news.ycombinator.com/item?id=14544002

Absolutely, I once trivially proved a 1000,000 line implementation of return 0 to be correct. I don't know why all comments are bothered by how much overkill this yes implementation is. Maybe they don't hold 100,000 PhDs like we do, am I right?

> even within enterprise apps.

The epitomes of today's software. I really like how you used "even".

The Leopold FC750R(T) mechanical keyboard.

> And yet huge amounts of the "civilized world" are largely tied to the US.

What? The USA is the least civilized country in the west and many parts of the east.

Big fancy words with zero content and a complete lack of arguments.

> He says "most likely", but even this is not certain.

That is the exact meaning of most likely.

> Simply because most companies we know that have acted in such a way actually were eavesdropping on its customers, one cannot say with certainty that this is a general rule.

It would be plain idiotic to not assume the worst until proven otherwise, especially after everything we learned in the past few years.

> char pointer array of size X called arr

That does not even English.

'char ٭arr[X]' over '٭char[X] arr'

What is this dirt after char and before char? This wouldn't even compile.

1. For "modern C" it would be K&R, then learn Haskell; especially take note of its type system and how you can apply what you learn there in C.

2. The C standard draft, your compiler(s') manual and man pages if you're on POSIX. Also pencil and paper for drawing your arrays.

Clarification about 1: Haskell has good solutions to a lot of problems that have plagued programming, learn them because they are not language-specific but are mindset-specific. The advantage is that once your mindset changes, you start paying attention to off-by-one errors and potential overflows and overruns. You also start paying attention to using the correct types in a C program and you start taking advantage of enums to reduce the space of possible states in each function in your program. Once this clicks, memory management is a breeze.

Also learn the mindset of solving the problem at hand and nothing but the problem at hand. C is not a language for creating abstractions everywhere, it's a language for writing down as little steps as possible to solve that specific problem.

The resources you refer to are abysmal, criticism is available and widespread online if you want details.

You get proficient at C programming by properly understanding what you learn rather than spend countless hours in trial and error cycles.

There isn't much magic to it and the concepts are quite simple. In my opinion if you're looking to get up to speed quickly instead of carefully writing code then C is not for you.

> That and of course spending countless hours debugging segfaults and memory leaks.

Maybe that's because you think that:

> the best way for learning C has been [0] Build Your Own Lisp and Zed Shaw's [1] Learn C The Hard Way.

No I don't think it does that either. What it dampens is the vibration caused in the steel plate due to the switches - aka the dreaded "ping" - bottoming out can be a factor of course, but so are switch springs moving back into position or even just banging the keyboard.

So? I adore the buttery smooth feeling and even more so the consistency of all switches: blues are super inconsistent in sound if you pay attention and browns feel like there's sand in the switches.

I like red switches and I hate browns and blues. What the hell are you talking about?