Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

xeiaso.net

Post reply on HN
Print view View original

111–120 of 342 posts

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

#111

Post by jimwhite42 »

pjc50 wrote: post #63
tialaramex wrote: post #7

Earlier quoted context omitted.

It's a deliberate echo of the famous Onion headline about America's absolutely disgraceful pretence that it couldn't do anything about all the shootings. https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_... > If someone has a choice, a safer more modern language can accommodate less skilled practitioners. This is the usual mistake. It's not a "skill issue". Footguns are a design mistake, they're much more…

Rather like the school shooting issue, the C issue is bound up with people at the identity level; they insist on the danger because they cannot stand the possibility of the danger being taken away from them. Their ability to use guns or C safely must not be questioned. They percieve it as an insult to take that choice away from them. They are the safe C programmer that never ships a CVE. They know that they themselve…

Here's an attempt to explaining the irrational part of programmers deciding which programming language to use. Part of it goes into more detail on ideas like C programmers insisting 'on the danger because they cannot stand the possibility of the danger being taken away from them'.

"The Pervert's Guide to Computer Programming Languages" https://www.youtube.com/watch?v=mZyvIHYn2zk

It's pretty out there, but I thought also interesting.

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

#112

Post by jokteur »

pdimitar wrote: post #53

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…

I would love to be able to use Rust in my professional project. Unfortunately, I am doing high performance scientific computing. Rust doesn't even come close to offer any good alternative to cross-plateform, cross-device (CPU/GPU) libraries such as OpenMP Target, Kokkos, SYCL, ... I believe we need Nvidia/AMD to take Rust seriously (I'm not sure it is even possible without unsafe everywhere) to be able to offer good libraries.

In my world, using C++ is the modern language, because most project are stuck with Fortran.

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

#113

Post by pdimitar »

glass-z13 wrote: post #110
pdimitar wrote: post #102

Earlier quoted context omitted.

Maybe it's you and some other curmudgeons projecting -- worth to consider if that's the case. Maybe it's normal for people to praise something that legitimately solved their problems. I know that happened with me.

There is a difference between praising and preaching, the latter happens more often with rust

If you say so. ¯\_(ツ)_/¯

But even if it was true (I'd contest it's not) can't you ignore it and judge the language on its merits? We are not teenagers for a long, long time now, we should be making up our own mind about things.

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

#114

Post by baq »

cornholio wrote: post #31
astrange wrote: post #16

Earlier quoted context omitted.

The lack of memory safety is a property of C implementations, not the language itself. You can have an implementation that reliably crashes on memory errors if you want, though it does get easier if you leave out a few features like casting pointers to ints and back.

There is a multiple decade long history of coaxing a memory safe C embodiment. If it was possible to simply implement memory safety without fundamentally changing the language, you would have a compiler flag that would give to you, requiring no source modifications. No compiler gives you that memory safety flag (aside from very specific security features, ex. -fstack-protector) because it's not possible in C.

For the sake of the example let's assume you make a C to Python compiler/transpiler which uses native Python arrays for every stack or heap based allocation and every pointer arithmetic would be replaced by a checked operation, you'd quite likely get a memory safe language in the 'shellcode impossible unless you really set the program up for it' sense.

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

#115

Post by orf »

alternatex wrote: post #96
minikomi wrote: post #75

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.

It kinda is a powerful language feature But with great power comes great responsibility, and that doesn’t mean it was a good idea in hindsight.

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

#116

Post by pjc50 »

baq wrote: post #101
consp wrote: post #66

Earlier quoted context omitted.

> Code should be dumb and easily maintainable. Well ... that rules out everyone's pet favourite here to replace c.

which is C, because nothing can replace C. C is portable assembly. Don't use it unless you really must. Yes I know people want to replace C with Rust, no it won't work because Rust is not assembly, yes it can be used to replace anywhere between 90% to 99% of C and it shouldn't even be too hard. (Unless your embedded device manufacturer doesn't care, which of course they don't.)

> C is portable assembly.

Unfortunately, it isn't quite this, and many of the instances which people use it for this are actually undefined behavior; there's a hinterland of "things C compilers do" which are used as portable asm but are not part of C because they are UB.

I sometimes wonder if it would be feasible to define an actually portable typesafe macro assembler.

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

#117

Post by akoboldfrying »

rini17 wrote: post #60
cornholio wrote: post #31

Earlier quoted context omitted.

There is a multiple decade long history of coaxing a memory safe C embodiment. If it was possible to simply implement memory safety without fundamentally changing the language, you would have a compiler flag that would give to you, requiring no source modifications. No compiler gives you that memory safety flag (aside from very specific security features, ex. -fstack-protector) because it's not possible in C.

It is totally possible for pointers with bounds checking to exist in C. Turbo C did that 30 years ago. However, why bother trying when whole culture is biased against it and you can use any of the other languages?

>Turbo C did that 30 years ago.

I used Turbo C++ (not C) back in the day, and recall near pointers, far pointers, based pointers, but I don't recall bounds-checked pointers. Do you remember any details?

>However, why bother trying

Because it would immediately make the large amounts of C code still in the wild safer for the users, who do care?

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

#118

Post by flohofwoe »

pdimitar wrote: post #104
flohofwoe wrote: post #90

Earlier quoted context omitted.

There's a massive Terra Incognita to explore between Rust on one side and Python on the other side (just to pick two extremes). It's not "2 out of 3", it's a triangle where a language can pick a sweet spot anywhere within the triangle (and ideally, it's not a "sweet spot" either, but more like a "sweet area" where the programmer can pick an actual spot within that area defined by the language).

That sort of extreme flexibility simply does not exist. I mean it does but then you are firmly in the dynamic languages territory and you are forgoing any hope for close-to-the-metal performance.

IMHO it does and its not restricted to dynamic languages (like JS or Python), look at this Zig function signature for instance (just an example from my current dabbling):

   fn setData(comptime pins: anytype, bus: anytype, data: u8) @TypeOf(bus)
In practice this looks and feels like dynamic typing, yet when looking at the compiler output it still resolves to optimal code (since it's "compile-time dynamic typing" not "run-time dynamic typing", but the difference in practice is surprisingly small).

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

#119

Post by pdimitar »

flohofwoe wrote: post #106
komali2 wrote: 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…

> 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 may lead to all sorts of workarounds to appease the compiler, from 'restructuring' your structs into smaller pieces (which then however may fit one borrowing situation, but not another), or using 'semantic crutches' like Rc, Cell or Box.

That's valid, thanks for pointing it out. I seem to recall the team lately mentioning they are starting to consider fixing that. And yes that's a real productivity killer, happened to me as well in the past.

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

#120

Post by nottorp »

glass-z13 wrote: post #110
pdimitar wrote: post #102

Earlier quoted context omitted.

Maybe it's you and some other curmudgeons projecting -- worth to consider if that's the case. Maybe it's normal for people to praise something that legitimately solved their problems. I know that happened with me.

There is a difference between praising and preaching, the latter happens more often with rust

Before the current "AI" hysteria, HN was full of "I've rewritten this thing that was working just fine in Rust". No mention of how it's better, has more features - or even has all the original's features - or anything about why you should use the rewrite instead of the original.

Am I supposed to use a tool just because of what it's made of, or because it solves a problem for me?

Post reply on HN