Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Time safety is more important than memory safety

halestrom.net

Post reply on HN
Print view View original

91–100 of 111 posts

Re: Time safety is more important than memory safety

#91

Post by dang »

safercplusplus wrote: post #44

If you're planning that far ahead it may not be an either-or situation. That is, in the future C/C++ may also have an enforced memory safe subset. In which case the issue becomes, how do you write your code today so that it will conform to the safe subset? There are conformance tools in the works that can already give you a sense of the restrictions that will be imposed [1]. [1] https://github.com/duneroadrunner/scpp…

Please don't use promotional accounts on HN. We're here for curious conversation, not promotion. I appreciate that you've been posting these links in threads where they're mostly relevant, as opposed to blanket-spamming the site, but it's still not in the spirit of HN to have single-purpose accounts or to use this place primarily for promotion. It's ok to post your own work occasionally, as long as it's part of a diverse mix of posts that are motivated primarily by intellectual curiosity. That's the value we're optimizing for here.

https://news.ycombinator.com/newsguidelines.html

Re: Time safety is more important than memory safety

#92

Post by downerending »

safety-third wrote: post #30

I actually have had the pleasure of porting a program from a defunct 16-bit language called Actor to C++. It wasn't a huge deal even at around 800 kLOC. All mainstream languages in the future are going to have some combination of structured, functional, and object-oriented programming. Converting is mostly going to be about syntax and libraries. As someone who has worked with C and C++ for living for over 20 years, I…

Rust is interesting and clever, but it will not see widespread use, for pretty much the same reason that Haskell won't: It's simply too complex for Joe Coder to deal with.

C++ is likewise quite complex, but it has the huge advantage that a team of mediocre programmers can largely just keep to a simple subset of the language and bumble along. With Rust, you must learn and deal with the memory model, and it's not an easy thing.

Re: Time safety is more important than memory safety

#93

Post by Quekid5 »

bvinc wrote: post #38
giornogiovanna wrote: post #14

Earlier quoted context omitted.

I thought this was going to be about bounding the time complexity of your algorithms; I don't know if any language does that yet. I suppose this title has a lot of interpretations.

My understanding is that automatically determining time complexity is impossible in the general case due to the halting problem. And getting a compiler to truly understand the time complexities of your data structures would involve either extremely difficult theorem proving or just forcing it. I do think it would still be interesting if a language had support for determining time complexity. It seems like it's often…

Another issue is that algorithmic complexity only really 'composes' in a trivial and uninteresting way: Ok, you have a for loop over N items, multiply the complexity of the loop body by N.

Well, no not quite... it may be the case that one particular iteration of the loop makes all the subsequent steps completely trivial, so O(1)... and even further it may be that such a step is guaranteed to be reached in log(M) time, etc. etc. You see this type of thing a log in graph algorithms where they look like they might be O(n^3) or whatever, but leaving markers on nodes can avoid a lot of repeated work (by skipping marked node), so they end up as O(n + k) or whatever.

Upper bounds for worst case complexity are relatively easy... just assume the worst, but the interesting thing is proving TIGHT bounds for worst case complexity.

Re: Time safety is more important than memory safety

#94

Post by wolf550e »

downerending wrote: post #92
safety-third wrote: post #30

I actually have had the pleasure of porting a program from a defunct 16-bit language called Actor to C++. It wasn't a huge deal even at around 800 kLOC. All mainstream languages in the future are going to have some combination of structured, functional, and object-oriented programming. Converting is mostly going to be about syntax and libraries. As someone who has worked with C and C++ for living for over 20 years, I…

Rust is interesting and clever, but it will not see widespread use, for pretty much the same reason that Haskell won't: It's simply too complex for Joe Coder to deal with. C++ is likewise quite complex, but it has the huge advantage that a team of mediocre programmers can largely just keep to a simple subset of the language and bumble along. With Rust, you must learn and deal with the memory model, and it's not an ea…

I think the conclusion is that C++ is too dangerous in the hands of non-experts.

Re: Time safety is more important than memory safety

#95

Post by downerending »

wolf550e wrote: post #94
downerending wrote: post #92

Earlier quoted context omitted.

Rust is interesting and clever, but it will not see widespread use, for pretty much the same reason that Haskell won't: It's simply too complex for Joe Coder to deal with. C++ is likewise quite complex, but it has the huge advantage that a team of mediocre programmers can largely just keep to a simple subset of the language and bumble along. With Rust, you must learn and deal with the memory model, and it's not an ea…

