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

101–110 of 342 posts

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

#101

Post by baq »

consp wrote: post #66
cookiengineer wrote: post #15

Alternative headline should be "But I have been taught that using C++ makes me the better programmer" because the stereotypes of echo chambers on the internet raised a lot of unreflected programmers to be this way. There is a place for C, where there's no alternative. But that place is where 99% of programmers never work, because they are not doing kernel nor firmware development (which, in the meantime, also has a l…

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

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

#102

Post by pdimitar »

nottorp wrote: post #98
pdimitar wrote: post #79

Earlier quoted context omitted.

That's why I said "almost anything". I am aware that f.ex. kernel development and embedded work is still firmly in the C domain. I am not evangelizing for Rust, Golang or anything in particular. I am evangelizing for periodically asking yourself "Am I still using the best tool for the job?" which most people never do.

Actually, maybe Rust would get more people interested if it didn't sound like a religion...

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.

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

#103

Post by hdjksndhsi »

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

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

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

#104

Post by pdimitar »

flohofwoe wrote: post #90
eterevsky wrote: post #76

Earlier quoted context omitted.

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

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.

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

#105

Post by TeMPOraL »

xena wrote: post #11
voidUpdate wrote: post #9

Earlier quoted context omitted.

This is also an ongoing series on that blog, if you look at previous entries there's lots with the same title, also about C having buffer overflows

https://xeiaso.net/shitposts/no-way-to-prevent-this/ Generated by exactly 69 lines of Go every time: https://github.com/Xe/site/blob/main/cmd/no-way-to-prevent-t...

Kudos for faithfully reproducing the joke then.

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

#106

Post by flohofwoe »

komali2 wrote: post #91
Xeamek wrote: post #82

Earlier quoted context omitted.

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

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

There are also related restrictions about function call barriers. AFAIK the Rust compiler cannot "peek into" called function bodies to figure out what's actually going on inside those functions (and that information would be very valuable for fine-grained borrow checking), it can only work with the information in the function signature.

Again, disclaimer: take this with a grain of salt since I'm not a daily Rust user, but this is how I understood why Rust feels so restrictive.

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

#107

Post by xigoi »

flohofwoe wrote: post #39
cookiengineer wrote: post #15

Alternative headline should be "But I have been taught that using C++ makes me the better programmer" because the stereotypes of echo chambers on the internet raised a lot of unreflected programmers to be this way. There is a place for C, where there's no alternative. But that place is where 99% of programmers never work, because they are not doing kernel nor firmware development (which, in the meantime, also has a l…

> The issue I have with this narcisstic fatigue (similar to the author's point I assume) is that there is no reflection when they fuck up a codebase. Forgive my bluntness, but do you even know any C programmers? The ones I know are not at all a homogenous group (there isn't even anything resembling a "C community" - and IMHO that's a good thing btw). > The best code is the code that is safe and easy to read. These tw…

> C code is unsafe, but typically easy to read

Are you joking?

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

#108

Post by BoxOfRain »

nomilk wrote: post #22

More broadly: > "No way to prevent $THIS" say users of only language where $THIS regularly happens A weird psychological quirk I've noticed (of myself, and others) is we'll often exhibit a sort of 'programming language xenophobia', where we apathetically accept (or don't even notice) unpleasantries of our language of choice, yet be quite averse to the unpleasantries of other languages. Maybe it's due to sunk cost; ti…

This is definitely a thing I recognise in myself, a year and a half of writing Scala daily has made me much more prejudiced against Java than I was before.

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

#109

Post by pjc50 »

pdimitar wrote: post #88
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

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…

> C/C++ being non-opinionated is the main source of the security vulnerabilities

This. "Undefined behavior" is such a terrible way of thinking. As is the "we can assume in the optimizer that UB does not happen and then eliminate code on that basis", which allows the compiler to introduce bugs that only appear at certain -O levels.

It took decades to get them to define arithmetic as twos-complement.

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

#110

Post by glass-z13 »

pdimitar wrote: post #102
nottorp wrote: post #98

Earlier quoted context omitted.

Actually, maybe Rust would get more people interested if it didn't sound like a religion...

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
Post reply on HN