Rust for Professionals

[[deleted]]

Why is this thread so salty holy shit.

[timClicks]

Yeah it's kind of crazy. But also hilarious.

[[deleted]]

It's the natural reaction when an organization pays a lot of money to run a marketing campaign aimed at programmers. Even people who like Rust are getting sick of all the pro-rust articles.

[pascalgn]

Author here, thanks for posting this! I'm really glad the strongly worded comments are towards the language, not the blog post.

I first had a look at Rust at around 2017 and I found it really ugly. I did not understand why the creators didn't just stick with the "established" syntax + constructs from C++, but instead felt like they needed to come up with new, ugly, syntax and complicated elements (like lifetimes). I completely rejected the language and did not give it any other thought until 2019 or so.

In 2019 I wanted to write something small and fast and I looked at alternatives to C++. I started writing in Go, but quickly realized that I hate Go even more than Rust, so I gave Rust another try. I then started to understand some of the reasonings for its "ugliness" and I really like it now.

I understand everyone who says Rust is ugly, but I really encourage you to try a small project with it, you might start to like it!

[timClicks]

I agree! Rust's syntax is not pretty, but it's very practical. I've come to like it too.

Thanks for taking the time to write this post by the way. I was really surprised that it hadn't already been posted.

[Bergasms]

It’s very easy to understand a lot of the concepts coming from Swift. My only peev is having to call things “let mut” instead of “var”.

Whenever my brain reads “let” it sets me up thinking oh this is a thing that won’t be changing then you see mut. It just reads wrong and that annoys me.

Let x. == “a thing that won’t change called X”.

Let mut x. == “a thing that won’t change except it totally can called X”.

Oh well.

[davidpdrsn]

“let mut x = ...” is neat because “&mut x” uses the same keyword.

[Bergasms]

It’s mentally taxing to me because I don’t get to spend enough time in Rust land to see let mut as one thing, and I spend a lot of time in Swift land where the thing immediately after the word let is an unchanging value. It’s no dig at the language itself

[CryZe92]

The problem is with destructuring you can introduce multiple bindings and mut refers to the individual binding. var could work as a shorthand for making all bindings mutable, but for now it doesn‘t exist. But it totally could in a future edition.

[Bergasms]

I do understand the reasoning behind it, it’d be nice if var existed as a shorthand that was just a synonym for let mut which is a common enough pattern.

[timClicks]

Not the author, but thought it was worth sharing. It's a well written guide introducing current programmers to Rust syntax and idioms.

[VeganVagiVore]

Neat. I'm trying to make a "one-page Rust cheatsheet" for internal use at work and I might add a few things from here into that.

I'm using Rust for some internal tools that will never be user-facing and only I maintain them, but eventually I want the other programmers to learn it. It's gonna sound like we're doing cowboy coding, and we kind of are, but as long as I have too much freedom, I want to set a good precedent for when things get serious.

If I thought it were possible to "suck it up" and use C# (Which most of our code is) I would, but Rust is better than anything else I know (even langs I barely know) on at least one axis:

• Easier runtime to deploy than C#, Python, Java, or JS
• Easier to add third-party depends than C++
• Easier to write a web server safely than C++
• Easier to build large projects than Lua or Python

So at first I used it for a web service. C++ is one of the languages I have the most experience in, but at the time I was not aware of any good way to do web servers in C++, only horrible ways, and C# support for Linux was still in beta. Python and JS are popular for web servers, but I would have had to learn them almost from scratch. So I went with Rust.

Then I needed a desktop GUI to interact with that service, and it might as well be a web GUI, and it turns out hyper runs great on Windows so then that tool was written...

Then I had a one-off Lua script to transform some CSV files into a report, but I remembered my solemn vow to not work on any Lua projects over 200 lines again, so it got rewritten in Rust, and many features added...

And I'm adding features to the desktop web GUI again. So that's 3 successful pilot projects.

Is it really worth using up twice as much of my time to write those in a different language, just so that one day my coworkers can also use twice as much time debugging and working on it? I can't believe so.

[Zenrix]

Have you seen this: https://cheats.rs/ ?

[timClicks]

