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

171–180 of 342 posts

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

#171

Post by pjmlp »

yau8edq12i wrote: post #74
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 program MCUs as a hobby. I wish I could use something better than C. Even C++ with RAII would be better. But somehow, even C++ support is spotty, with unsupported features, broken debugging, etc. for seemingly no reason. And all device-specific libraries are written in C, so I'd have to write C++ wrappers for every little thing. Send help...

Mikroe is still in business selling Pascal and Basic compilers for all kinds of tiny CPU and MCUs since 1997, so some people do value their products.

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

#172

Post by aw1621107 »

Xeamek wrote: post #133
pdimitar wrote: post #99

Earlier quoted context omitted.

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?

Comment above, mentioned borrowing while structs instead of borrowing memory. I believe this was once discussed under term 'partial borrows', but the "idiomatic" aproach is to 'just split your structs'. Which isn't really a good aproach to structuring codebase, it's just to appeal to borrow checker inflexibility. Lack of global scope. Lack of function overloading.

> Lack of function overloading.

Isn't there at least some technical basis for this (less-than-ideal interactions with type inference IIRC)?

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

#173

Post by pjmlp »

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…

I would say until C++98, C++ used to be more opinated, one of the reasons many of us went with C++ when given the choice, wasn't OOP features, rather the security improvements over bare bones C, with compiler provider frameworks.

Then eventually C++ got invaded by C expatriates, and writing C with C++ compiler idioms increased instead of going away.

It is like giving Typescript to groups of folks that insist on using any all over the place.

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

#174

Post by marcyb5st »

jstimpfle wrote: post #84
marcyb5st wrote: post #50

Earlier quoted context omitted.

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.

Fair enough. But unsafe for kernel code I guess it's a necessary evil (that's why I didn't mention it).

However, I believe the being "opt-in" by explicitly marking sections unsafe is the way to go instead of having unsafe by default (which is the only way using C).

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

#175

Post by pdimitar »

pjmlp wrote: post #173
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 would say until C++98, C++ used to be more opinated, one of the reasons many of us went with C++ when given the choice, wasn't OOP features, rather the security improvements over bare bones C, with compiler provider frameworks. Then eventually C++ got invaded by C expatriates, and writing C with C++ compiler idioms increased instead of going away. It is like giving Typescript to groups of folks that insist on using…

Actually I have good-ish memories of the early `boost` (we're talking 2003 - 2006) and some of the `std::` libraries in C++. They got the job done fine and were not in the way. So yeah, agreed.

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

#176

Post by pdimitar »

flohofwoe wrote: post #118
pdimitar wrote: post #104

Earlier quoted context omitted.

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 "ru…

Well you can make OCaml and Rust look like dynamic typing as well by omitting type signatures and squeezing the type inference engine as much as you can but I was under the impression that you have more asked about something that is very relaxed in terms of upfront requirements and be able to tighten it up later?

That's why I claimed that no such language exists.

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

#177

Post by akoboldfrying »

Some of the HN discussion about whether "new projects in C should be allowed" is moot: Fluent Bit was imported into git in 2015 [0] (a few months before Rust's first public release), and may be considerably older than that for all I know.

I suppose incidents like this actually do give a reason to "rewrite it in Rust", when "it" is "widely deployed infrastructure written in C". OTOH, I'm sure there were plenty of non-memory-safety bugs introduced and later fixed over the years, and rewriting in Rust will recapitulate that subset of bugs.

[0] https://github.com/fluent/fluent-bit/commit/49269c5ec3c74411...

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

#178

Post by SpaceNugget »

flohofwoe wrote: post #118
pdimitar wrote: post #104

Earlier quoted context omitted.

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 "ru…

I'm not super familiar with Zig, but that appears to be the same as the rust function signature fn setData(pins: P, bus: B, data: u8) -> B;

in rust, the P and B are resolved at compile time, not at runtime. If you wanted dynamic dispatch the types would be Box

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

#179

Post by tialaramex »

amarant wrote: post #163
pdimitar wrote: post #149

Earlier quoted context omitted.

> It is actually insane how people is still unconvinced about sum types. Oh don't even get me started on this but I agree sooooo much. > No, more people should be using memory managed languages like Java and Golang. Well, I use both Golang and Rust depending on the need. We can have both, it's not an either-or.

I'm feeling my lack of academic training here, but I needed to make sure. When you say sum types, are you referring to enums, or is it a broader concept than that? The Wikipedia article was quite archaic but seemed to support my initial understanding that you're talking about enums. Are you talking about enums?

Rust's enum is a sum type. The enum in C is just integers (again) wearing a hat for some reason. This may not be obvious, but if my enum in C seemingly has three possible values it... doesn't, it actually has at least hundreds of possible values, but only three have names - it's just an integer in a hat.

A sum type is an idea from type arithmetic. Suppose we have two types A and B, and we want to produce a new type from those, the most common provision in languages is to let you make a product type, it has all the values of A multiplied by all the values of B, this may be available to you as a named tuple, perhaps named a "struct" or "class" in your preferred language.

But what if instead we added these types instead of multiplying them? The new type has the values of A plus the values of B ? That's a sum type.

Suppose I have three types which resemble booleans: mood (it's either happy or sad), size (huge or tiny) and activity (either sleeping or eating)

A sum type of these three would allow me to make a "brief" of a cat as one of the six values, either as its mood, its size or its activity. The cat brief can be sad, or sleeping, or tiny, but it cannot be sleeping and sad [in this model] any more than a cat's size could be both huge and tiny. There are 2 + 2 + 2 = six values of the brief type.

In contrast a product type, maybe lets call that "state" of the cat consists of separate values of each of the three constituents, so the state of a cat might be (sad, tiny, sleeping) or (happy, huge, eating) or any other combination. There are 2 * 2 * 2 = eight values of this state type.

Just as an arithmetic is kinda crap if it only has multiply but not add, a type system is kinda crap if it can't make sum types. Where complicated hard-to-get-right hacks are used (e.g. C++ std::variant) these are often unsatisfying both ergonomically and in terms of delivered functionality, so hence the desire to have actual sum types in the language.

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

#180

Post by isoprophlex »

Beretta_Vexee wrote: post #122
isoprophlex wrote: post #20

Maybe C programmers need some more thoughts and prayers at deployment time?

No, the only way to stop a bad dev with a strcpy() is a good dev with a strcpy().

C doesn't overflow and spill your memory contents, your RAM modules do!
Post reply on HN