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

In-Memory C++ Leap in Blockchain Analysis

caudena.com

Post reply on HN
Print view View original

51–60 of 72 posts

Re: In-Memory C++ Leap in Blockchain Analysis

#51

Post by hexaga »

npalli wrote: post #41
wgjordan wrote: post #33

Earlier quoted context omitted.

> The memory issue will mostly be addressed as needed I have no allegiance to either lang ecosystem, but I think it's an overly optimistic take to consider memory safety a solved problem from a tweet about fil-c, especially considering "the performance cost is not negligible" (about 2x according to a quick search?)

Performance drop of 2x for memory safety critical sections vs Rust rewrite taking years/decades, not even a contest. Now, if that drop was 10x maybe, but at 2x it is no brainer to continue with C++. I'm not certain Fil-C totally works in all cases, but it is an example of how the ecosystem will evolve to solve this issue and not migrate to Rust.

What would you consider to be a non memory safety critical section? I tried to answer this and ended up in a chain of 'but wait, actually memory issues here would be similarly bad...', mainly because UB and friends tend to propagate and make local problems very non-local.

Re: In-Memory C++ Leap in Blockchain Analysis

#52

Post by kanbankaren »

wat10000 wrote: post #46
kanbankaren wrote: post #32

Earlier quoted context omitted.

Show me a memory issue that was caused by proper usage of POSIX concurrency primitives.

Any reasonable meaning of “proper” would include not causing memory issues, so you’ve just defined away any problems. Note that this is substantially different from not having any problems. The great lesson in software security of the past few decades is that you can’t just document “proper usage,” declare all other usage to be the programmer’s fault, and achieve anything close to secure software. You must have syste…

> And when was the last time you found a bug in C-family code caused by someone who didn’t correctly use concurrency primitives because the programmer incorrectly believed that a certain piece of mutable data would only be accessed on a single thread? I’ll give you my answer: it was yesterday.

You answered my question. My original argument was using concurrency primitives "properly" in C++ prevents memory issues and Rust isn't strictly necessary.

I have nothing against Rust. I will use it when they freeze the language and publish a ISO spec and multiple compilers are available.

Re: In-Memory C++ Leap in Blockchain Analysis

#54

Post by bobmcnamara »

kanbankaren wrote: post #32
CharlesW wrote: post #29

Earlier quoted context omitted.

> With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. There is a mountain of evidence (two examples follow) that this is not true. Roughly two-thirds of serious security bugs in large C++ products are still memory-safety violations. (1) https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-syst... (2) https://www.chromium.org/Home/chromium-security/memory-s…

Show me a memory issue that was caused by proper usage of POSIX concurrency primitives.

dozens caused by folks thinking pthread_cancel() was the right tool for the job

Re: In-Memory C++ Leap in Blockchain Analysis

#56

Post by seviu »

newswasboring wrote: post #48
seviu wrote: post #36

Earlier quoted context omitted.

Cadena post above yours mentioned quite a few use successful cases, all built on top of Ethereum or copy cats (Ethereum is by itself a successful use case) Without thinking too hard, Aave is shaping to be a giant by its own as lending protocol. Circle recently had a very successful IPO. Farcaster and Lens are attempting to compete as social network platforms (surprisingly they lack much of the toxicity that comes on…

All of these are at best nice prospects and most of these are just services which are only useful if the space itself is useful. I'm sorry but I'm not convinced of utility by layers upon layers of "successful" protocols.

I wouldn’t call polymarket a nice prospect though.

Re: In-Memory C++ Leap in Blockchain Analysis

#58

Post by FpUser »

CharlesW wrote: post #29
kanbankaren wrote: post #20

Earlier quoted context omitted.

What is wrong with C++? With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. Source: Writing code in C/C++ for 30 years.

> With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. There is a mountain of evidence (two examples follow) that this is not true. Roughly two-thirds of serious security bugs in large C++ products are still memory-safety violations. (1) https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-syst... (2) https://www.chromium.org/Home/chromium-security/memory-s…

I write high performance backends in C++. Works approximately as described in article and all data are in RAM and in structures specialized for access patterns. Works like a charm and runs 24x7 without a trace of problem.

I've never had a single complaint from my customers. Well I do have bugs in logic during development but those are found and eliminated after testing. And every new backend I do I base on already battle tested C++ foundation code. Why FFS would I ever want to change it (rewrite in Rust). As a language Rust has way less features that I am accustomed to use and this safety of Rust does not provide me any business benefits. It is quite the opposite. I would just lose time, money and still have those same logical bugs to iron out.

Re: In-Memory C++ Leap in Blockchain Analysis

#59

Post by acdha »

FpUser wrote: post #58
CharlesW wrote: post #29

Earlier quoted context omitted.

> With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. There is a mountain of evidence (two examples follow) that this is not true. Roughly two-thirds of serious security bugs in large C++ products are still memory-safety violations. (1) https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-syst... (2) https://www.chromium.org/Home/chromium-security/memory-s…

I write high performance backends in C++. Works approximately as described in article and all data are in RAM and in structures specialized for access patterns. Works like a charm and runs 24x7 without a trace of problem. I've never had a single complaint from my customers. Well I do have bugs in logic during development but those are found and eliminated after testing. And every new backend I do I base on already ba…

How many other programmers have you trained up to that level of results? Can you get them to work on Windows, Chrome, etc. so users stop getting exposed to bugs which are common in C-like languages but not memory-safe languages?

Re: In-Memory C++ Leap in Blockchain Analysis

#60

Post by FpUser »

acdha wrote: post #59
FpUser wrote: post #58

Earlier quoted context omitted.

I write high performance backends in C++. Works approximately as described in article and all data are in RAM and in structures specialized for access patterns. Works like a charm and runs 24x7 without a trace of problem. I've never had a single complaint from my customers. Well I do have bugs in logic during development but those are found and eliminated after testing. And every new backend I do I base on already ba…

How many other programmers have you trained up to that level of results? Can you get them to work on Windows, Chrome, etc. so users stop getting exposed to bugs which are common in C-like languages but not memory-safe languages?

I do not train programmers. I hire subcontractors when I need help. They're all same level as myself or better. Easy to find amongst East Europeans and does not cost much. Actually cheaper than some mediocre programmer from North America who can only program using single language / framework and has no clue about architecture and how various things work together in general.
Post reply on HN