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

Post by pdimitar » Wed, May 22, 2024, 9:14 AM UTC

Xeamek wrote: post #126

hdjksndhsi wrote: post #103

Earlier quoted context omitted.

So a few things .. Rust is a very good safe language. It also has an unsafe keyword to make the compiler ignore borrows etc. If you want fast iteration, use python and then hand transpile your code into rust. Not every tool has to be used at once ... but Python for the idea and rust for the implementation can be the best of both worlds ... :)

Except Rust's unsafe is even worse then any other 'unsafe' languages. And while you can technically prototype in a other language, speed of iteration is always a bottleneck. The only way to escape it is if You are an about master of language, the project you are working on and even the feature you are adding. But that's a verry rare case scenario

Post by Xeamek » Wed, May 22, 2024, 9:15 AM UTC

pdimitar wrote: post #99

Xeamek wrote: post #97

Earlier quoted context omitted.

There are restrictions out on You by the borrow checker to ensure safety, and then there are restrictions put on You by rust design team 'just because'. Again, the former are fine, it's the latter I have a problem with.

In order for me to agree on the "just because" part you'll have to give some examples. What made you think they are arbitrary? And how did they prevent you from doing your job?

Post by p_l » Wed, May 22, 2024, 9:17 AM UTC

Xeamek wrote: post #59

polotics wrote: post #18

Earlier quoted context omitted.

This "accommodate less skilled practitioners" you wrote is something that never fails to puzzle me from C/C++ practicing colleagues: the idea that in the problem space there is a high-risk high-reward zone of top performance where only the heroes dare tread. I am sorry but my observarion is that Nim and LLVM and dare I say even GC-less Java all achieve the same performance as C without the footgun baggage. Sometimes…

>I am sorry but my observarion is that Nim and LLVM and dare I say even GC-less Java all achieve the same performance as C This is just false. Sure, they probably are 'close enough', but you can't claim the performance is 'the same' simply because those languages inherently do more to achieve the same results.

Post by pjc50 » Wed, May 22, 2024, 9:18 AM UTC

highcountess wrote: post #49

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…

One can in fact not do anything about something for which one refuse to even consider the root causes of. In the case of shootings, one must talk about what may have caused shootings to start noticeably increasing in around the 1970s, to the point where a single year started having as many shootings as all the shootings prior to the 20th century combined. Fun fact; the first documented school shooting was perpetrated…

Post by lpribis » Wed, May 22, 2024, 9:20 AM UTC

p_l wrote: post #65

pjmlp wrote: post #56

Earlier quoted context omitted.

Kernels have been developed in safer languages already before C became widespread outside Bell Labs, it is a myth that C is even required for that, other than historical baggage.

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.

    *((volatile unsigned *)(0x20001000)) = 0x12345678;