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

81–90 of 342 posts

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

#81

Post by jstimpfle »

tialaramex wrote: post #32
JonChesterfield wrote: post #17

Earlier quoted context omitted.

Simplicity.

This isn't a crazy thought to have about K&R C. They're trying to fit a high level language onto a 1970s computer and so sacrifices must be made. Some of the trades they make are... questionable and others I'd say clearly wrong (they just don't need Tony's billion dollar mistake, nor to be so cavalier with types in general), but it's not as though they're targeting a machine with gigabytes of RAM and a multi-core CPU…

What things simplicity do you lose? I think there isn't much of a difference between these dialects. Most important one might be possibility to define variables on the spot instead of at top of block. Then, some people like C99 compound literals. I don't think any of these break simplicity, they are quality-of-life improvements with no interactions with the rest of the language semantics.

Next one is what, the C11 memory model? Doesn't take away any simplicity, just defines things better.

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

#82

Post by Xeamek »

eterevsky wrote: post #76
Xeamek wrote: 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

Unfortunately you have to pick 2 out of: - Lack of restrictions - Safety - Performance If you choose safety and no restriction, you pay the price in performance (for GC etc.)

Again, restrictions that are forced you for a price of safety are one thing. But what I'm complaining about are restrictions that don't have to be there to get borrowchecker working, but rather are there because designers arbitrary decided "it's better this way".

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

#83

Post by self_awareness »

Xeamek wrote: post #64
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…

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

Most programmers don't have any opinions, so if they use an unopinionated language, they end up using patterns that opinionated people use. So it's better to have one source of truth for opinions, so that we don't end up using the "wrong" opinions of people who talk more than they think.

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

#84

Post by jstimpfle »

marcyb5st wrote: post #50
JonChesterfield wrote: post #17

Earlier quoted context omitted.

Simplicity.

With all the language features I agree. However, if you reduce the language surface it is possible to have something safe and simple enough (IMHO). For instance, you can say no async, no custom traits and only {Debug, Display, Eq, PartialEq, ...} are allowed for your structs and generics. From limited personal experience that takes away more than half of the complexity of navigating rust code.

The more you take away, the closer you are to a simple but unsafe language. If you remove the "unsafe" keyword, many things you can't solve easily nor optimally.

You might be able to outsource some complexity to external libraries, but integrating libraries is itself a major headache, and it can lead to security issues too.

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

#86

Post by xena »

blueflow wrote: post #67
xena wrote: post #55

Earlier quoted context omitted.

They're being satirical. People usually berate my posts because I have cartoon characters for Socratic exchanges to teach people things like Kubernetes, claiming that is "unprofessional" or something. These people are sarcastically berating my post for NOT using that Socratic system.

No I'm not. I expected that there is some furry or anime girl visible when i click on that link. This is the stuff i do not want to have on my screen when there are coworkers nearby.

Have this: https://xeiaso.net/notes/2024/ai-hype/

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

#87

Post by ben_w »

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…

If you're going to go back there far, before it was independent, I bet there was something documented in medieval Oxford or Cambridge involving a longbow and/or an anelas.

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

#88

Post by pdimitar »

Xeamek wrote: post #64
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…

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 designers force onto You that aren't inherent to safety checks, but more because 'that's a better practice (according to us)'.

Show me something that does better and I'll switch tomorrow. But don't tell me C/C++ are better -- they are not. Too much freedom leads to CVEs literally every month somewhere and that's only because we don't have better vetting and checking tools, otherwise I'm sure we'd be getting one every day for a while.

> And also, easy and fast iteration just isn't there, both because of borrow checker restrictions and compile times

I agree on that, that's why I mentioned Golang. Most of the C/C++ systems I worked on around 15-20 years ago didn't need the close-to-the-metal speed because at least 90% of their time was spent on I/O... frak, even Python would have done well there. And Golang is times faster. It's a very nice compromise if you want to be productive and don't care super much about CPU speed efficiency.

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

#89

Post by blueflow »

xena wrote: post #86
blueflow wrote: post #67

Earlier quoted context omitted.

No I'm not. I expected that there is some furry or anime girl visible when i click on that link. This is the stuff i do not want to have on my screen when there are coworkers nearby.

Have this: https://xeiaso.net/notes/2024/ai-hype/

Bismuth crystals are less edgy.

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

#90

Post by flohofwoe »

eterevsky wrote: post #76
Xeamek wrote: 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

Unfortunately you have to pick 2 out of: - Lack of restrictions - Safety - Performance If you choose safety and no restriction, you pay the price in performance (for GC etc.)

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).

Post reply on HN