Little note about function parameters: Taking &str instead of String is good, but only if you don't need an owned String. If you do need an owned String, make sure to take a String, so the caller can decide how the owned string is generated. (For example, the caller might already have a String. If you take a &str, you need an unnecessary clone) Now to contradict myself: If you do need an owned String, it might be best to use an impl Into instead. This way, the caller can pass in a &str as well. Improves ergonomics. In the same vein, taking impl AsRef instead of &str also allows your function to take an owned string. It is trivial to put an & in front, so it's not as important as Into, but it also slightly improves ergonomics. Depending on what you actually do with it, you might even want your string input to be IntoIterator or something. This does decrease ergonomics, since the caller now needs to call chars on the string, but it does mean your function will also work with, for example, Vec. If you sometimes return an owned string and sometimes a &str, you can use Cow. For example, if you sometimes return a string literal, Cow
I think this is probably your best video yet. It's great that you've gone a little bit deeper. Programmers really need to know this stuff. Thanks for your effort.
This might be the best string and UTF8 encoding video I’ve ever seen. So many experienced, professional programmers really do not understand how Strings actually work, even in their own language or choice. And it truly did demystify for me Rusts behavior around the different string types. Much appreciated.
As a note on your comment at the end: The type that you said that Rust does not have would be represented by Vec in Rust applications. It is not equivalent to rune slices in Go ([]rune), but intended for the same usage. In general, go slices are similar to rust vectors. However, there is a difference between char and rune: In Go, rune is an alias for int32. In Rust, char is its own type. With Rust's emphasis on memory safety, safe Rust code cannot generate invalid chars. This means that it's behavior is different from u32, the type that it would otherwise be equivalent with. In Go, it is perfectly possible to create meaningless runes. The same is true for strings by the way, safe Rust code cannot generate invalid UTF-8 values, but no such limitation exists in Go. As I understand it, these are equivalent types between Go and Rust: - string -> &[u8] - rune -> i32 - byte -> u8 - []byte -> Vec - []rune -> Vec - [7]byte -> [u8; 7] - [7]rune -> [i32; 7] The other Rust types that we mentioned (char, &str, String, Vec, etc) have additional memory safety guarantees that Go does not provide.
Def one of the best, light weight (and logic dense) videos I've seen regarding rust string types from a practical standpoint (concerning aspiring Rustaceans). Excellent vid.
At 20:50 you talk about fixed-length encoding using four bytes. This is what UTF-32 does. AFAIK none of the major languages uses it, but Python has an interesting take on it: When a string is created, the interpreter chooses the “best fit“ between ASCII, UTF-16, and UTF-32, so that constant indexing is always possible but not too much memory is wasted. This of course only works because Python strings are immutable.
Rust's char type actually is UTF-32, as far as I understand it. Which means you could get very similar functionality to a fixed character length encoding by simply using a Vec (or an &[char] to emulate a string slice), if you so wished. Granted, not all the operations that are possible for the normal string types are implemented for a Vec, but given the size of the Rust ecosystem, there's probably a library to make it possible.
This was driving me crazy last week. Really glad to see good, thorough showcase of this concept in Rust. Appreciate your content! Keep at it, this will be big when Rust blows up.
awesome video, just a small thing. Newer programmers may be confused by the lookup vs search times for a character. For UTF-8 (or any variable length encoding) if you want to lookup the nth scalar or grapheme you need to do a linear walk through of the string to count off every time you get to the end of a sequence of bytes representing a scalar/grapheme but for a fixed length encoding (runes, UTF-32) you can rely on each unit (scalar/char/grapheme) being a fixed size and you can just skip (n - 1) * 4 bytes (UTF-32 uses 4 bytes per scalar) to land in the right place. Not sure if I just confused a bunch of people or added clarity for some.
Finally! A great explanation of what's going on between string slices and Strings -- thank you! I also appreciated your delving into unicode encoding -- I was worried you were going to rabbit hole on binary representations of a bit characters, but you did exactly the right thing in terms of explaining how unicode encoding works, how it solves the "where am I" when you have a pointer to an arbitrary byte in a unicode string (i.e. "am I at the start?" "where is the next char boundary?") -- I love that you explicitly mentioned that the first byte of a multicode byte string is differentiable based on the high order bits, and that it encodes the length of the multibyte sequence. You mentioned indexing into a Unicode string was a linear operation, which is true, but it's sub-linear in terms of number of bytes explicitly traversed -- if you have 4 4-byte unicode chars in a string, traversal takes only 4 operations, not 16, due to this clever encoding of the first byte.
Wow, this is extremely useful! I come from the Java world and it was really confuse me when working with Rust string, especially when I need to deal with ideographic characters. Thank you!
Here a brief summary of UTF-8 encoding: - UTF-8 (Unicode Transformation Format, 8-bit) is an encoding scheme, just like ASCII, for representing Unicode characters. - In UTF-8, ASCII characters are represented using a single byte, which means that any valid ASCII text is also valid UTF-8 text. - Therefore, UTF8 is backward compatible with ASCII. - In UTF-8, characters that can be represented using a single byte (i.e., ASCII characters) are represented as themselves. - Characters that require more than one byte are encoded using a combination of multiple bytes. - A code point refers to a numerical value assigned to each character or symbol in the Unicode standard. - Code points are represented using hexadecimal notation and are typically prefixed with "U+" to distinguish them from other numerical values. - For example, character "é" (Latin Small Letter E with Acute) consists of two Unicode code points: the base character "e" (U+0065) and the combining acute accent (U+0301). When encoded in UTF-8, "é" is represented by the bytes 0xC3 0xA9. - A grapheme refers to a visual unit of a written language. It represents a single user-perceived character or a combination of characters that are displayed together. - len() function returns the number of bytes, not the number of characters in a Unicode-unaware string. - len() function returns the number of characters in case of a Unicode-aware string.
The thing I like about Rust is you can take a buffer out of one type and transfer it to another. Like for instance you can convert between String, Vec and Box, while keeping the same underlying buffer without reallocation and copying. Hope C++ would have this. It had node transfer in limited form for lists and in newer standard for maps.
Note that converting to a `Box` reallocates if the length is less than the capacity, but other than that, owned conversions just transfer ownership of the existing allocation.
Most people say strings in rust are complicated. For me, it makes a lot of sense how it's handled. I do quite a bit of C progamming on µCs, and there everything is char*
@@sconosciutosconosciuto2196 Embedded Rust usually doesn't have the full standard library. It has parts of std called core and alloc. If your resources are limited, you can use a CString, which is null terminated and equivalent to char*.
I really like all of your videos they are one of the best out there. You mentioned that you came from a javascript background. How did you become a pro-rust-developer? did you learn the language privately and than you searched for a job or was it a fluent transition within the company you've worked in? I'm prof. C# /Typescript/Javascript developer and would like to jump on the rust-train :-)
As far as I understand in Go you take a string which is a slice of bytes and build another slice of int32, 1 per each unicode code points. So it's nothing special, or advantegious. You just paid for a a full string decoding once. This would be equivalent to chars().map(|c| c as u32).collect::() in Rust. But because in Rust iterators are lazy you don't pay for creation of a new vector each time unless you explicitly want to.
I have been using Python since the Python 2 days and while it seemed simpler by trying to automatically convert between unicode and bytes, this was a source for really confusing errors. In fact, Python 3 became more strict in this area by introducing the same separation between bytes and (character) strings that Rust is essentially using - which saves programmers from a lot of hard to track errors. The difference is that in Python, indexing into a string now counts the characters, which has an unexpected complexity, while Rust counts the bytes and then checks that the result is valid.
How does Rust handle interoperability between string implementations (OSString, CString, a hypothetical UTF-32 String etc.)? Is there enough compiler sugar to pass a reference to an alternate String type to &str, or is there an "IString" trait you can implement or is there a lot of myString.as_str() involved?
it’s always manual conversions, though you have a lot of options depending on what you need - rust is super strict about not performing expensive conversions automatically (especially ones that can fail, like converting a byte string to a utf-8 string)
Your tutorials are the best in Rust I've seen! Your English is also gorgeous. I didn't know you were Ukrainian before this video. Glory to Ukraine 🇺🇦 from Kazakhstan 🇰🇿
I know about the stack and the heap (and the register), but I've never heard of the "application's binary". What is it? Do you have another video where you explain it? Thanks!
There are a few different ways a program can get read only or read write memory. Your executable normally contains a chunks or describes chunks or memory that it needs. The OS then copies or creates these chunks from your program and marks them as read only or read write. They are different sections of the program then heap and stack. That's the basics hope it makes sense.
The proliferation of code pages was an issue many years before the world wide web hit critical mass. Not everyone developed code to run in only one Country/Region.
@@xrafter In JS they just let you make the mistakes. "🤔".length == 2, for example. And to split grapheme clusters, you will have to go find an external library, because it can't do that at all. The only thing other languages can do is streamline the usage of the complex stuff. In Elixir, for example, they hide the concept of string normalisation by making string equality work correctly out of the box. They still have an iterator over grapheme clusters but it's in the core library so you don't have to pull a separate dependency to get it. Older languages as a rule just get string handling wrong and push the complexity to the developer. It isn't so much hidden, as completely absent.
In 2003, the RFC 3629 standard for UTF-8 restricted the possible range of symbols by U+10FFFF and excluded U+D800..U+DFFF from the range, to make UTF-8 compatible with UTF-16.
I think it's really the name that's confusing. It seems better to just think of &str as an immutable reference to a string - it can be viewed but not modified. If you want to modify, you need a String. The rest of the stuff about slicing and indexing isn't really confusing, people are probably already familiar with indexing into arrays. Finally, you just have to remember that you can only index in a &str, not a String. You can learn why if you want to, but it doesn't really matter much at the end of the day. &str: indexable, immutable String: non-indexable, mutable
Good stuff! Just getting into Rust as a mainly JS-Dev and this is by far the best content out there! One question: What VS-Code extension are you using, that shows these greyed out type-annotations and function-parameters?
You skipped straight past the original solution to the 127 character limit which was code pages and encoding. UTF-8 was the better solution that came out of this, but UTF-8 was not widely used. UTF-16 was, but the problem with it was that it doubled the amount of memory required to represent every character, even those that could be represented by ASCII. So it was not popular because computers back in the 90's had such limited memory. UTF-8 was popular in the early 2000's, but the problem was that it was not standardised on and everybody was still using character encodings. So there was this fun problem of writing data into databases in the wrong encoding and then decoding it in the wrong way too, leading to all sorts of fun jobs for me to fix peoples databases and nobody really understood how to fix. These days this problem is all fixed (I guess, right? right guys?). But yeah, just wanted to write about how UTF-8 was NOT the original solution to the ASCII problem.
Hello, happy to subscribe to your channel. Would you please say few words why an absolute beginner would rather get more motivated to learn Rust rather than say Python (or any other language that is closer to the English language syntax, ie easier ). Thank you kindly
📝 Get your *FREE Rust cheat sheet* : www.letsgetrusty.com/cheatsheet
This has become my favorite RUST channel on TH-cam.
Because this is the only rust channel on TH-cam
Little note about function parameters:
Taking &str instead of String is good, but only if you don't need an owned String. If you do need an owned String, make sure to take a String, so the caller can decide how the owned string is generated. (For example, the caller might already have a String. If you take a &str, you need an unnecessary clone)
Now to contradict myself: If you do need an owned String, it might be best to use an impl Into instead. This way, the caller can pass in a &str as well. Improves ergonomics.
In the same vein, taking impl AsRef instead of &str also allows your function to take an owned string. It is trivial to put an & in front, so it's not as important as Into, but it also slightly improves ergonomics.
Depending on what you actually do with it, you might even want your string input to be IntoIterator or something. This does decrease ergonomics, since the caller now needs to call chars on the string, but it does mean your function will also work with, for example, Vec.
If you sometimes return an owned string and sometimes a &str, you can use Cow. For example, if you sometimes return a string literal, Cow
I think this is probably your best video yet. It's great that you've gone a little bit deeper. Programmers really need to know this stuff. Thanks for your effort.
This might be the best string and UTF8 encoding video I’ve ever seen. So many experienced, professional programmers really do not understand how Strings actually work, even in their own language or choice. And it truly did demystify for me Rusts behavior around the different string types. Much appreciated.
As a note on your comment at the end: The type that you said that Rust does not have would be represented by Vec in Rust applications. It is not equivalent to rune slices in Go ([]rune), but intended for the same usage.
In general, go slices are similar to rust vectors. However, there is a difference between char and rune: In Go, rune is an alias for int32. In Rust, char is its own type. With Rust's emphasis on memory safety, safe Rust code cannot generate invalid chars. This means that it's behavior is different from u32, the type that it would otherwise be equivalent with. In Go, it is perfectly possible to create meaningless runes. The same is true for strings by the way, safe Rust code cannot generate invalid UTF-8 values, but no such limitation exists in Go.
As I understand it, these are equivalent types between Go and Rust:
- string -> &[u8]
- rune -> i32
- byte -> u8
- []byte -> Vec
- []rune -> Vec
- [7]byte -> [u8; 7]
- [7]rune -> [i32; 7]
The other Rust types that we mentioned (char, &str, String, Vec, etc) have additional memory safety guarantees that Go does not provide.
Def one of the best, light weight (and logic dense) videos I've seen regarding rust string types from a practical standpoint (concerning aspiring Rustaceans).
Excellent vid.
At 20:50 you talk about fixed-length encoding using four bytes. This is what UTF-32 does. AFAIK none of the major languages uses it, but Python has an interesting take on it: When a string is created, the interpreter chooses the “best fit“ between ASCII, UTF-16, and UTF-32, so that constant indexing is always possible but not too much memory is wasted. This of course only works because Python strings are immutable.
Rust's char type actually is UTF-32, as far as I understand it. Which means you could get very similar functionality to a fixed character length encoding by simply using a Vec (or an &[char] to emulate a string slice), if you so wished. Granted, not all the operations that are possible for the normal string types are implemented for a Vec, but given the size of the Rust ecosystem, there's probably a library to make it possible.
I'm like 90% sure that Java `String`s are UTF-32. From my recollection, the `char` type in Java is pretty explicitly an `int` under the hood as well.
@Haniyasu char is UTF-16. But if i remember correctly, multibyte encoding does not work in Java. Could be changed now, haven't use Java since Java 8
Keep it up!! As Rust grows, you will one day be remembered as one of the O.G. Rust youtubers!
Probably the best explanation of string, utf-8, ascii types I’ve encountered in my 15 year career! Keep up the good work!
This was driving me crazy last week.
Really glad to see good, thorough showcase of this concept in Rust.
Appreciate your content! Keep at it, this will be big when Rust blows up.
Liked the little explanation of UTF-8 encoding. Thanks for making the videos. It helpful to refresh what I’ve read and get a few tips too
This earns you the title of professor. Hardly seen anything better explained than this!
learn more about utf, bytes and string on 20 min video than my 4 year of uni, thanks man ✌️
Thanks a lot! I finally understand the difference between String and &str! And it wasn't complicated, I "made" it complicated in my head. :)
awesome video, just a small thing. Newer programmers may be confused by the lookup vs search times for a character. For UTF-8 (or any variable length encoding) if you want to lookup the nth scalar or grapheme you need to do a linear walk through of the string to count off every time you get to the end of a sequence of bytes representing a scalar/grapheme but for a fixed length encoding (runes, UTF-32) you can rely on each unit (scalar/char/grapheme) being a fixed size and you can just skip (n - 1) * 4 bytes (UTF-32 uses 4 bytes per scalar) to land in the right place. Not sure if I just confused a bunch of people or added clarity for some.
UTF-32 has fixed length code points/units, but not grapheme clusters
Finally! A great explanation of what's going on between string slices and Strings -- thank you! I also appreciated your delving into unicode encoding -- I was worried you were going to rabbit hole on binary representations of a bit characters, but you did exactly the right thing in terms of explaining how unicode encoding works, how it solves the "where am I" when you have a pointer to an arbitrary byte in a unicode string (i.e. "am I at the start?" "where is the next char boundary?") -- I love that you explicitly mentioned that the first byte of a multicode byte string is differentiable based on the high order bits, and that it encodes the length of the multibyte sequence. You mentioned indexing into a Unicode string was a linear operation, which is true, but it's sub-linear in terms of number of bytes explicitly traversed -- if you have 4 4-byte unicode chars in a string, traversal takes only 4 operations, not 16, due to this clever encoding of the first byte.
Wow, this is extremely useful! I come from the Java world and it was really confuse me when working with Rust string, especially when I need to deal with ideographic characters. Thank you!
This is a great guide to a subject that has given me a ton of grief in Rust. Awesome job!
Here a brief summary of UTF-8 encoding:
- UTF-8 (Unicode Transformation Format, 8-bit) is an encoding scheme, just like ASCII, for representing Unicode characters.
- In UTF-8, ASCII characters are represented using a single byte, which means that any valid ASCII text is also valid UTF-8 text.
- Therefore, UTF8 is backward compatible with ASCII.
- In UTF-8, characters that can be represented using a single byte (i.e., ASCII characters) are represented as themselves.
- Characters that require more than one byte are encoded using a combination of multiple bytes.
- A code point refers to a numerical value assigned to each character or symbol in the Unicode standard.
- Code points are represented using hexadecimal notation and are typically prefixed with "U+" to distinguish them from other numerical values.
- For example, character "é" (Latin Small Letter E with Acute) consists of two Unicode code points: the base character "e" (U+0065) and the combining acute accent (U+0301). When encoded in UTF-8, "é" is represented by the bytes 0xC3 0xA9.
- A grapheme refers to a visual unit of a written language. It represents a single user-perceived character or a combination of characters that are displayed together.
- len() function returns the number of bytes, not the number of characters in a Unicode-unaware string.
- len() function returns the number of characters in case of a Unicode-aware string.
The thing I like about Rust is you can take a buffer out of one type and transfer it to another. Like for instance you can convert between String, Vec and Box, while keeping the same underlying buffer without reallocation and copying. Hope C++ would have this. It had node transfer in limited form for lists and in newer standard for maps.
Note that converting to a `Box` reallocates if the length is less than the capacity, but other than that, owned conversions just transfer ownership of the existing allocation.
@@SolomonUcko oh, OK. Good to know. I'm still at the very beginning at learning Rust.
I learned something new about how UTF-8 works! Thank you!
Не очікував тут побачити земляка, дякую за туторіал)
Most people say strings in rust are complicated. For me, it makes a lot of sense how it's handled. I do quite a bit of C progamming on µCs, and there everything is char*
Is rust bad for microcontrollers?
@@sconosciutosconosciuto2196 Embedded Rust usually doesn't have the full standard library. It has parts of std called core and alloc.
If your resources are limited, you can use a CString, which is null terminated and equivalent to char*.
2:04 you could create an array of chars or Vec since chars are 4 bytes long.
you are the best one to explain the difference between the two.
Namaste brother. You’re videos are too good. Keep this format going, tackling each topic standalone or mixed if it’s contextually relevant.
Thanks for this refresher, I was getting pretty rusty.
Shit just got serious
This is the first time I really understood UTF-8
I learn so much from your videos. Thanks
The super in-depth content I crave! Great video
I really like all of your videos they are one of the best out there. You mentioned that you came from a javascript background. How did you become a pro-rust-developer? did you learn the language privately and than you searched for a job or was it a fluent transition within the company you've worked in? I'm prof. C# /Typescript/Javascript developer and would like to jump on the rust-train :-)
This was great. I wish I had this when I was first learning Rust.
Your channel is so cool, thanks for putting the effort in making these tutorials.
Amazing content for a beginner! Super helpful! Thank you very much! 🙌
Привіт світ - was great!)
I started with creating char arrays in C back in the day so this isn't too crazy compared to that.
Thank you, you demystified Unicode for me, now I see how I would implement some of the UnicodeSegmentation crate myself :)
🇺🇦 Thank you for the explanation and examples!
As far as I understand in Go you take a string which is a slice of bytes and build another slice of int32, 1 per each unicode code points. So it's nothing special, or advantegious. You just paid for a a full string decoding once. This would be equivalent to chars().map(|c| c as u32).collect::() in Rust.
But because in Rust iterators are lazy you don't pay for creation of a new vector each time unless you explicitly want to.
shouldn't it be `.chars().map(|x| x as u32).collect::()`?
@@proloycodes You're correct. Fixed.
Nice and useful intro to Rust strings. Thanks :)
Okay... it's been about a month, but you can just use a Vec for constant time lookups.
A char does not equal a user perceived character. 1 user perceived character can be multiple chars.
@@letsgetrusty yeah, true
splendid and thoroughly explained. Bravo!
Great explanation of this important topic in Rust. Thank you very much!
String in Rust made my head spin. Coming from Ruby and Python string is very easy.
I have been using Python since the Python 2 days and while it seemed simpler by trying to automatically convert between unicode and bytes, this was a source for really confusing errors. In fact, Python 3 became more strict in this area by introducing the same separation between bytes and (character) strings that Rust is essentially using - which saves programmers from a lot of hard to track errors. The difference is that in Python, indexing into a string now counts the characters, which has an unexpected complexity, while Rust counts the bytes and then checks that the result is valid.
Very nice in depth video.
interesting that you see ASCII as a map from integers to characters and not a map from characters to integers :)
Great content! Can you do a video of chars in Rust and unicode scalar values? After hours of searching on the Internet, I am still confused.
You have such great videos. Learning a lot.
what an effort man.... hats off
Let's get goddamn rusty!
Fantastic explanation, thank you very much! 👍
How does Rust handle interoperability between string implementations (OSString, CString, a hypothetical UTF-32 String etc.)? Is there enough compiler sugar to pass a reference to an alternate String type to &str, or is there an "IString" trait you can implement or is there a lot of myString.as_str() involved?
it’s always manual conversions, though you have a lot of options depending on what you need - rust is super strict about not performing expensive conversions automatically (especially ones that can fail, like converting a byte string to a utf-8 string)
usually you will see something like AsRef in th3 standard library
Слава Україні! 🇺🇦🙏🏾 great seeing Ukrainian in this video
Your tutorials are the best in Rust I've seen! Your English is also gorgeous. I didn't know you were Ukrainian before this video. Glory to Ukraine 🇺🇦 from Kazakhstan 🇰🇿
18:03 Namaste!
I know about the stack and the heap (and the register), but I've never heard of the "application's binary". What is it? Do you have another video where you explain it?
Thanks!
There are a few different ways a program can get read only or read write memory.
Your executable normally contains a chunks or describes chunks or memory that it needs.
The OS then copies or creates these chunks from your program and marks them as read only or read write.
They are different sections of the program then heap and stack. That's the basics hope it makes sense.
@@dynfoxx Definitely! Thank you!
Really helpful, thanks !
Very interesting video thanks!
10:37 wow that's so cute, thank you))
very well done video.
this channel is a blessing. best explanation out there. thank you
Y U no have THANKS button? I would have bought you a pint! Thanks mate, fantastic explanation. Had some aha moments. Thanks again
I'm a little late, but what is the binary? And how does it differ from the stack and heap?
Awesome content, thanks for your work!
The proliferation of code pages was an issue many years before the world wide web hit critical mass. Not everyone developed code to run in only one Country/Region.
Hey bro, thanks for video. Do you use rust for blockchain development? The guys at Solana would love to have a series on that development on solana!
Definitely learnt unicode.. thanks!!.. wondering how this complexity is being hidden in other languages 🤔..
They usually hide this checking and validation away from you .
in js for example the engine will do it .
@@xrafter In JS they just let you make the mistakes. "🤔".length == 2, for example. And to split grapheme clusters, you will have to go find an external library, because it can't do that at all.
The only thing other languages can do is streamline the usage of the complex stuff. In Elixir, for example, they hide the concept of string normalisation by making string equality work correctly out of the box. They still have an iterator over grapheme clusters but it's in the core library so you don't have to pull a separate dependency to get it.
Older languages as a rule just get string handling wrong and push the complexity to the developer. It isn't so much hidden, as completely absent.
how do you get that type annotation automatically added - what extension is it?
really nice content man. Keep it rusty xD
Дякую за вашу працю.
FINALLY, thanks bro
Simply brilliant !!!
Outstanding video.
I am trying switch over as well from nodejs still struggling with rust..
What intrigues me is that, according to that explanation, in UTF-8 we should have 2,164,864 possibilities and not 1,112,064. So lets see:
- 1 byte characters (0xxxxxxx): 2^(7) possibilities = 128 possibilities
- 2 bytes characters (110xxxxx 10xxxxxx): 2^(11) possibilities = 2,048 possibilities
- 3 bytes characters (1110xxxx 10xxxxxx 10xxxxxx): 2^(16) possibilities = 65,536 possibilities
- 4 bytes characters (11110xxx 10xxxxxx 10xxxxxx 10xxxxxx): 2^(21) possibilities = 2,097,152 possibilities
Total possibilities of characters: 128 + 2,048 + 65,536 + 2,097,152 = 2,164,864
So why 1,112,064?
In 2003, the RFC 3629 standard for UTF-8 restricted the possible range of symbols by U+10FFFF and excluded U+D800..U+DFFF from the range, to make UTF-8 compatible with UTF-16.
@@MalleusRegum thanks for the clarification!
Great Video!!!!
I think it's really the name that's confusing. It seems better to just think of &str as an immutable reference to a string - it can be viewed but not modified. If you want to modify, you need a String. The rest of the stuff about slicing and indexing isn't really confusing, people are probably already familiar with indexing into arrays. Finally, you just have to remember that you can only index in a &str, not a String. You can learn why if you want to, but it doesn't really matter much at the end of the day.
&str: indexable, immutable
String: non-indexable, mutable
How do you get VSCode to show the type annotations for let bindings automatically?
дяка за «Привіт Світ» 😁
What's the extension you're using for type autocomplete?
Let's get rusty!
Excuse me! Can you tell me how your vscode can show type of rust variable on the left side? Thanks a lot
@Let's Get Rusty I was wondering the exact same thing
That's the rust language server.
Or should I say, Rust Analyzer extension.
I love the Namaste 🙏
"Applications binary" - is is the a static memory?
Богдан, спасибо! очень крутой материал
Thanks!
What is string slice?
Good stuff! Just getting into Rust as a mainly JS-Dev and this is by far the best content out there! One question: What VS-Code extension are you using, that shows these greyed out type-annotations and function-parameters?
It's built-in in vs code and it's generated by the Language Server and it's called inlay hints
please teach me about integers? what are integers?
How do you enter emoji in your code?
wow. I'm from JS too
Дякую (:
Thanks! 🤙
You skipped straight past the original solution to the 127 character limit which was code pages and encoding. UTF-8 was the better solution that came out of this, but UTF-8 was not widely used. UTF-16 was, but the problem with it was that it doubled the amount of memory required to represent every character, even those that could be represented by ASCII. So it was not popular because computers back in the 90's had such limited memory. UTF-8 was popular in the early 2000's, but the problem was that it was not standardised on and everybody was still using character encodings. So there was this fun problem of writing data into databases in the wrong encoding and then decoding it in the wrong way too, leading to all sorts of fun jobs for me to fix peoples databases and nobody really understood how to fix. These days this problem is all fixed (I guess, right? right guys?). But yeah, just wanted to write about how UTF-8 was NOT the original solution to the ASCII problem.
Hello, happy to subscribe to your channel. Would you please say few words why an absolute beginner would rather get more motivated to learn Rust rather than say Python (or any other language that is closer to the English language syntax, ie easier ). Thank you kindly
If you don't need to do low level systems programming then learn Python instead. It's easier and will allow you to build things quickly.
Hey do u get the warning that says something like could not access incremental compilation directory?.
Nope
looks like you are using termux cuz i also get that
what is byte?
Why is there both to_string() and to_owned()?