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

151–160 of 342 posts

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

#151

Post by _old_dude_ »

orf wrote: post #115
alternatex wrote: post #96

Earlier quoted context omitted.

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.

Yes, it's functions vs methods. You can make this explicit like in Python, you can make it implicit but have two kinds of methods, instance methods and static methods like in C++/C#/Java.

And you have JavaScript were all functions have an implicit this ...

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

#152

Post by pdimitar »

nottorp wrote: post #140
pdimitar wrote: post #129

Earlier quoted context omitted.

I have not done either. "Curmudgeon" is a "get off my lawn, kids!" grandpa btw. :) I have not denied you anything, I implored you to ignore the zealots that exist IN EVERY ECOSYSTEM and judge the thing based on what it can actually do. Please don't misrepresent what I said, that's not arguing in good faith.

Heh, this grandpa has written like 3x more python than C this year. And the C part was no choice - that was all I had on these devices. Edit: from what I hear from my peers (translation: other programmers that I have coffee or drinks with), if I started a new server application today and I needed the performance of a compiled language, I should use Go not Rust. I believe servers are where the propensity of C like lan…

Servers and many CLI tools, yes. Buffer overflows and memory unsafety are really easy to allow there for everyone but absolutely Godlike C/C++ devs.

Golang, Rust, Nim, Zig, and a few others are a much better fit nowadays.

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

#153

Post by flohofwoe »

self_awareness wrote: post #83
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

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.

Compiler/language people are also just "opinionated people" though. Some have good opinions, some have bad opinions. In the worst case you have opinions which are the result of a 'design by committee/community' process.

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

#154

Post by nubinetwork »

> a vulnerability in HTTP parsing code that allows for heap corruption and arbitrary code execution by making a HTTP GET request with a megabyte of the letter 'A' in its body

You mean a buffer overflow? Why write so technical then dumb down something that's pretty obvious.

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

#155

Post by JonChesterfield »

jstimpfle wrote: post #81
tialaramex wrote: post #32

Earlier quoted context omitted.

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 me…

K&R gets used as a shorthand for the "portable assembly" C that some people remember and others swear never existed. That's my guess at what the parent meant, not the syntactic strangeness of writing types after the parameter list.

C11 atomics would have been much better if they'd standardised existing practice instead of inventing something based around the application centric design C++ was inventing. It's nice that there's an acquire/release scheme one can reason with but a real shame that they conflated it with type annotations.

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

#156

Post by yetihehe »

jamesdhutton wrote: post #121
yetihehe wrote: post #24

Earlier quoted context omitted.

Simple | Fast | Safe. Choose two.

Exactly this. It's all about trade-offs. You need to pick the right tool for the job. Sometimes the right tool is dangerous. Knives are dangerous tools, but you need them if you want to cook a meal.

I love one comparison to hole hawg[0] (used for unix vs windows&mac), which is usable here. Memory safe languages are like a fancy electric drill from target. They get the job done, but if you want some more serious drilling they die on you instead of doing something dangerous. C is like one of those drills which are comprised of engine and a handle (cheap, changeable piece of steel pipe). They are designed to do one thing: they rotate a drill. When drill blocks, they rotate you. But when you take appropriate precautions, boy do it drills...

This is from my favourite book: In the beginning was the command line.

[0] https://web.stanford.edu/class/cs81n/command.txt , search "HOLE HAWG".

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

#157

Post by SSLy »

nubinetwork wrote: post #154

> a vulnerability in HTTP parsing code that allows for heap corruption and arbitrary code execution by making a HTTP GET request with a megabyte of the letter 'A' in its body You mean a buffer overflow? Why write so technical then dumb down something that's pretty obvious.

buffers are stored on heap.

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

#158

Post by Supermancho »

fnordian_slip wrote: post #6

Just in case someone needs the reference, the onion uses '"no way to prevent this" says only nation where this regularly happens' as a reoccurring article at every major school shooting[0], to highlight the frequency of such events and the fact that nothing has really changed since the last one. [0] https://www.theonion.com/no-way-to-prevent-this-says-only-na...

The oversimplification is part of the joke.

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

#159

Post by GoblinSlayer »

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…

It's possible to write systematically safe code in C, no need to change language. People really just don't want to do it.

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

#160

Post by pdimitar »

ngrilly wrote: post #148
pdimitar wrote: post #88

Earlier quoted context omitted.

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.

And I agree on that. My favorite Elixir's runtime (Erlang's BEAM VM) still has some subtle problems with holding on to big(ger) binaries (strings) that requires very specific code be written at the green thread boundaries and it can get pretty maddening if you don't get it right -- which is not easy.

Golang I hear is doing much better btw. But you still have to be wary of its footguns i.e. leaking goroutines.

Post reply on HN