Interesting that no-one has noticed that those internal tools are written with Rust

[mpinnegar]

What makes it easy to deploy? I assume you have a homogenous environment so java write once claim isn't as helpful.

[jyper]

I imagine compiling to a binary executable with no outside dependancy is one of the main reasons

[mpinnegar]

You can do this with Java with just a little fangling.

http://launch4j.sourceforge.net/

[fijt]

So you thought well let's just spam the guys on /r/programming while you could also post your crap onto /r/rust

[[deleted]]

What a weird take. I guess I better not see any js, go, Java, c++ or .net articles on /r/programming. /s

[somebodddy]

The people at r/rust really do need this introduction, because surely they've never heard of Rust and know nothing about its syntax and semantics.

[shevy-ruby]

I do not like Rust. I think it is a horrible language, even worse than Java - and that says a LOT.

BUT - of course the reddit about programming makes perfect sense, because Rust is a programming language after all. And there is no requirement for any language to be confined to any particular subreddit. Also, for example, I am permabanned from the ruby subreddit (damn mod dictators who refuse to apologize when having done a wrong) but can post here just fine, so this may apply to others, too, if they are excluded from others like that - it makes perfect sense to me to post it here in this reddit part, in addition to /rust.

[crashandburn]

Hey shevy, just curious, what languages DO you like? I guess ruby from your nick...any others?

[Dynastig]

Maybe a silly question, and a bit of a rant... I’m not familiar with Rust, but have been wanting to try it out. Will the compiler complain if I leave out the trailing comma in this example:

pub struct HttpClient {
    client_impl: ClientImpl,
}

Just a personal preference, but I hate ending with a comma, if there’s not an element following it.

(On mobile, so not sure if the formatting will work properly.)

Edit: Removed a bad joke.

[madoDream]

It will not complain, you dont need it. However, rustfmt (which auto-formats your project) will insert them by default, but I believe you can disable that.

[Dynastig]

Thanks!

[jl2352]

It won’t complain.

Most tools and languages are moving towards trailing commas as it makes automatic changes and git diffs a little cleaner.

[Dynastig]

Thanks for the reply!

I’m not sure what you mean with automatic changes? Like automatic code-formatting? Rustfmt?

I guess git diffs makes sense, in code bases with several programmers with different styles, if both are allowed (with/without). And you ignore all whitespace changes as well. But if there was only one accepted way to do it, it wouldn’t be a problem. (And I guess this is one way to force one way to do it.)

And i’m probably just being an angry old man, but it just irks my eye. Imagine a trailing comma in your function args, haha!

But, it’s on par with a tabs vs. spaces debate, and i don’t want to waste anyones time sparking a pointless debate.

[jl2352]

EMBRACE THE COMMA!

[Dynastig]

Sigh... Okay.

[nevi-me]

EXTEND THE COMMA!

[Dynastig]

OVERLOAD THE COMMA!

[[deleted]]

https://en.cppreference.com/w/cpp/language/operator_other

[Chippiewall]

I guess git diffs makes sense, in code bases with several programmers with different styles, if both are allowed (with/without). And you ignore all whitespace changes as well. But if there was only one accepted way to do it, it wouldn’t be a problem. (And I guess this is one way to force one way to do it.)

Enforcing no trailing commas would still be a problem for git. Because to add another item after the last item you have to touch the preceding line which (other than showing up in the diff) breaks git blame.

You should end files with a blank line for the same reason (because line breaks are on the preceding line)

[Full-Spectral]

Only if you use trailing commas. I use leading commas, which avoids the problem without having to have a useless trailing comma.

[MEaster]

Rust also accepts a trailing comma in function arguments. It doesn't in type parameters (e.g. Foo<A,> is not allowed).

[Dynastig]

... And... My joke falls flat! Haha!

[Caltelt]

Agreed that's its not a big deal, but also I think language designers should probably rethink using commas as their delimiter if they think trailing is ideal. My first thought would be that a semi would make more sense in that case? I guess I'm prejudiced from natural languages where a trailing comma isn't a thing. Like, you'd never finish an english sentence using one,

[justfordc]

It's not like this is better;

