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

A Rust shaped hole

mnvr.in

Post reply on HN
Print view View original

181–190 of 319 posts

Re: A Rust shaped hole

#181

Post by pjmlp »

tialaramex wrote: post #46
uecker wrote: post #20

It is a bit unclear to me why somebody who rejects C++ because "I once spent an entire year in the heaven of C++, walking around in a glorious daze of std::vector and RAII, before one day snapping out of it and realizing that I was just spawning complexity that is unrelated to the problem at hand." (which I can absolutely agree with!) is picking Rust from all options. If there is a language that can rival C++ in term…

I've seen this idea from a few people and I don't get it at all. Rust is certainly not the simplest language you'll run into, but C++ is incredibly baroque, they're not really comparable on this axis. One difference which is already important and I think will grow only more important over time is that Rust's Editions give it permission to go back and fix things, so it does - where in C++ it's like venturing into a ho…

Because of the type system, with its ML influence, two macro systems, the stuff on nightly that many folks enjoy using, having to rely on external crates for proper error handling and async/await features.

Additionally, given its ML influence, too many people enjoy doing Haskell level FP programming in Rust, which puts off those not yet skilled in the FP arts.

Also the borrow checker is the Rust version of Haskell burrito blogs with monads, it is hard to get how to design with it in mind, and when one gets it, it isn't that easy to explain to others still trying to figure it out.

Hence why from the outside people get this opinion over Rust.

Naturally those of us with experience in compilers, type systems theory and such, see it differently, we are at another level of understanding.

Re: A Rust shaped hole

#182

Post by pjmlp »

blub wrote: post #178
tialaramex wrote: post #46

Earlier quoted context omitted.

I've seen this idea from a few people and I don't get it at all. Rust is certainly not the simplest language you'll run into, but C++ is incredibly baroque, they're not really comparable on this axis. One difference which is already important and I think will grow only more important over time is that Rust's Editions give it permission to go back and fix things, so it does - where in C++ it's like venturing into a ho…

Because they’re both complicated languages, but for different reasons. Rust didn’t really solve memory safety, it just pushed all the complexity into the type system. If one was struggling with memory errors in C++ that’s nice. If one was using Java, that still sucks. Furthermore some programmers really like complicated languages like Rust, Haskell, etc others like straightforward languages like Go, Python, etc.

Go pushes the complexity into the programmer, that is how one ends with source code like Kubernetes, when the language doesn't provide all the tooling.

Python belongs to the complicated languages section, people that think Python is straightforward never bothered reading all the manuals, nor had to put up with all the breaking changes throughout its history, it wasn't only 2 => 3, that was the major event, every release breaks something, even if little.

Re: A Rust shaped hole

#183

Post by pjmlp »

Expurple wrote: post #148
adastra22 wrote: post #121

Earlier quoted context omitted.

C++ has editions too btw. C++11, C++14, C++17, etc. These are opt in and allowed to break compatibility, although that is very rarely done in practice.

> although that is very rarely done in practice. That's one difference. And the other important differences are: - Rust apps can depend on library "headers" written in other editions. That's the whole deal with editions! Breaking changes are local to your own code and don't fracture the ecosystem. - Rust has a built-in tool that automatically migrates your code to the next edition while preserving its behavior. In C+…

Not really, because the crates they depend on cannot expose APIs with semantic changes across versions.

Also it requires everything to be compiled with the same compiler, from source code.

There are tools available in some C++ compilers for migration like clang, note the difference between ISO languages with multiple implementations, and one driven by its reference compiler.

Re: A Rust shaped hole

#184

Post by pjmlp »

tialaramex wrote: post #149
adastra22 wrote: post #121

Earlier quoted context omitted.

C++ has editions too btw. C++11, C++14, C++17, etc. These are opt in and allowed to break compatibility, although that is very rarely done in practice.

C++ shipping new and slightly incompatible versions of the entire language every three years isn't Editions, there was a proposal to attempt Editions (under the name "Epochs") for C++ but it faced significant headwinds and was abandoned.

On the other hand, editions do less that what people think they actually do.

Re: A Rust shaped hole

#185

Post by pjmlp »

uecker wrote: post #64
AstralStorm wrote: post #56

Earlier quoted context omitted.

In personal experience, the much stronger and composite type model in Rust makes it easier to refactor. Adding features in particular is a breeze and automatically the compiler/language will track for you the places that use only old set of traits. Tooling is still newer though and needs polish. Generic handling is interesting at times and there are related missing features for that in the language, vis a vis special…