I think the conclusion is that C++ is too dangerous in the hands of non-experts.

As far as it goes, I agree, and I rarely recommend C++ as the right language for a project.

Nonetheless, on real-world projects, a team of average programmers can make reasonable headway in C++. They'll probably write a lot of dubious and buggy code and eventually slam into the complexity wall. In Rust, they'd slam into a wall almost immediately and very noticeably. Managers won't put up with that.

Re: Time safety is more important than memory safety

#96

Post by heavenlyblue »

cshenton wrote: post #67
heavenlyblue wrote: post #64

Earlier quoted context omitted.

“too new”. Would you say the same about he new Boeing plane, then - too?

The 737 max? Yeah probably.

However if 737 continued flying we would get more deaths rather than more fixes, wouldn’t we?

Age has got nothing to do with stability.

Re: Time safety is more important than memory safety

#97

Post by heavenlyblue »

downerending wrote: post #92
safety-third wrote: post #30

I actually have had the pleasure of porting a program from a defunct 16-bit language called Actor to C++. It wasn't a huge deal even at around 800 kLOC. All mainstream languages in the future are going to have some combination of structured, functional, and object-oriented programming. Converting is mostly going to be about syntax and libraries. As someone who has worked with C and C++ for living for over 20 years, I…

Rust is interesting and clever, but it will not see widespread use, for pretty much the same reason that Haskell won't: It's simply too complex for Joe Coder to deal with. C++ is likewise quite complex, but it has the huge advantage that a team of mediocre programmers can largely just keep to a simple subset of the language and bumble along. With Rust, you must learn and deal with the memory model, and it's not an ea…

There’s nothing complex about Rust memory model

Re: Time safety is more important than memory safety

#98

Post by pasabagi »

downerending wrote: post #95
wolf550e wrote: post #94

Earlier quoted context omitted.

I think the conclusion is that C++ is too dangerous in the hands of non-experts.

As far as it goes, I agree, and I rarely recommend C++ as the right language for a project. Nonetheless, on real-world projects, a team of average programmers can make reasonable headway in C++. They'll probably write a lot of dubious and buggy code and eventually slam into the complexity wall. In Rust, they'd slam into a wall almost immediately and very noticeably. Managers won't put up with that.

I've never really dug into C++, but I've written a little bit of C, and I feel it's generally easier to write a given program in Rust than it is in C.

I can see why Rust has its reputation for difficulty - the burrow checker is a new idea, and the unfamiliar is inherently dificult. However, I think once you've spend a modicum of time, it's a fairly straightforward language, simply because the compiler almost always tells you exactly what you're doing wrong.

I don't feel like it's a particularly ergonomic language, and it's certainly hard to read (very symbol dense), but I think it's easier to learn to appease the burrow checker than it is to debug your average C program, especially if you're the sort of person (I certainly am) that produces dubious and buggy code more days than not.

Re: Time safety is more important than memory safety

#99

Post by rthille »

joshuamorton wrote: post #29
tpmx wrote: post #10

Earlier quoted context omitted.

That was before storage become abundant and cheap; from a source code storage perspective. It will not become more expensive. Nowadays storage capacity is developed to store video - this is really the only thing that needs a lot of new storage capacity. Every line of sourcecode written by every programmer ever is a fart in the wind compared to what's being uploaded to Youtube in the next 60 seconds.

Which does nothing to address "it works on my machine" build related issues. And more modern languages have much more robust solutions to hermetic build and package management.

That's what docker images are for :-)

Re: Time safety is more important than memory safety

#100

Post by downerending »

pasabagi wrote: post #98
downerending wrote: post #95

Earlier quoted context omitted.

As far as it goes, I agree, and I rarely recommend C++ as the right language for a project. Nonetheless, on real-world projects, a team of average programmers can make reasonable headway in C++. They'll probably write a lot of dubious and buggy code and eventually slam into the complexity wall. In Rust, they'd slam into a wall almost immediately and very noticeably. Managers won't put up with that.

I've never really dug into C++, but I've written a little bit of C, and I feel it's generally easier to write a given program in Rust than it is in C. I can see why Rust has its reputation for difficulty - the burrow checker is a new idea, and the unfamiliar is inherently dificult. However, I think once you've spend a modicum of time, it's a fairly straightforward language, simply because the compiler almost always t…

That may be, but debugging "looks like work" in the eyes of mgmt.

The borrow checker, on the other hand, looks more like "I can't find any applicants in Little Rock who can do this stuff.".

Post reply on HN