Live data from Hacker News

"No way to prevent this" say users of only language where this regularly happens

xeiaso.net

141–150 of 342 posts

Re: "No way to prevent this" say users of only language where this regularly happens

#141

Earlier quoted context omitted.

That's completely valid and that's why I said "almost anything" -- other things include kernel development and embedded. My broader point was that C/C++ are still kings in some areas but people insist on using them where a bunch of languages do better today.

Also cross-platform libraries, if you want to be everywhere, from computers and phones to set top boxes to weird Japanese rtoses you haven't even heard of, Rust just won't cut it.

Fortunately there are other languages that are more available cross-platform than Rust with its tiny Tier 1 list.

Unless ofc you're contractually obligated to use vendors half-arsed kludget together patchy version of GCC of unknown provenance that they compiled with barely half C support, let alone other GCC languages.

Re: "No way to prevent this" say users of only language where this regularly happens

#142

Maybe C programmers need some more thoughts and prayers at deployment time?

No, the only way to stop a bad dev with a strcpy() is a good dev with a strcpy().

Basically fuzzing then?

Re: "No way to prevent this" say users of only language where this regularly happens

#143

I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain these mythic qualities called "self-reflection" and "introspection". Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in…

This is one possibility. Have you considered the other, that you're the old-man-yells-at-cloud variety of narcissist? Hence why you choose to interpret things as everyone (except you) is defective. Everyone (except you) is laughable, completely lacking in self-awareness, refusing to adapt and be and do as they should (according to you of course). Because they're all lesser than you! That's why. You write Rust. So obv…

> Couldn't be reasons like inertia, or lacking the time, or not having the budget to change, or being too tired to learn, or any other such thing that'd let them be equal to you but just with differing priorities.

This is already included in the "almost anything" expression and you are the 4th person deliberately (or accidentally?) not noticing it.

There are valid cases for C/C++ both on technical merits and business specifics. I have not denied that.

---

The rest of your comment is just projection borne out of your faulty assumptions about my comment and it's thus not interesting at all.

Re: "No way to prevent this" say users of only language where this regularly happens

#144

Earlier quoted context omitted.

`this` was mostly prevented in JS with the introduction of arrow function expressions

I had someone on Reddit r/webdev try to convince me that 'this' was not a mistake but a powerful language feature. A small glimpse into the mind of JS fans.

If it didn't exist, people would come up with weird hacks to implement the few cases where you do need it. But those are rare.

Re: "No way to prevent this" say users of only language where this regularly happens

#145
post #91

Earlier quoted context omitted.

As someone just starting to finally learn Rust, I'm curious what some examples of this might be.

All AFAIK, since I only dabble occasionally in Rust: The borrow checker works on "struct granularity", but it would be much more flexible and convenient if borrowing would work on memory location granularity (for instance passing a struct reference into a function "taints" the entire struct as borrowed, even if that function only accesses a single item in the borrowed struct - this 'coarse borrowing' restriction then…

They made a lot of progress with borrow checker granularity between 1.0 and now. It's much more granular now than before.

Re: "No way to prevent this" say users of only language where this regularly happens

#146

I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain these mythic qualities called "self-reflection" and "introspection". Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in…

No, more people should be using memory managed languages like Java and Golang. Then educate and expose people to sum types and pattern matching. It is actually insane how people is still unconvinced about sum types. Imagine how insane it is to program without product types? That's exactly what it felt like.

Re: "No way to prevent this" say users of only language where this regularly happens

#147
post #65

Earlier quoted context omitted.

Especially when one adds how many "low level programming" idioms for C are, as far as I understand, undefined behaviour in C. Like assigning an address to then use as pointer to physical memory... Which is extra visible when one looks at original UNIX sources and its many short assembly bits in separate files to handle bits of direct hw manipulation.

> Like assigning an address to then use as pointer to physical memory... What do you mean by this? Like writing to a specific integer address? *((volatile unsigned *)(0x20001000)) = 0x12345678; That's not UB and is also the only way to write to memmapped registers.

> That's not UB

Please cite chapter and verse of the C standard which defines this behavior. Any edition.

Re: "No way to prevent this" say users of only language where this regularly happens

#148
post #64

Earlier quoted context omitted.

Eh, Rust would be fine if not for the fact that it's too opinionated. Unfortunately you can't just have Rust's safety checks, without opting into restrictions that Rust designers force onto You that aren't inherent to safety checks, but more because 'that's a better practice (according to us)'. And also, easy and fast iteration just isn't there, both because of borrow checker restrictions and compile times

C/C++ being non-opinionated is the main source of the security vulnerabilities. Let's face it, it felt good to be a lone cowboy carrying a lot of responsibility and knowing what you are doing. I was there myself and I'll admit the ego trip was awesome. These times are long past and naturally, people refuse to adapt. > Unfortunately you can't just have Rust's safety checks, without opting into restrictions that Rust d…

I’d say the biggest problem of interpreted, JIT compiled, and GCed languages is not the speed; it’s the RAM use. I agree that quite often we don’t need the speed of close-to-the-metal. But there is something wrong with most programs eating tens or hundreds of megabytes, without doing much.

Re: "No way to prevent this" say users of only language where this regularly happens

#149

I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain these mythic qualities called "self-reflection" and "introspection". Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in…

No, more people should be using memory managed languages like Java and Golang. Then educate and expose people to sum types and pattern matching. It is actually insane how people is still unconvinced about sum types. Imagine how insane it is to program without product types? That's exactly what it felt like.

> It is actually insane how people is still unconvinced about sum types.

Oh don't even get me started on this but I agree sooooo much.

> No, more people should be using memory managed languages like Java and Golang.

Well, I use both Golang and Rust depending on the need. We can have both, it's not an either-or.

Re: "No way to prevent this" say users of only language where this regularly happens

#150

I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain these mythic qualities called "self-reflection" and "introspection". Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in…

[deleted]
Post reply on HN