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

221–230 of 233 posts

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

#221

Post by joshka »

pcthrowaway wrote: post #179
joshka wrote: post #178

Earlier quoted context omitted.

>The idea that people might spend 2 months learning rust and become as productive in other languages is frankly unbelievable to me. Upvoted even though I anecdotally disagree with your perspective based on personal experience. I wrote my first line of rust in March this year (just as a hobby), and now am one of the maintainers of a popular TUI framework (Ratatui). I feel just as productive or more than any of the pre…

Interesting. I've been learning/using rust for work for the last 3 months. I'm at the point now where I'm productive (took me over a month to even get to that point), but I still feel incredibly slow compared to Typescript. The compilation time doesn't help. Anyway, thanks for the perspective. I'm still skeptical that the survey reflects honest feedback given Google's culture, but perhaps I'm just biased from how lon…

Probably one of the biggest speed ups to your inner loop writing / running code is to use something like https://github.com/Canop/bacon/. I used a combination of the docs and GPT chats to increase my learning speed a lot.

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

#222

Post by vpastore »

softirq wrote: post #63
ljlolel wrote: post #39

Earlier quoted context omitted.

Try Zig as a C replacement.

I'm not really looking for a replacement for C, the ecosystem of system programming is still really C centric, it would take a large shift in the industry for me to justify investing in another language. I've dabbled with Rust only because early support was merged into Linux. IMO most languages are only marginal improvements over the previous generation that don't outweigh fighting against the entrenchment of experti…

[dead]

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

#223

Post by bombela »

foldr wrote: post #191
davidhyde wrote: post #165

Earlier quoted context omitted.

> “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 e…

In my experience a decent way to solve this is by two layers of abstractions. I will take any better design ideas!

First layer gives you safe access to the hardware registers. For example, ensure atomic/synchronized access, forbid invalid/reserved values. Name the flags/bits to reduce human mistakes (reg |= Prescaler::Div8.

You can still miss-configure the PWM/Timer settings of course.

The second layer gives you a safe driver interface. Giving you all the options to configure a timer for a some PWM settings for example.

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

#224

Post by IshKebab »

pjmlp wrote: post #197
IshKebab wrote: post #46

Earlier quoted context omitted.

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…

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

Depends on the project. Many commercial projects do vendor dependencies and build them too, because you can't rely on the OS version. Especially on Windows or with more niche dependencies.

Just compiling Boost takes 15 minutes - more than any Rust project I've ever compiled.

Not sure what you mean about multiple toolchains.

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

#225

Post by pjmlp »

IshKebab wrote: post #224
pjmlp wrote: post #197

Earlier quoted context omitted.

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…

> Which we seldom due on most C++ projects, we rather rely on binary libraries and build only our own code. Depends on the project. Many commercial projects do vendor dependencies and build them too, because you can't rely on the OS version. Especially on Windows or with more niche dependencies. Just compiling Boost takes 15 minutes - more than any Rust project I've ever compiled. Not sure what you mean about multipl…

On Windows even more so, as most folks do heavy use of DLLs and COM.

And yes exporting C++ from DLLs is compiler specific, which doesn't matter, as there is only one specific compiler version that is usually validated for the whole project delivery pipeline.

Plus we can edit and continue on C++ Builder and Visual C++, with incremental compiler and incremental linker.

There is a reason why so many companies forbid Boost.

Regarding toolchains, JIT, AOT, bytecode interpreter, REPL. Here, 4 variants to compile and execute code, depending on release requirements and developer workflow loop, each with its own sets of plus and minus. It is great when there is a choice.

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

#226

Post by lenkite »

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.

Something like the Flecs ECS (https://www.flecs.dev/flecs/) which makes Rust's Bevy team jealous makes extensive use of C's "useless macros".

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

#227

Post by lcall »

carlmr wrote: post #163
flylikeabanana wrote: post #106

Earlier quoted context omitted.

Isn't this the difference between concurrency and parallelism? Like you said, Tokio (I'm coming from effect systems in Scala, the current generation of which take heavy inspiration from Tokio) is good for informing your program when your code is blocked so it can perform some useful work elsewhere, which is a fundamentally different problem to parallelizing code. So if I'm understanding your complaint right it's that…

Not OP, but I think the problem they are trying to explain is that if you create an async function it can only be called from other async functions, so it's quite an infectious concept. If you create a library that uses async, you're forcing everybody that uses the library into async as well (with the same executor). If somebody writes a library now that's generally useful but uses async, it forces others to use asyn…

I think this is not true. I found a way (in the async book or tokio documentation, somewhere near the end of the docs or end of a quick-start guide or such) to just call it and not have to make the calling function async, using runtime.block_on() .

If you request here or via the email at my web site (in profile), I can provide a more detailed example from a test I have.

(note to self: see fn test_basic_sql_connectivity_with_async_and_tokio() .)

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

#228

Post by mlindner »

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

People who say this somewhat perplex me. Yes you can get the syntax of the language down in a day, but that does little to stop you from running into your first Bus Error or Segmentation Fault within the first 30 minutes of trying to write any software, not to mention all the hidden errors/exploits you've put in your code that are only a platform switch or a compiler version change away from being found explosively. And you can completely forget trying to write a multithreaded C application, which basically confines you to very slow single-threaded code, completely tanking performance versus even the slowest dynamic language that supports multithreading, erasing any advantage for using C.

This is not a personal attack but when I have to try to come up with an assumed background for people who say this it usually involves some assumptions that the person isn't keeping in touch with the "real world" of some sort. I have trouble rationalizing it otherwise. Thus I'll usually ask what their background is when they say this to try to make sense of things.

The only places C is still the optimal choice is where C is already being used or in extreme platforms where there aren't good toolchains (various ASICs/rare 8bit microprocessors). There's zero reason to use it otherwise.

> the pain points cough macros are still often pain points in Rust.

Hygenic syntax checked macros are an entirely different animal than just string insertion/substition macros. I don't think this comparison is fair.

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

#229

Post by lcall »

zaphar wrote: post #218
hgomersall wrote: post #216

Earlier quoted context omitted.

No it doesn't. Your can call an async function in rust from anywhere, you just can't await on it outside of an async function.

The async function also can't await outside of an async runtime. Which means I cant just call it and expect it to work. I need to wrap the call in an executor of some sort. If the async function doesn't do any awaiting itself then it doesn't even need to be an async function. So in practice my statement stands.

I'm no expert on all the details, but I found you can use (at least with tokio) runtime.block_on() to call async (sqlx) code from non-async (my) code. Ctrl-F to see my other comment about block_on, here.

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

#230

Post by no_wizard »

steveklabnik wrote: post #22
no_wizard wrote: post #20

Earlier quoted context omitted.

Color functions are just not the right road to go down. Something akin to Javas new green threads would be better, or Go style coroutines. The path Rust is going means async becomes viral, and is something I dislike a lot about JavaScript[0] and other languages I’ve worked in[1]. I’d love to see Rust avoid this trap. [0]: I work in TypeScript in actuality not sure which to use here. It’s certainly by far the language…

Do you have a way to accomplish this while still staying within the other various constraints that Rust's async is under? I don't believe it is reconcilable. For those not aware of the history and looking for background, I laid it out here: https://www.infoq.com/presentations/rust-2019/ and here https://www.infoq.com/presentations/rust-async-await/ Those style systems are useful and have advantages, but they also hav…

Make it an optional crate like `no-std` is, where you specify it in your cargo.toml
Post reply on HN