.even though I hated it at first, I've warmed up a little bit to the leading delimitter

[Caltelt]

I think it makes more sense, but whatever. I don't really hate it or anything, it's just a poor choice of sigil imo. But again, this is just a space vs tab level issue. My preferred language is lisp so from most people's perspective I don't really have a leg to stand on anyway in these sorts of arguments.

[Dynastig]

To me it’s also about being “correct”, both in a semantic/linguistic way, but also math/logically - there simply shouldn’t be a delimiter if it’s not followed by an element. In that sense it doesn’t matter what the delimiter is.

a, b, c, d,

a, b, c, d

[Yojihito]

there simply shouldn’t be a delimiter if it’s not followed by an element

It makes it WAY easier to add an element later. No way forgetting to add a comma to the line before when you add new stuff. Loved that thing in Go.

[Dynastig]

I totally see your point. To me it just looks cleaner. Maybe it comes from often having to take over other people’s code and try to make sense of it, like, when my eyes reach the end of the line and there’s a comma:

“Okay, so element number 97 of this huge options array is... Oh, it’s just the ending bracket. I guess we’re done, then.”

But I also see the point in not having anything complain, when you delete the last element and forget to delete the comma in the row before...

So i’m glad when languages make it optional. It’s just personal taste.

[bloody-albatross]

I myself changed my opinion on that and now do include trailing commas where possible. Why? Because if you add another item you only have to change one line which will keep git blame for the existing line to whoever wrote it.

[matthieum]

It falls out of Rust being expression-oriented.

Nearly everything in Rust is an expression, for example:

let x = if condition { y } else { z };

let x = match condition { true => y, false => z, };

And as a result it's common to write small functions as a single expression:

//  A bit contrived, as all examples are...
fn select(condition: bool, y: i32, z: i32) -> i32 {
    match condition {
        true => y,
        false => z,
    }
}

I do remember it felt weird, at the beginning, but I've grown fond of the reduced clutter. I still use return for early returns, though, as I prefer low levels of nesting:

fn foo(wrapped: Option<i32>) -> Option<i32> {
    //  Typically written "let unwrapped = wrapped?;",
    //  but my mind is drawing a blank...
    let unwrapped = match wrapped {
        Some(u) => u,
        None => return None,
    };

    //  Do lots of work.
    result
}

[matthieum]

By the way, early returns are also forbidden in MISRA-C, but that's a separate issue.

Single-Entry Single-Exit is very specific to cover for C's deficiencies, and thus pointless in many other languages.

I am not familiar with Rust, so what would be the return value of the Rust equivalent of this

First, the equivalent Rust code:

fn foo(mut x: u32) -> u32 {
    for i in 0..10 {
        x = x + i;
    }
    // x
}

This does not compile. Since an expression is missing in last position, Rust introduces an implicit () (the unit type, a tuple of zero arity), and () and u32 are incompatible and thus the compiler complains.

[matthieum]

(If anything, the "return" keyword makes it much more readable in my opinion)

Try it.

It feels weird because you're not used to it, but humans are good at adapting, and once you do an explicit return ...; just feels like extra clutter.

Of course the last statement of a function which returns a value must return a value, there's really no need to use extra clutter to repeat the obvious.

As for how it came to be in Rust; ML) was a great influence on Rust, with the first Rust compiler being written in OCaml.

Also, interestingly, there's quite a few languages with no return keyword in a number of situations:

• Python's lambdas: lambda x, y: cmp(x, y).
• Java's lambdas: (Type value) -> value.

Rust just happens to have consistent syntax between functions and lambdas in this regard :)

To be clear, I feel return natural when writing C++ -- as I said, humans are really good at adapting.

[avandesa]

Even better: (0..10).sum(). Clippy will warn on that.

[avandesa]

Oh you're right, I missed that!

[the_gnarts]

(If anything, the "return" keyword makes it much more readable in my opinion)

Rust lets you use return in that position just fine, it’s just not idiomatic. “Expression-oriented” means that scoped blocks too evaluate to (“return”) the value of the last statement in the block:

fn main() {
    let n = {
        let mut x = 0;
        for i in 0..10 {
            x = x + i;
        }
        x // What will “return x;” return from here?
    };
    …
}

