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

Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

opensource.googleblog.com

Post reply on HN
Print view View original

191–200 of 233 posts

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#191

Post by foldr »

davidhyde wrote: post #165
softirq wrote: post #152

Earlier quoted context omitted.

I think you missed the part about systems programming. When you are programming real hardware, the focus is entirely on low level details. You need to know the commands being sent to the device, the device state, and the ownership of resources by the device (which Rust doesn't solve for) are correct. The innovation of Rust is the borrow checker, which is primarily of interest to systems programmers. If your primary i…

> “and the ownership of resources by the device (which Rust doesn't solve for) are correct.” For embedded software, the underlying code basically reads and writes a bunch of registers. Unsafe memory access with side effects. The benefit of using rust here is that you can easily model these access patterns to make an api that cannot be abused. So the driver reads and writes addresses and the user code operates through…

>You can’t have two threads (or interrupt handlers) mutating the same device without satisfying the ownership rules.

The trouble with this is that abstract 'devices' don't necessarily map neatly to the underlying hardware. Configuring peripherals on a typical microcontroller typically requires setting flags in a bunch of random registers which don't necessarily have neatly separated responsibilities.

Take PWM as an example. Is there a PWM 'device'? Is there a PWM setting for each port, according to some abstract representation of ports? What about the timer used to generate the PWM output? Does the PWM device own the timer, or does the timer own the PWM device? Any such abstractions cause more problems than they solve. You really just need to think carefully about how you are manipulating the underlying hardware.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#192

Post by pjmlp »

softirq wrote: post #30

> Low-level Operating Systems Sr. User Experience Researcher Wow, I didn't even know this job existed. IMO Rust as a C++ replacement is fine, Rust as a C replacement has more trade-offs than I still care to make. C is still far simpler (you can still read K&R in one day and keep most of the language in your head), has faster compile times, and the pain points cough macros are still often pain points in Rust. I think…

> You can still read K&R in one day and keep most of the language in your head

Except that isn't what most compilers expose, including the UB semantics.

One is in for a sea of surprises when trying to write portable C code and using K&R C as language reference.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#193

Post by littlestymaar »

littlestymaar wrote: post #159
valzam wrote: post #156

Earlier quoted context omitted.

The main difference to me is that Async/await tends to permeate your whole codebase. Once one part of the system is Async/await everything is. With Go I can write most of my code synchronously and maybe somewhere down the stack make 3 HTTP calls in parallel without having to change anything about the calling functions.

> make 3 HTTP calls in parallel without having to change anything about the calling functions. Exception that now you need to bubble up the error condition comming from these functions (if you function didn't have other error already). And in fact, adding those call do change things about how the calling function is run (yields point are inserted and the function isn't being run sequentially anymore), it's just not v…

> Exception that

Except*, damn autocorrect.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#194

Post by tasuki »

PartiallyTyped wrote: post #164
saulrh wrote: post #19

Earlier quoted context omitted.

Consider an alternative reading: 50% of developers think they are as productive in a language they have four months of practice with as they are in a language they have four teen years of practice with. 50% of developers think they are as productive in a high-performance bit-bashing-capable language as they are in a high-level glue language. The people in this statistic are switching from languages they have years or…

I am willing to bet that the type system and the opinionated way of doing things helps a lot here. Anecdata but I found myself very productive with Haskell when I was learning it for grad school, to the point where I knew that if it compiled, it was most likely right. I had similar experiences though not to that degree with Rust with very little time spent on it in comparison to Haskell. I feel a lot more comfortable…

> Anecdata but I found myself very productive with Haskell when I was learning it for grad school, to the point where I knew that if it compiled, it was most likely right.

I recently told this to someone. The very next day my Elm code compiled just fine but it had three relatively tricky logical bugs which took me two hours to find and fix.

This was a rare enough occurrence that I remember it. Higher cosmic powers took note of my praise of strong typing and decided to teach me a lesson.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#195

Post by kaba0 »

littlestymaar wrote: post #188
kaba0 wrote: post #184

Earlier quoted context omitted.

Let’s not make this discussion so rust-specific — panics are not used that way in rust for a reason. But exceptions (especially checked exceptions like in java) don’t have that problem, and are exact analogues to Result types. The point is, some way or another that parse function can fail and you may want to handle it. The caller can easily decide that from afar. This is not true of async/blocking — there can be sema…

> Let’s not make this discussion so rust-specific But this is a discussion about Rust! And my entire point is that async/await is entirely consistent with Rust's overall design. > But exceptions (especially checked exceptions like in java) don’t have that problem, and are exact analogues to Result types. Unchecked exceptions don't have this problem (but checked exceptions do), and that's exactly my point. Async/await…

I’m talking about checked exceptions — they are absolutely analogous to a Result in Rust, that is they are part of the type signatures. It is no longer the example you are talking about re panics vs Result.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#196

Post by tasuki »

Ygg2 wrote: post #119
predictabl3 wrote: post #71

If only we could harness the people who still insist that rust is all hype and engage in impressive gymnastics to ignore all evidence to the contrary... Some of the stuff people say about Rust reminds me of iOS users talking about Android. "Tell me you are operating from a place of near total ignorance, without telling me that you're talking out your butt". See: the number of people, here, acting like you can't do ra…

“It is difficult to get a man to understand something, when his salary depends on his not understanding it.” ― Upton Sinclair Amount of dislike on HN for Rust is frankly unexpected, one part might be response to evangelization, but I've seen more hate on evangelization than actual evangelization. Sure, Rust ain't perfect but like C++ is even more imperfect. So that leaves me with job security in C++.

I don't see much dislike for Rust on HN. It's probably the most loved language around here.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#197

Post by pjmlp »

IshKebab wrote: post #46
epage wrote: post #34

> Rumor 2: The Rust compiler is not as fast as people would like – Confirmed ! I wish there was more context to these, especially this one. For example, how much of this is perception compared to what they were used to (go?, Python?, C++?)? Or is it "any waiting is bad"? From an improvement perspective, I'd also love to know why their builds are slow. Is it proc-macro heavy? Do they have wide and deep dependency grap…

Yeah most of these results are meaningless without comparison to other languages. Same with the "how quick is it to learn?" what are the equivalent numbers of Go? Based on my experience they're overselling how easy it is to learn and underselling the compiler speed. Compilation is fairly fast these days. I would say it's faster than C++ feature-for-feature, at least for clean builds. But on the other hand most people…

Only when considering clean builds as building the whole world from scratch.

Which we seldom due on most C++ projects, we rather rely on binary libraries and build only our own code.

Also when comparing with Delphi, Ada, D, or even Haskell or OCaml, it isn't that great.

You might feel like pointing out that Haskell or OCaml can be even slower, which is true, however they package multiple toolchains and a REPL, and as of today Rust still isn't as flexible in having multiple toolchains for different purposes.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#198

Post by foldr »

kaba0 wrote: post #97
softirq wrote: post #30

> Low-level Operating Systems Sr. User Experience Researcher Wow, I didn't even know this job existed. IMO Rust as a C++ replacement is fine, Rust as a C replacement has more trade-offs than I still care to make. C is still far simpler (you can still read K&R in one day and keep most of the language in your head), has faster compile times, and the pain points cough macros are still often pain points in Rust. I think…

C has beyond useless “macros”, they should not be compared with Rust’s, that are actually useful.

C's macros are primitive and unsafe but by no means useless. Here's a somewhat silly example from embedded programming. I wanted to embed the bitmaps of a small set of characters for use on a bitmapped monochrome display. It was easy to define macros CHAR_GRID, _ and X such that e.g.

    const uint8_t zero[] = {
      CHAR_GRID(
        _,X,X,X,_,
        X,_,_,_,X,
        X,_,_,X,X,
        X,_,X,_,X,
        X,X,_,_,X,
        X,_,_,_,X,
        _,X,X,X,_
      )
    };
desugared to a column-major array of 5 bytes.

    #define CHAR_GRID(c1r1, c2r1, c3r1, c4r1, c5r1, \
    c1r2, c2r2, c3r2, c4r2, c5r2, c1r3, c2r3, c3r3, c4r3, c5r3, c1r4, c2r4, c3r4, c4r4, c5r4, c1r5, c2r5, c3r5, c4r5, c5r5, c1r6, c2r6, c3r6, c4r6, c5r6, c1r7, c2r7, c3r7, c4r7, c5r7) \
 c1r1 | (c1r2

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#199

Post by littlestymaar »

kaba0 wrote: post #195
littlestymaar wrote: post #188

Earlier quoted context omitted.

> Let’s not make this discussion so rust-specific But this is a discussion about Rust! And my entire point is that async/await is entirely consistent with Rust's overall design. > But exceptions (especially checked exceptions like in java) don’t have that problem, and are exact analogues to Result types. Unchecked exceptions don't have this problem (but checked exceptions do), and that's exactly my point. Async/await…

I’m talking about checked exceptions — they are absolutely analogous to a Result in Rust, that is they are part of the type signatures. It is no longer the example you are talking about re panics vs Result.

Checked exceptions are indeed similar to Result, but as such they also have the same issue of “coloring” the call stack, so I don't really see what's the argument you're making here…

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#200

Post by pkolaczk »

kaba0 wrote: post #189
pkolaczk wrote: post #187

Earlier quoted context omitted.

> It has some syntactic sugar for it in the form of a compiler-enforced RAII, but that is still manual memory management for all practical purposes. Then you've got a different definition of "manual" than mine. Manual means that developer has to insert calls to allocate / deallocate memory and that the developer is responsible for proving the correctness of those calls. Automated means those calls are done by the run…

> The fact that ownership is a part of public API is a good thing A libraries next version which switches up some internal representations memory handling should ideally not mess up your application, but it also mandates a higher refactor rate when you are only working within your application’s boundaries. These are worthwhile tradeoffs for the niche rust is targeting, but not for every use case. I’m not saying Rust…

> A libraries next version which switches up some internal representations memory handling should ideally not mess up your application

It doesn't have to because internal memory representation can and should be abstracted out, and Rust gives a plethora of tools to do that.

Your argument works against against static typing in general. The next version changes the address representation from String to Address (in managed language) and messes up your app. That's the same thing.

Post reply on HN