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

571–580 of 675 posts

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

#571

Post by int_19h »

sn9 wrote: post #522
bunderbunder wrote: post #488

Earlier quoted context omitted.

It's close. Perhaps there's an interesting conversation to be had about why OCaml hasn't taken over the world the way Rust has. The toolchain might be a first candidate. Rust's toolchain feels so very modern, and OCaml's gives me flashbacks to late nights trying to get my homework done on the department's HP-UX server back in college.

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

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

#572

Post by int_19h »

bunderbunder wrote: post #477

This is actually the point where Rust starts to frustrate me a little bit. Not because Rust is doing anything wrong here, but because the first well-known language to really get some of these things right also happens to be a fairly low-level systems language with manual memory management. A lot of my colleagues seem to primarily be falling in love with Rust because it's doing a good job at some basic things that hav…

Well, Rust is specifically targeting the "C++ and thereabouts" bucket, so they need the borrow checker to make all those nifty abstractions zero-cost or nearly so.

If that's not the goal and you really are perfectly fine with GC, then the baseline wouldn't be C++ but rather e.g. C# and Java. At which point you'd look at F# and Kotlin. Or even C# itself, which has been acquiring more and more FP-like languages over the years.

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

#573

Post by bionhoward »

J_Shelby_J wrote: post #498
bionhoward wrote: post #434

Earlier quoted context omitted.

This is already a thing, I do this right now. You configure the linter to forbid panics, unwraps, and even arithmetic side effects at compile time. You can configure your lints in your workspace-level Cargo.toml (the folder of crates) “”” [workspace.lints.clippy] pedantic = { level = "warn", priority = -1 } # arithmetic_side_effects = "deny" unwrap_used = "deny" expect_used = "deny" panic = "deny" “”” then in your cr…

But can deny the use of all operations that might panic like indexing an array?

Yes, looks like you can, try indexing_slicing

https://rust-lang.github.io/rust-clippy/master/#indexing_sli...

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

#574

Post by bionhoward »

aaronmdjones wrote: post #452
bionhoward wrote: post #434

Earlier quoted context omitted.

This is already a thing, I do this right now. You configure the linter to forbid panics, unwraps, and even arithmetic side effects at compile time. You can configure your lints in your workspace-level Cargo.toml (the folder of crates) “”” [workspace.lints.clippy] pedantic = { level = "warn", priority = -1 } # arithmetic_side_effects = "deny" unwrap_used = "deny" expect_used = "deny" panic = "deny" “”” then in your cr…

Indent by 4 spaces to get code blocks on HN. Like this

  Thank
  you

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

#575

Post by int_19h »

karel-3d wrote: post #321

Well, if you don't want to confuse parameters, you should use Objective-C. You would do [orderbook sendOrderWithSymbol:"foo" buy:true quantity:100 price:1000.00] Cannot confuse that! (I never used swift, I think it retains this?)

Swift does retain this, but it makes it look much more readable. The example above would be something like:

  orderbook.sendOrder(symbol: "foo", buy: true, quantity: 100, price: 1000.00);
It also has a nifty syntax for function declarations to allow decoupling the keyword from the variable name when that leads to more readable code:

  func parseInt(from s: String) -> Int {
    /* the variable is named 's' here */
  }

  parseInt(from: "123")

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

#576

Post by int_19h »

monkeyelite wrote: post #363
bsder wrote: post #192

Earlier quoted context omitted.

> When there are 3-4 parameters it is too much trouble to write the names. Sorry, I don't agree. First, code is read far more often than written. The few seconds it takes to type out the arguments are paid again and again each time you have to read it. Second, this is one of the few things that autocomplete is really good at. Third, almost everybody configures their IDE to display the names anyway . So, you might as…

Making something longer doesn’t make it easier to read, especially in repetition.

Making something explicit does.

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

#577

Post by kragen »

Ygg2 wrote: post #459
kragen wrote: post #457

Earlier quoted context omitted.

I'd like to read the other sides of the story; do you have any recommendations? On the surface it sounds like a community with such deep pathology that it will take at least a generation following a complete change of leadership to have a chance at recovery. But there are three sides to every story.

I think the best summary is this: https://fasterthanli.me/articles/the-rustconf-keynote-fiasco... > On the surface it sounds like a community with such deep pathology First what sort of pathology? You're confusing community with leadership. The community didn't want this, and leadership was doing a restructuring due to change from Foundation and Project. Welcome to OSS projects. Second as opposed to what? A community…

Thank you!

I can try to answer your questions if they are important to you, but it will require some significant effort, so I'd like to be sure they aren't rhetorical first.

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

#578

Post by int_19h »

bsder wrote: post #192
codedokode wrote: post #110

Earlier quoted context omitted.

When there are 3-4 parameters it is too much trouble to write the names.

> When there are 3-4 parameters it is too much trouble to write the names. Sorry, I don't agree. First, code is read far more often than written. The few seconds it takes to type out the arguments are paid again and again each time you have to read it. Second, this is one of the few things that autocomplete is really good at. Third, almost everybody configures their IDE to display the names anyway . So, you might as…

They aren't even necessarily redundant. If you have argument names as part of the function name, they can be overloaded on - and this is much more readable than type-based overloading because it's all explicit. Swift uses this to great effect, e.g. here are some different ways to construct a string:

   String(repeating: "foo", count: 42);

   String(cString: zeroTerminatedBuffer); 

   String(42, radix: 16);

   String(contentsOfFile: "foo.txt", encoding: .utf8);

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

#579

Post by int_19h »

pdimitar wrote: post #561
int_19h wrote: post #560

Earlier quoted context omitted.

So what do you do in the error branch if something like out-of-bounds index happens? Wrap and propagate the error to the caller?

Usually yes. But I lean much more to writing library-like code, I admit. When I have to make a decision on an app-level, it becomes a different game though. I don't have a clear-and-cut answer for that.

This implies that every function in your library that ever has to do anything that might error out - e.g. integer arithmetic or array indexing - has to be declared as returning the corresponding Result to propagate the error. Which means that you are now imposing this requirement (to check for internal logic bugs in library code) onto the user of your library.

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

#580

Post by pdimitar »

int_19h wrote: post #579
pdimitar wrote: post #561

Earlier quoted context omitted.

Usually yes. But I lean much more to writing library-like code, I admit. When I have to make a decision on an app-level, it becomes a different game though. I don't have a clear-and-cut answer for that.

This implies that every function in your library that ever has to do anything that might error out - e.g. integer arithmetic or array indexing - has to be declared as returning the corresponding Result to propagate the error. Which means that you are now imposing this requirement (to check for internal logic bugs in library code) onto the user of your library.

Well, I don't write as huge a code as this though, nor does it have as many layers.

Usually I just use the `?` and `.map_err` (or `anyhow` / `thiserror`) to delegate and move on with life.

I have a few places where I do pattern-matches to avoid exactly what you described: imposing the extra internal complexity to users. Which is indeed a bad thing and I am trying to fight it. Not always succeeding.

Post reply on HN