News for hackers. Stuff that matters.
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by pjmlp on Tuesday June 25, 2024 @03:21AM (#40785474)
I would consider that serious attempts have been made since 1961, however all of them failed in the presence of a free beer OS, with free beer unsafe compilers.

The getting traction part is the relevance part.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by quectophoton on Tuesday June 25, 2024 @10:19AM (#40788984)
Yeah, all previous attempts at making such a language lacked two things:

1. They didn't have a big, well-known, company name with good enough reputation to attract contributors.

2. They didn't have brackets.

Success was because traction, traction was because appeal, and appeal was mostly because those two things. Nothing else was new AFAIK.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by yosefk on Tuesday June 25, 2024 @02:02PM (#40791549)
No shared mutable state in an imperative language is common, as are memory safe languages with performance close to C's? Didn't see the latter in the language shootout benchmarks, in fact Rust is much closer to C than the next closest thing
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by steveklabnik on Tuesday June 25, 2024 @02:12PM (#40791652)
I take a slightly different view of this, though I do not deny that those things are important. #1 in particular was important to my early involvement in Rust, though I had also tinkered with several other "C replacement" languages in the past.

A lot of them simply assumed that some amount of "overhead," vaguely described, was acceptable to the target audience. Either tracing GC or reference counting. "but we're kinda close to C performance" was a thing that was said, but wasn't really actually true. Or rather, it was true in a different sense: as computers got faster, more application domains could deal with some overhead, and so the true domain of "low level programming languages" shrunk. And so finally, Rust came along, being able to tackle the true "last mile" for memory unsafety.

Rust even almost missed the boat on this up until as late as one year before Rust 1.0! We would have gotten closer than most if RFC 230 hadn't landed, but in retrospect this decision was absolutely pivotal for Rust to rise to the degree that it has.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by pjmlp on Wednesday June 26, 2024 @02:36AM (#40797029)
That wasn't the case of Modula-2, Ada or Object Pascal.

Their problems was a mix of not being hieroglyph languages (too much text to type!), being much strongly typed (straitjacket programming with a famous rant post, wrongly), commercial offerings being expensive (more so against free in the box alternative), and not comming with an OS to make their use unavoidable.

Note that for all the hype, Zig is basically Modula-2 features with C syntax, to certain extent.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by steveklabnik on Wednesday June 26, 2024 @12:30PM (#40801747)
> not comming with an OS to make their use unavoidable.

Early MacOS did use Pascal, though IIRC not Object Pascal.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by another2another on Friday June 28, 2024 @10:21AM (#40820866)
You can still find documentation for Macos toolkit with Pascal bindings.

This is a bit of a nostalgia trip for me as I owned a copy of this book way back in the 90's

https://developer.apple.com/library/archive/documentation/ma...