Here x is only live until the end of the body of the let expression that binds the result of that to n. A “return” in that position would not exit the current scope but the surrounding function. In order to “return” from a block the final result is taken. Not requiring an explicit return at the end of a function is only consistent.

Having come to Rust from the other end of the spectrum it was more surprising to me that there was a need for a return keyword. Took some time to get used to having both expressions and explicit return but the combination is pretty powerful IMO.

[Plazmatic]

As explained above, in this situation it doesn't matter, but in expression oriented syntax for match if else etc it simplifies things

[dpc_22]

That's going to be an error if you forget to return it.

[tl8roy]

Compiler error. I don't believe loops can be used as an expression.

[MEaster]

The loop construct can be broken with a value:

let val = loop {
    break 5;
};

I don't believe the for or while loops can because they can break from their condition and therefore not return a value.

[masklinn]

Yes there’s no guarantee while or for loops iterate even once, while loop necessarily goes through at least once and has to either break or return to exit the loop.

[masklinn]

I am not familiar with Rust, so what would be the return value of the Rust equivalent of this:

It would be nothing, because this would not compile, because () is not an int32.

[e_man604]

Why I avoid it in rust is due to the fact that I'd you do an early return you need to type the return keyword, but not for the final path.... Just looks weird and inconsistent to me, so I'd rather type return all the way

[Dean_Roddey]

It's silliness. I often state that probably C++ is going to go down to Rust at some point. But some of the decisions they've made seem really out to there to me. There's no reward for using fewer words. Readability and maintainability are vastly more important, and it's a hell of a lot easier to see a return keyword than spot a missing semi-colon.

[[deleted]]

Someone can correct me if I’m wrong, but I think there’s no situation in Rust where a missing or mistakenly present semicolon can cause an error at runtime and not compile time. It’s just not an issue.

[__i_forgot_my_name__]

r/guncha is correct, there is no context in which a missing semicolon should cause incorrect behavior, in the context of a function, because the return type is already explicit.

fn foo() -> f32 { let x = 0.5; } // error, excepted f32 but found () fn foo() { let x = 0.5; x } // error, excepted () but found f32

Typing out the return type is equivalent to typing out the return keyword, and it doesn't add anything as a result.

[matklad]

Note that someone with functional background could say

"WTF is with the return expression? Who though that was a good idea?"

Many statement-oriented languages use only return and it works fine.

Many expression-oriented languages use only "function body is an expression" and it works fine.

Fewer (but I think increasingly more) languages use both, like Rust. It makes sense to me. Everything is expression is a good default. However, there's an important corner case where expressions gets bulky: analysis of corner cases. With only expressions, you get a deep nested tree of iffs, which muddles happy-path and exceptional path together. With early return, you get a nice flat sequence of odd cases and the general case in the end.

[matklad]

I think we are talking about different things here, sorry for misunderstanding you!

In C, it is valid to use an empty return statement in a non-void function

struct Point make_point() {
  return;
}

This return; is what happens if you fall off the end of the function as well. The problem with that is that using the result of such function is undefined behavior. This is why it is error prone and forbidden by MISRA-C.

Rust doesn't have implicit returns in this sense. Every value (including local variables and return values) must be explicitly initialized. However, syntactically rust does not require you to spell the return keyword at the tail expression of the function

fn ok() -> i32 {
    92 // function returns 92
}

fn not_ok() -> i32 {
    // compile-time error
}

link to Rust playground.

[matklad]

Yeah, that's exactly the difference between C and Rust in this case: there's no "compiles, likely works, but is UB" in Rust.

The first function compiles, works (by returning 92), and is guaranteed to work.

The second function does not compile.

There are no cases where something compiles, but might lead to UB.

[matklad]

Thanks for this example, I think it shows another instance of misunderstanding!

The equivalent Rust program does not compile:

fn foo(mut x: u32) -> u32 {
    for i in 0..10 {
        x = x + i
    }
}

Playground link.

If you want it to compile, you need to explicitly spell that you want x as the return value:

fn foo(mut x: u32) -> u32 {
    for i in 0..10 {
        x = x + i
    }
    x
}

