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

Ask HN: What's the Deal with HN and Rust?

news.ycombinator.com

Post reply on HN
Print view View original

101–108 of 108 posts

Re: Ask HN: What's the Deal with HN and Rust?

#101

Post by cyber_kinetist »

jatone wrote: post #72
cyber_kinetist wrote: post #66

Earlier quoted context omitted.

For that I see it as a matter of tooling more than the language design: wasm is nicely integrated into cargo and is maintained far better than other choices. You can also compile C/C++ to WASM if you want (and the language semantics definitely allows for it, since it doesn't have a garbage collector), but you just really don't want to deal with CMake while doing so.

garbage collector isn't a limiting factor for wasm. my main issue with wasm is no standard interopt for primitive types. thankfully some sort of FFI is in the works from my understanding.

In theory yes, but in practice managed languages need native GC support because garbage collectors in WASM code are quite slow. There's a proposal in the works: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...

Re: Ask HN: What's the Deal with HN and Rust?

#103

Post by fargle »

PaulHoule wrote: post #96
fargle wrote: post #70

Earlier quoted context omitted.

> strcpy in C is Turing complete How so? You've made this claim twice ( https://news.ycombinator.com/item?id=27910640 ), but I can find nothing else to back this up. We know about C++ templates "accidentally" being discovered to be Turing complete, but I've never heard of strcpy() being so... while((*p++=*q++)); ... I'm not seeing it. Honest question, can you shed light on how this can be?

Strcpy is a good setup for a buffer overflow despite having to run a gauntlet of countermeasures to really pull it off in 2022.

Well, OK, but that isn't fair to say "C" or strcpy(). That's the implementation - so is it surprising that the common underlying implementation of "C" can be coerced into indeterminate or even Turing complete behavior?

It's fair to say that C allows unsafe calls. It's useless to point out that undefined-behavior and unsafe calls could result in Turing completeness. Strcpy() is not Turing complete - it doesn't automatically detect and protect against unsafe usages. That are evil.

Re: Ask HN: What's the Deal with HN and Rust?

#105

Post by PaulHoule »

chombier wrote: post #60
bArray wrote: post #46

Earlier quoted context omitted.

> 2 performance cost of a managed language like Java It can be a lot worse too. Java lacks the ability to have really compact data structures and can not lean in too much into the hardware acceleration without becoming incompatible. You can't exactly set `--fast-math`. Shame GCJ got dropped. > strcpy in C is Turing complete Not something I've heard of - is this an abuse of Unicode? > most code has to portable to at l…

> strcpy in C is Turing complete I was curious too, but my google-fu did not succeed. The closest I found is about printf being Turing-complete [1], which is also new to me. [1] https://www.ioccc.org/2020/carlini/index.html

It’s not the strcpy that’s Turing complete, it’s the return afterwards… this is not true about PASCAL and many other programming languages.

Re: Ask HN: What's the Deal with HN and Rust?

#106

Post by spicyusername »

bestouff wrote: post #76
skocznymroczny wrote: post #57

As someone who looks at Rust and other alternative languages every now and then. I think many C/C++ programmers are looking for an alternative. C/C++ accumulated a lot of legacy stuff over the years, and things like #includes, .h vs .cpp, non-trivial metaprogramming, limited IDE capabilities, no standarized package manager show how old these languages are. Compare it to Rust, which has one build tool/package manager.…

> 99% of projects I don't know where you got this figure from, but I highly doubt 1% of Rust projects use a different build/package system. More like 0.001% (this number is scientifically extracted from thin air).

99% in this context is an expression of speech.

OP doesn't literally mean 99%, they mean "almost everyone". The actual numerical value is irrelevant.

Re: Ask HN: What's the Deal with HN and Rust?

#107

Post by tored »

armchairhacker wrote: post #67

IMO C++ was and is still the leading language for writing performance-intensive and memory-intensive applications (excluding Rust), and C++ is really flawed. Like, I know that Java and JavaScript and Python get criticism, but the fact is those languages are still usable compared to C++: - There are several different ways to do everything and half of them are wrong. For example, you can define an unsigned int type wit…

C++ is also hard to read, especially after introducing lambdas.

Re: Ask HN: What's the Deal with HN and Rust?

#108

Post by stephc_int13 »

Gwypaas wrote: post #51
stephc_int13 wrote: post #48

Rust might be a better C++. (Zig is the better C) The memory safety thing seems to be appealing to some people who believe it will dramatically reduce the security issues found in many software. (they usually know very little about actual security exploits) Rust is building a cult-like community around it, and I think it could be its demise, I personally hate it (the community)

> The Chromium project finds that around 70% of our serious security bugs are memory safety problems. Our next major project is to prevent such bugs at source. https://www.chromium.org/Home/chromium-security/memory-safet... > As was pointed out in our previous post, the root cause of approximately 70% of security vulnerabilities that Microsoft fixes and assigns a CVE (Common Vulnerabilities and Exposures) are due to…

I took a look at the Chromium codebase a long time ago, out of curiosity. I am not surprised it is full of bugs and vulnerabilities, and yes modern C++ idioms are harmful in that regard.

But I am not convinced that Rust is the solution.

Post reply on HN