I am wondering about this. In C the nice thing is that you usually change things locally. A line of code does not depend on a million other things. I can't quite see how this works in Rust... At least in C++, template, overloading, etc. can make a single line depend on a lot of things.

Preprocessor enters the scene.

Then we have the functions that might be re-entrant or not, in the presence of signals, threads,...

Re: A Rust shaped hole

#186

Post by self_awareness »

I've seen this argument for years. "C is an easy language and it's easy to code review it.".

Maybe if you want to skip all the off-by-1 errors, double frees, overflows, underflows, wrong API usage, you don't need to maintain multiplatform build environment, and you don't support multiple architectures.

I mean, in this sense, assembly is even easier than C. Its syntax is trivial, and if that would be the only thing that matters, people should write assembly.

But they don't write assembly, because it's not the only thing that matters. So please stop considering C only in terms of easy syntax. Because syntax is the only thing that's easy in C.

Re: A Rust shaped hole

#187

Post by pjmlp »

materielle wrote: post #110
tines wrote: post #31

Earlier quoted context omitted.

The two are incomparable in both quality and quantity. The complexity of Rust comes from the fact that it's solving complex problems. The complexity of C++ comes from a poorly thought out design and backwards-compatibility. (Not to slight the standards committee; they are smart people, and did the best with what they had.) Anothere way of putting it is, if you didn't care about backwards-compatibility, you could grea…

The C++ standard committee is definitely smart. But language design requires sense beyond just being smart. They didn’t do the best with what they had. Sure, some problems were caused by C backwards compatibility. But so much of the complexity and silliness of the language was invented by the committee themselves.

As someone that really enjoys C++, I would say that the current issues are cause by lack of preview implementations before being voted into the standard, this is just broken, but there are not enough people around to be able to turn the ship around.

Those folks eventually move to something else and adopt "C++ the good parts" instead.

Re: A Rust shaped hole

#188

Post by pjmlp »

Expurple wrote: post #51
pron wrote: post #42

> And the very point of writing a native program in the first place is to make it feel solid. What does that mean, and what is it about native programs (i.e. programs AOT-compiled to machine code) that makes them feel solid? BTW, such programs are often more, not less, sensitive to OS changes. > realizing that I was just spawning complexity that is unrelated to the problem at hand Wait till you use Rust for a while,…

> such programs are often more, not less, sensitive to OS changes. You may be technically correct that they are more sensitive to the kernel interface changes. But the point is that native, static binaries depend only on the kernel interface, while the other programs also depend on the language runtime that's installed on that OS. Typical Python programs even depend on the libraries being installed separately (in sou…

Even C has a runtime, even if tiny one.

Re: A Rust shaped hole

#189

Post by Expurple »

delusional wrote: post #174
Expurple wrote: post #162

Earlier quoted context omitted.

> There's so many good high-level languages to choose from We have many popular high-level languages, but I disagree that they are good. Most of them are fragile piles of crap unsuitable for writing anything larger than a throwaway script. (In my subjective and biased assessment, which is hovewer based on professional experience)

That's an interesting opinion. Could you mention one that wasn't fragile? Just to get a sense of the shape of these classes.

They are all fragile for different reasons: dynamic typing (that always leaks through bolted-on type hints anyway), implementation inheritance, null, exceptions, uncontrolled mutation, abuse of reflection and downcasts, weak leaky interfaces that the compiler doesn't check, no help with issues in multithreaded code, insecure defaults, poor semver practices in the ecosystem, poor tooling, fragile runtime dependencies.

I use Rust. From what I've read, Swift seems better than the others, with Typescript and Go following closely. All four happen to be widely praised in this thread.

To clarify, I don't have "professional experience" with every popular language, including Swift and Typescript too.

Re: A Rust shaped hole

#190

Post by pjmlp »

JoelMcCracken wrote: post #34

Wow, a lot of stuff in here surprises me. C definitely can/does have spooky at a distance. Just share a pointer to a resource with something else and enjoy the spooky modifications. Changes are local as long as you program that way, but sometimes it can be a bit not-obvious that this is happening. regarding redefining functions, what could the author mean? using global function pointers that get redefined? otherwise…

When people say C is simple, besides everything that you point out, apparently they never learned anything beyond the classical K&R C book (ANSI/ISO C edition), and are stuck in a C89 mindset without any kind of compiler extensions.
Post reply on HN