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

Matt Godbolt sold me on Rust by showing me C++

collabora.com

Post reply on HN
Print view View original

651–660 of 675 posts

Re: Matt Godbolt sold me on Rust by showing me C++

#651

Post by [deleted] »

aw1621107 wrote: post #340
Ygg2 wrote: post #305

Earlier quoted context omitted.

> there's also a whole other argument that the hardware is unsafe so all Rust code will depend on unsafe somewhere or another to run on actual hardware, but that's probably getting a bit into the weeds. That's not going into the weeds, by that logic (Nirvana fallacy) no language is safe, you're going to die, so why bother about anything? Just lie down and wait for bugs to eat you.

Perhaps I got the quip wrong. I was basically trying to reference discussions I've seen elsewhere along the lines of "Rust is not actually memory-safe because it needs unsafe", sometimes followed by the argument you outlined. Those discussions can get a bit involved and I don't think this is a good time/place for them, so I more or less just wanted to reference it without spending much time/words on actually delving…

[deleted]

Re: Matt Godbolt sold me on Rust by showing me C++

#652

Post by foobahhhhh »

rowanG077 wrote: post #645
pjmlp wrote: post #598

Earlier quoted context omitted.

Software developers no, but Software Engineering does, it is a professional title in many countries, where universities and engineers are only legally allowed to use such titles after being validated.

I really don't think this matters. It's the processes beyond physical engineering that make it better. I have seen the most highly accredited software devs write the worst code. I have seen self-taught devs deeply consider implication of the things they are writing and solve the problem simply. And it's not even the case that I can perceive a trend. Well except for PhDs, I have met only one PhD that I know can write…

I think if PhDs are bad at code it is because they ain't coding in a team 7.6 hours a day. It is not the PhDness rather than not being a coder. (Sone PhDs might code a lot as a hobby and be good).

You can also write a medical PhD without knowing how to do first aid on a snake bite.

Re: Matt Godbolt sold me on Rust by showing me C++

#653

Post by throw10920 »

ttfkam wrote: post #643
throw10920 wrote: post #639

Earlier quoted context omitted.

I don't need to define "good code" for my argument. You're not a person capable of using logic, apparently. As is characteristic of Rust zealots.

> When I say "it doesn't work" I mean that it doesn't allow you to write good code But you skipped over how you are defining, "good code"? Without that part, "doesn't allow" cannot be evaluated in the context of Java or C++ or Python or Go or Rust. Logic.

Apparently you have difficulty with reading comprehension, because my original comment already defines "good code":

> The result type does not work because you have to choose between immediate callers handling failures (they don't always have the context to do so because they're not aware of the context of callers higher up on the call stack) or between propagating all of your error values all the way up the stack to the error handling point and making your program fantastically brittle and insanely hard to refactor.

It's interactions like this that are the reason why my organization isn't adopting Rust.

Re: Matt Godbolt sold me on Rust by showing me C++

#654

Post by sn9 »

int_19h wrote: post #571
sn9 wrote: post #522

Earlier quoted context omitted.

Can I interest you in some Moonbit? https://www.moonbitlang.com/blog/first-announce

With any new language, the first question one has to ask is, "what are the guarantees that it'll still be around in 5 years?".

Always true, but they've made a remarkable amount of progress since the language was announced, and have some experienced people leading the project.

Re: Matt Godbolt sold me on Rust by showing me C++

#655

Post by xarope »

kstrauser wrote: post #515
xarope wrote: post #258

This reminds me of SQL's constraints, or pydantic's custom types and validators, which can validate that a value should be an int, and between 0-999, and not exceed, e.g. -1 or 1000. pydantic is a library for python, but I'm not aware of anything similar in rust or golang that can do this yet? (i.e. not just schema validation, but value range validation too)

The semantics are a little different in that you have to explicitly call .validate(), but Rust's "validator" crate[0] feels a lot like Pydantic to me. [0] https://docs.rs/validator/latest/validator/

I'm aware of this as well as go(lang)'s https://github.com/go-playground/validator, so you are right, I'm wondering about a more implicit validator like what Pydantic does when a value is assigned, versus an explicit call to validate().

Re: Matt Godbolt sold me on Rust by showing me C++

#656

Post by nextaccountic »

throw10920 wrote: post #583
dvratil wrote: post #8

The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions, functions returning bool, functions returning 0 on success, functions returning 0 on error, functions returning -1 on error, functions returning negative errno on error, functions taking optional pointer to bool to indicate error (optionally), functions taking r…

