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

241–250 of 319 posts

Re: A Rust shaped hole

#241

Post by [deleted] »

jcranmer wrote: post #118
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…

Having developed a fair amount of expertise with both C++ and Rust, C++ is on a completely different level of complexity from Rust. In Rust, for most users, the main source of complexity is struggling with the borrow checker, especially because you're likely to go through a phase where you're yelling at the borrow checker for complaining that your code violates lifetime rules when it clearly doesn't (only to work it…

[deleted]

Re: A Rust shaped hole

#242

Post by blu3h4t »

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…

Why would everyone call rust a c+++ whet it is obviously an ocaml erlang hybrid :D

Re: A Rust shaped hole

#243

Post by ReaperCub »

pjmlp wrote: post #182
blub wrote: post #178

Earlier quoted context omitted.

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 rele…

> 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.

I am not sure what you mean by this. I write go code pretty much everyday and that code looks vaguely the same as it would do in C#, or Python, or JavaScript.

> 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.

I've read the manuals. Most docs appear to be reasonably well written, even if I find many of the examples a bit odd (I've never been a big fan of Monty Python, so the spam and eggs examples are all a bit odd).

The 2 => 3 change was probably a big thing for those migrating all the existing libraries, frameworks. But as someone that uses it for prototyping stuff, I barely noticed the difference.

Re: A Rust shaped hole

#244

Post by LoganDark »

AlotOfReading wrote: post #112
LoganDark wrote: post #103

Earlier quoted context omitted.

> it a bit too idealistic and not pragmatic enough This is an ideal programming language for certain types of people. It also gives the programming language certain properties that make it useful when provable correctness is a concern (see Ferrocene).

Last time I talked to the ferrocene people they had no plans to do anything with formal methods. Has their scope expanded?

Sorry, I didn't mean provable correctness as in using formal methods, I meant it in terms of far stronger compiler guarantees about especially things such as memory safety. I also personally find Rust code far more pleasant to write and to reason about compared to C/C++ because of how well-defined and consistent it is.

Re: A Rust shaped hole

#245

Post by d--b »

> That leaves me with the following options — C, C++, Go, Rust.

> Technically, there are a lot more options, and I wrote a long section here about eliminating them piecewise, but after writing it I felt like it was just noise.

Uh? I am guessing OP doesn't like virtual machines maybe, cause Java and C# sound like something that fits what they want. Both support AoT compilation though now...

Also the assumption about Typescript to Wasm being not "solid" seems wrong.

I mean I find it super weird that the author's only option for "native typescript" is Rust.

Re: A Rust shaped hole

#246

Post by nlitened »

> To paraphrase Norvig's Latency numbers a programmer should know, if we imagine a computer that executes 1 CPU instruction every second, it would take it _days_ to read from RAM.

I think the author probably misread the numbers. If CPU executed 1 instruction every second, it would take just 1—2 minutes to read from uncached RAM, no need to be overly dramatic.

Overall, this reads to me like a very young programmer trying to convince themselves to learn Rust because he heard it's cool, not an objective evaluation. And I'm totally on board with that, whatever convinces you, just learn new things!

Re: A Rust shaped hole

#247

Post by pjmlp »

Expurple wrote: post #237
pjmlp wrote: post #234

Earlier quoted context omitted.

4 editions later, Rust is yet to be used at the scale of C and C++ across the industry, my point on the comment is how editions will look like after 50 years of Rust history. ABIs and multiple versions of the language runtime, are part of what defines a language ecosystem, hence why editions don't really cover as much as people think they do.

Editions will look like band-aids that don't fully solve the cruft accumulated over the 50 years. That's not hard to predict. It's still a very useful mechanism that slows down the accumulation of said cruft. I'm yet to see a language that has a better stability/evolution story

In any case, while I as language geek have these kind of discussions, given current progress in AI systems, my point of view is that we will get the next evolution in programming systems, thus it won't matter much if it is C, C++, Rust, C#, Java, Go or whatever.

We (as in the industry) will eventually get reliable ways to generate applications directly to machine code, just as optimizing compilers took a couple of decades to beat hand written Assembly, and generate reliable optimized code.

So editions, regardless of what they offer, might not be as relevant in such a timeframe from a couple of decades ahead.

Re: A Rust shaped hole

#248

Post by tialaramex »

whytevuhuni wrote: post #236
borkido wrote: post #228

Earlier quoted context omitted.

What would the benefit be of not associating functions that operate on a struct with said struct? You would just end up with a bunch of functions that take a struct of that type as their first argument.

> You would just end up with a bunch of functions that take a struct of that type as their first argument. I don't see that as a necessarily bad thing, it brings uniformity with the rest of the functions. I've coded with libraries like APR, Nginx's API, and GTK's GLib, and the result looks quite aesthetically pleasing too (subjective of course). I'm also not considering this as a deal-breaker or anything. The point i…

Unlike C++ all Rust's methods already can be used this way

    '5'.is_digit(10) // Is literally the same as
    char::is_digit('5', 10) // this
Basically all a "method" is in Rust is an associated function where the first parameter has the magic keyword self instead of needing a real name and type.

Rust even has guidelines recommending you consider e.g. &self rather than having an associated function whose first argument has type &Self, but noting that you should not do this if your type has "smart pointer" behaviour where users expect to call methods on the inner value instead. For example Box and Arc provide associated functions but not methods.

Re: A Rust shaped hole

#249

Post by WD-42 »

eMSF wrote: post #224
tialaramex wrote: post #154

Earlier quoted context omitted.

This is a case of exactly the "hoarder" modality in C++ that I described. When somebody says array in C++ you think of std::array, the newer shiny C++ class which you're asked to use instead of the native array types. The native array types in C++ still exist and indeed do not provide methods like size() In Rust the arrays aren't stunted left over primitive types which weren't gifted modern features, array.len() work…

While it is true that only class types have member functions in C++, that does not mean that objects of other types demand the use of macros. C++ also supports non-member functions, and the standard library contains a fair amount of these; including `std::size` that can be used to "get" the length of an array. (C++ arrays are different from arrays in many other programming languages, though not necessarily Rust, in t…

Ah, std::size, since c++17. No wonder nobody knows about it, that’s after we all started switching to rust.

Re: A Rust shaped hole

#250

Post by tines »

anon-3988 wrote: post #123
tines wrote: post #44

Earlier quoted context omitted.

Can you give some examples of Rust and C++ design that are over engineered?

For C++ specifically, constructors. Just have functions for gods sake.

The question was mainly meant to elicit examples for Rust (I asked about C++ just to get a baseline of what the original commenter thinks "overengineered" means), but nobody seems to have any for Rust :)
Post reply on HN