DEV Community

loading...

Discussion on: Rust looks awesome

Collapse
davidmm1707 profile image
David MM🐍

I have tried Rust a bit and I added it to my "To learn" list, between Go and C#.

I have seen some criticism to the compiler being "too loud" complaining about everything. To me, is one of its best features.

It is very hard to write bad code that way.

Collapse
itsjzt profile image
Saurabh Sharma • Edited

I have a love-hate relationship with strict compiler and I prefer flags that removes the strictness because sometimes I don't want to look at the edge cases and want things to work in most of the case.

Collapse
dentych profile image
Dennis • Edited

Problem is that "sometimes" usually end up turning into "never". You turn off a feature because it becomes an annoyance, and you "just want to test something". Then you get used to it, and if you enable it later on, it will become an annoyance again, which is why you disabled it the first time and it eventually just stays off...

Collapse
louy2 profile image
Yufan Lou

I think turning off strictness project-wide is too big a hammer. unwrap() is always used in Rust to defer error handling during prototyping, and the way Option and Result preserves the inner type information helps with silly mistakes. OTOH, if the strict compiler doesn't come with good type inference, I know how frustrating writing all the types manually can be. Rust's type inference is on par with OCaml, so you rarely need to declare types on variables. Where Rust struggles is if you use callback functions a lot: the closure types are restricted by the lifetime rules and can be unwieldy.

Collapse
peterwarrington profile image
Peter Warrington

Exactly, it forces you to not do stupid stuff that can bite back in the future. Also I love how it seperates unsafe memory stuff from safe stuff based on a keyword. You will never do anything unsafe unless you explicitly tell it too.

Collapse
ivan profile image
Ivan Dlugos Author • Edited

That's precisely what I prefer. More diligence during development, less time spent debugging obscure errors.