The result type is obviously insufficient for writing nontrivial programs, because nontrivial programs fail in nontrivial ways that need exceptional control flow. The result type does not work because you have to choose between immediate callers handling failures (they don't always have the context to do so because they're not aware of the context of callers higher up on the call stack) or between propagating all of…

You can inspect error values in Rust, handle some errors, and bubble up others, with an ordinary match statement.

Exactly like try catch

Re: Matt Godbolt sold me on Rust by showing me C++

#657

Post by mathw »

kanbankaren wrote: post #185
thrwyexecbrain wrote: post #132

The C++ code I write these days is actually pretty similar to Rust: everything is explicit, lots of strong types, very simple and clear lifetimes (arenas, pools), non-owning handles instead of pointers. The only difference in practice is that the build systems are different and that the Rust compiler is more helpful (both in catching bugs and reporting errors). Neither a huge deal if you have a proper build and testi…

The C++ code I wrote 20 years ago also had strong typing and clear lifetimes. Modern C++ has reduced a lot of typing through type inference, but otherwise the language is still strongly typed and essentially the same.

Foundationally though C++ still allows a lot of implicit casts that can and will shoot you in the foot.

You CAN write nice modern code in C++, but the ability to force yourself and all your colleagues to do so in perpetuity isn't really there yet.

Although it might be in the future, which would be nice.

Re: Matt Godbolt sold me on Rust by showing me C++

#658

Post by simonask »

bluGill wrote: post #613
simonask wrote: post #594

Earlier quoted context omitted.

I don't think it's a defect of the language that your particular circumstance makes it infeasible to port your project. Having a great C++ interop story would be amazing, but Rust would be decidedly less awesome if it had made concessions in that direction early on. There's a lot of warts here, particularly around the fact that all Rust types are "trivially relocatable" in C++ parlance. At the same time, figuring out…

I didn't say it was a defect. I said it made rust inferior for me. Those are different things. I don't disagree with rust reasons for making that tradeoff - but the tradeoff as a result makes rust useless for now, for me. If it works for you great.

I think the term "inferior" isn't really appropriate, then. It typically applies to the quality of the thing on its own, not its applicability outside of its stated scope.

Re: Matt Godbolt sold me on Rust by showing me C++

#659

Post by _flux »

Ygg2 wrote: post #150
jsat wrote: post #64

Earlier quoted context omitted.

Had the same thought... It's backwards that any language isn't using named parameters at this point.

Named parameters do come with a large footgun. Renaming your parameters is a breaking change. Especially if you're coming from different langs.

E.g. OCaml has the ability to separate argument name and variable name for named arguments: let foo ~argument:variable = variable + variable

In fact, I think OCaml has one of the best labeled argument system around there. The only downside is that it doesn't always interact well with currying, but perhaps languages without currying could just copy all the rest.

Just to elaborate a bit, in OCaml you can have functions like:

    let foo ~a ?b c =
      let b = match b with
        | None -> 42
        | Some x -> x
      in a + b + c
And you can then call this like foo ~a:1 ~b:42 55 or foo ~a:2 ?b:None 55. But then forwarding those optional parameters works like:

    let bar ~a ?b c =
      foo ~a ?b c
and the optional parameter b will be forwarded as an optional parameter.

Given Rust's historical relations with OCaml I'm slightly disappointed that it doesn't have the same labeled and optional argument system.

Re: Matt Godbolt sold me on Rust by showing me C++

#660

Post by ttfkam »

throw10920 wrote: post #653
ttfkam wrote: post #643

Earlier quoted context omitted.

> When I say "it doesn't work" I mean that it doesn't allow you to write good code But you skipped over how you are defining, "good code"? Without that part, "doesn't allow" cannot be evaluated in the context of Java or C++ or Python or Go or Rust. Logic.

Apparently you have difficulty with reading comprehension, because my original comment already defines "good code": > The result type does not work because you have to choose between immediate callers handling failures (they don't always have the context to do so because they're not aware of the context of callers higher up on the call stack) or between propagating all of your error values all the way up the stack to…

Defined good code TO YOU. You've failed to recognize there is no objective and universally recognized metric for good code within our industry. The closest thing we have to it is number of defects per line of code and how severe those defects are through CVEs. That's it.

You've mistaken your personal preferences and aesthetic sense for absolute truth.

The arrogance is astounding.

Post reply on HN