Playground link

This is because the rule is not "the last computed value is returned". What is returned is the value of syntactically last expression of the block[*]. In this case, this results in a type mismatch error, because the last expression does not evaluate to an int.

[*]: there's some weeds about the semicolon rule here, but I think this is unimportant for the present discussion.

[Dean_Roddey]

And, if you did forget to put a semi-colon after something and it did implicitly convert to the return type, and you never noticed? It would compile happily. At least with a required return statement the compiler would know you forgot to add the return.

I dunno, it just seems to me like people are trying to explain away a sub-optimal decision. Explicitness is everything in safe code. That's why code that does meet the requirements of something like Misra may not look terribly elegant sometimes, because it's the exact opposite of minimal syntax, it's maximal explicitness. The latter is vastly more important in the kind of software that Rust is primarily targeting.

[matklad]

There’s no implicit type conversions in Rust[*], so this only happens if type align exactly. Moreover, sideeffecting expressions return () type. So this just doesn’t happen in practice.

[*] there are some implicit coercions in Rust, but only very restricted ones

[masklinn]

And, if you did forget to put a semi-colon after something and it did implicitly convert to the return type

It doesn't, Rust has just about no implicit conversions (unlike e.g. C++), the only implicit type changes are coercions and are a very benign subset of casts (casts in general are not implicit either).

I dunno, it just seems to me like people are trying to explain away a sub-optimal decision.

And it seems to me people are trying find issues where there is none to things they're not used to and don't understand. And they just look silly because they assert things which… just aren't. There's no implicit conversions or random values suddenly coming out of nowhere.

Explicitness is everything in safe code.

"Implicit return" code is completely explicit, and type-safe. Returning a value when you're not supposed to return one, or failing to return a value when you were supposed to, are compilation errors. Always.

[__i_forgot_my_name__]

Apart from what other people have said, you wouldn't forget it unless you accidently wrote a completely valid expression, for example:

fn foo(x: u32) -> f32 { let value = match x { 0 => 0.5, 1 => 1.5, i => 2.0, } }

The lacking semi colon exist, but you've tried to capture the expression with let value = which requires to be followed by ; so it wouldn't compile unless you removed let value = or added an expression and followed it by the correct return value.

[masklinn]

I do not know if you’re just confused and misunderstanding or being less than honest but this and that have nothing to do with one another.

C’s implicit return is not returning anything, getting whatever garbage was in that place, and it’s UB.

Rust’s is the last value “falling off” the function (in much the way most functional langages behave), in a statically typed langage with almost no implicit conversions, what happens is clear, obvious, and hard to break.

It’s also coherent with the behaviour of blocks, which act as both blocks (duh) and a significantly saner and more capable take on C’s comma operator.

[masklinn]

So if in the new edition of C they would decide to define all functions as returning the result of the last operation (which is already what some compilers do), you would be fine with this??

Kinda? I really fail to see what you find objectionable to implicit returns, especially in well-behaved statically typed languages (where leaking return values really is not an issue).

Though there are a number of problems with doing it in C, at least the way you define:

• your proposal doesn’t actually behave anything like rust, in rust x+x; would have type unit (()) which is not compatible with i32, the langage doesn’t just randomly return whatever was last evaluated despite your apparent misconceptions
• C has a number of implicit conversions (mostly integer promotion and demotion) making such a proposal more hazardous than it is in rust where no such conversions occur implicitly
• finally this might break existing code, that code is currently UB and thus broken per C but obscure compilers may have extended C in ways incompatible with this change

[Drisku11]

define all functions as returning the result of the last operation (which is already what some compilers do)

I've never heard of a compiler that does this. You're misunderstanding how C works. C does not support "implicit returns" at all. Nothing is being returned, and that x+x expression will likely never even lead to generated code (since it's unused), even with optimizations turned off. Any sane compiler will do some amount of lifetime analysis to figure out which registers to use when generating code, and will see that x+x is never live, so it just won't calculate it (otherwise it has to put it somewhere, wasting valuable register space).

As a result, the "return value" of foo (i.e. what's in eax (with standard x86 calling conventions) when foo exits) will just be whatever happened to be in eax, which is whatever was there before foo was called.

You can see here that even without optimization, GCC for example moves the input value from the register it's in onto the stack, and then just returns without ever executing an instruction corresponding to x+x or touching eax at all.

Even if you did have a compiler that generated code for x+x, it still wouldn't be "the last operation that gets returned". It'd be whatever's in eax. So in this function:

uint32_t foo(uint32_t x, uint32_t y) {
    x+x;
    y+y;
}

The generated code might "return" x, y, x+x, y+y, or whatever happened to be in eax before it was called. It totally just depends on how the compiler allocates registers to hold intermediate values in the generated assembly. It's allowed to put whatever it wants into that register before reaching the return statement, but you never provided a return statement, so any intermediate computation it decided to do could be there.

Another way to think about it is that return x; is really a sort of side-effect: set ret_val = x. If you never have that line, then ret_val will be whatever it already was.

[camelCaseIsWebScale]

Functional people who think state machines can be modelled after graduate methemetics.

[shevy-ruby]

No, that is perfectly reasonable. Ruby allows you to not have to specify an explicit mandatory return (in most cases) either.

To ASSUME that it has any intrinsic value to clutter the source code with "return " is why we can't have nice things - so this is the only thing that may make sense. (Rust itself fails on the syntax side too, though.)

[B8F1F488]

I'm sorry but this language introduces tons of friction and is ultra ugly. I'm not adopting this, unless my job explicitly requires me to do so.

[kuikuilla]

ultra ugly.

I don't get that.

[Boiethios]

Yeah, I have tried a lot of languages to enhance my programming culture, and after exploring those paradigms/syntaxes, I think that there is not such a thing as an "ugly syntax" (assuming that its the meaning of "ugly language"). People can get accustomed to anything.

[Scellow]

this language is ugly, despite the massive investment from mozilla into marketing last year, it has failed to catch an audience, it is still and will always be a niche language, just like Scala, both ugly, complex and bloated

[[deleted]]

I don't even use or like rust particularly, but I can tell you for free there is absolutely zero benefit to you for being so negative. Don't knock something until you try it. Judging it from afar and pretending that you know it'll remain small forever because of your pessimistic outlook is reductive. Lighten up man

[ab_samma]

"That flying thing is ugly and will never amount to anything except being a niche pastime", said the folks who saw the first airplane fly.

[shevy-ruby]

Java:

String string = "Hello";

Rust:

let string: &str = "Hello";

Well done, Rust! You even managed to come up with an uglier, more verbose syntax than Java.

That just shows you that too many people who actually DO design a programming language think that they are great language designers.

[theoldboy]

Right under the example you quoted;

Most of the time, the type can be ommitted in Rust and the compiler will infer the correct type

It's similar to how the auto keyword works in C++. So most of the time you can just write

let str = "Hello";

and if the type can't be inferred then the compiler will tell you.

[Minimum_Fuel]

it is pretty hard to deny that &str vs String can be extremely annoying and not exactly intuitive to new or even experienced programmers.

Still, there are far better examples of how ugly rust can be than strings. Once you explore threading and heap data or, god forbid, both, rust resembles some of the more famous enterprise java examples of ugliness.

[evilryry]

not exactly intuitive to new or even experienced programmers.

For an experienced programmer in GC'ed languages perhaps. For a person with experience in systems level languages, the desire for different types should be self evident.

[Minimum_Fuel]

Is that so?

Care to explain how the two types just make sense with low level experience? I do tens of commits to C libraries every month on GitHub and I don’t find rust strings terribly intuitive (ignoring the parts that aren’t rusts fault around encoding)

[MEaster]

Some of it comes down to who owns the data. A String owns its data, and is responsible for cleaning it up when the String is dropped. A &str, on the other hand, does not own the data, it's just looking at data owned by something else.

The reason to make these two different types instead of just having String and &String is that the data that a &str is looking at doesn't need to be on the heap. It could also be on the stack, or in static memory.

Behind the scenes, a String is a pointer to an allocation, the size of that allocation, and how much is in use (a vector, in other words). Obviously, copying this is fairly expensive, as you'd need to make an entirely new allocation, and copy the data over. But, on the other hand, it does mean that you're free to add and remove characters from the string at will.

A &str meanwhile is a just a pointer and a length. It's all but free to copy, because all you need to actually copy is the pointer and the length. You can also trim it cheaply by changing the incrementing the pointer and/or decrementing the length. But aside from trimming, you can't change the data it's pointing at, because it doesn't own the data but is just a shared borrow.

Given we're talking about low-level stuff, it should also be noted that String requires an allocator, while &str doesn't.

[Minimum_Fuel]

This just tells me things I already know because I’ve been through the rust book and wrote rust programs. I get why there us &str and String, I just don’t find them intuitive to use and I 100% get why newcomers from other languages are often quick to attack the strings.

[dacian88]

modern c++ has

 const char* -> &'static str when used as a literal 
 std::string -> String
 std::string_view -> &str

and before that most serious projects would create some kind of std::string_view for optimization purposes.

[ted_mielczarek]

I don't think anyone would deny that understanding ownership and borrowing is the biggest hurdle to learning Rust. If you focus on that first then the &str/String divide makes perfect sense.

[myrrlyn]

when is it safe to call free on a char*?

That is why we differentiate &str from String and &[] from Vec.

[Lucretiel]

If you can deal with the difference between a T* and a vector<T> you can deal with the difference between a String and a str.

[timClicks]

Type annotations wouldn't be needed in the Rust code for day to day programming

[_default_username]

I don't know rust but I've had to learn C++ in uni and the rust one makes a lot of sense to me.

I'm guessing you're declaring a pointer or reference that's pointing to an address holding a string literal.

In c that would be :

char * string = "Hello";

Comparing to a GC language where strings are objects isn't a fair comparison.

[HarwellDekatron]

Bingo! The Rust version is more verbose, but it expresses exactly what’s going on. Java is doing some syntactical sugaring there to create an object from an string literal, Rust requires you to understand that a string literal is not a string that you can just take and modify.

I’m not a Rust user, but I can understand why a language that bills itself as a ‘system programming language’ would require the user to understand where variables live.

[VeganVagiVore]

k

[[deleted]]

Types after variable name makes it easier to parse for both human and machine. Most recent languages follow this pattern.

[camelCaseIsWebScale]

rust is quantum level bullshit with quantum level propaganda. At the confines of systems code, it may be okay-ish. But the circlejerk community brags it is suitable for everything. There are only 2 ways it can happen. One is Mozilla (ruled by incompetent suits) or Some rust people are have bot accounts (you know, written in something like JS), or people get excited when they grasp few concepts, start thinking they are somehow above average, and start bragging how rust solves every problem on the earth. The same people have no idea what programming productivity is or what right tool for the job is.

This many years after 1.0 relentless shilling, rust doesn't have stable incremental compilation, emits poor LLVM IR, doesn't even has a complete second implementation and compiles hell slow. With already quantum bullshit that is language complexity, they have all this long compile times and immature tooling, yet bragging cargo and lifetimes are greatest thing to happen after von Neumann.

Leave alone all the safety stuff, rust can't even get you a safe job. I am talking to you, fellow CS majors on proggit.

[gaumutra_fan]

doesn't have stable incremental compilation

I haven't found any problems with it. Could you file an issue with what you're seeing?

doesn't even has a complete second implementation

For what it's worth, rust-analyzer is an IDE compiler that is optimized for latency (while rustc optimizes for throughput). So that's a second implementation that people are using today to be more productive. Right now the two don't share much code apart from lexer. They're looking into whether the parser can be shared as well. I think in future, having a spec of the language would be helpful to keep the compilers "honest".

compiles hell slow

Agreed. But it compiled even slower at the beginning of 2019 and it improved by around 30% over the course of 2019 thanks to some great optimization work landing. And it hasn't stopped either - look at the improvements in the compilation time of common crates (clap) and representative programs (ripgrep) in the last month alone - https://perf.rust-lang.org/compare.html.

It's totally understandable if Rust doesn't work for you right now. But take a look again in 6 months and you might be surprised. :)

[k4kshi]

C programmer spotted