The whole "book" seems to be AI-generated, or at least very heavily AI-edited. Would at this point it not be easier to just tell developers to use their LLM of choice to achieve the same (or, likely, better) result?
I wonder when LLMs will catch up with the new timelines, they frequently cite days/weeks of worth, then you say "Ok, implement that" and 30 minutes later everything been implemented. But seems they themselves is stuck not realizing they're not estimating for human timeframes anymore.
I can't recommend Rust enough. It has such a bad reputation, but it isn't that hard. I truly think it's easier than many languages with much less-intimidating reputations.
That said, one of the places Rust loses people pretty early on is an example they have early in this intro:
```rust
let parts: Vec<&str> = "a,b,c".split(',').collect(); // Vec<&str>
```
I never understood why Rust didn't / couldn't make functions able to return different outputs depending on context. If you chain `.split()` to something else that can take an iterator, you want to pass an iterator. If you don't, ~99% of people would probably rather have a collected array. And if you want an `it`, you could just do `.it()` or this is when type inference could be overloaded and you could do:
```rust
let it: Split<'_, char> = "a,b,c".split(',');
```
I think Rust should've put more effort into making the thing newbs want to do the default, and easy ways to get the most efficient thing for experts.
```rust
let parts = "a,b,c".split(); // Gives an Array/Vec
let count = "a,b,c".split().count(); // Optimized stream, no array allocation
```
It could work like that, and I think almost everyone would be happy. But it doesn't.
Instead, they've created a language that I think could have been nearly as easy as a scripting language, but isn't.
It obviously isn't only collection iterators this applies to. There's dozens of very small places that add up and make what - I believe - is an otherwise relatively easy and sensible language feel too far out of reach for too many people.
`Option<T>`, `Result<T, E>`, `Future<T>` all impact linguistically how you can interact with a Type. I think the impacts of this don't make sense to people who've never encountered this before. `Arc<T>`, `Rc<T>`, `Mutex<T>`, and `RwLock<T>`, etc also have similar consequences.
Not only do people just not get it. But also, the type system quickly becomes "scary". To do pretty basic concurrency, you need to build a pretty "scary" looking type if you come from Python.
Which is why I'm a psychopath and attempting to create a language where it defaults to the things most people want, and it's very easy for experts to override.
Having the result type of a function change based on context sounds like a horrible idea because it would introduce tons of unnecessary ambiguity. If it's an issue that you have to chain one extra collect call, just write a helper function for splitting that returns a vec.
> Having the result type of a function change based on context sounds like a horrible idea because it would introduce tons of unnecessary ambiguity.
I think you're assuming the language won't warn you if you're doing something cost ineffective, and that there aren't modes to compilation which will make you make things explicit whenever its ambiguous.
For a person to get started, they should be able to compile in `easy` mode and do things that make sense to them, and the compiler should only bitch at you to be pedantic when you ask for that.
Especially because an LLM can probably do that pedantic part for you.
You: write code almost as high level as a scripting language, it works, turn on strict mode, most of the time you get auto-fix solutions/options from the compiler.
That's my opinion anyhow. I assume most Rust people won't like it. That's fine. You already have your language!
I'm not trying to make a slightly different Rust for Rust people...
I'm trying to make Rust more accessible to everyone else.
> I never understood why Rust didn't / couldn't make functions able to return different outputs depending on context
Referential transparency probably being the first reason I could see. Having the behaviour of a callee sounds horrible and something we usually try to actively work against, you want to be able to look at the function in isolation and be able to understand how it works and what values it gives back, without jumping around and seeing where it's being called.
And yes, I'd agree with your last part, you do sound a bit like a psychopath ;) With that said, the world needs those too, so I hope your experiment is fun and brings you lots of learnings, enjoy! :)
The whole "book" seems to be AI-generated, or at least very heavily AI-edited. Would at this point it not be easier to just tell developers to use their LLM of choice to achieve the same (or, likely, better) result?
Random chapter so you can judge the quality for yourself: https://microsoft.github.io/RustTraining/python-book/ch09-er...
And the non-stop bullet list slop just looks horrible: https://microsoft.github.io/RustTraining/python-book/ch01-in...
Seems like this isn't limited to the Python book though, and others have the same issues: https://github.com/microsoft/RustTraining/issues/14
This tutorial is very bad, and the time estimates are pretty absurd.
The explanations are extremely short and I imagine a new Rust dev would not understand what is going on.
The Brown tutorial is far better, compare its section on mutables and ownership to this.
And yes, this entirely thing is AI generated. Why was this created?
Link to the Brown tutorial: https://rust-book.cs.brown.edu/
> and the time estimates are pretty absurd.
I wonder when LLMs will catch up with the new timelines, they frequently cite days/weeks of worth, then you say "Ok, implement that" and 30 minutes later everything been implemented. But seems they themselves is stuck not realizing they're not estimating for human timeframes anymore.
I can't recommend Rust enough. It has such a bad reputation, but it isn't that hard. I truly think it's easier than many languages with much less-intimidating reputations.
That said, one of the places Rust loses people pretty early on is an example they have early in this intro:
```rust
let parts: Vec<&str> = "a,b,c".split(',').collect(); // Vec<&str>
```
I never understood why Rust didn't / couldn't make functions able to return different outputs depending on context. If you chain `.split()` to something else that can take an iterator, you want to pass an iterator. If you don't, ~99% of people would probably rather have a collected array. And if you want an `it`, you could just do `.it()` or this is when type inference could be overloaded and you could do:
```rust
let it: Split<'_, char> = "a,b,c".split(',');
```
I think Rust should've put more effort into making the thing newbs want to do the default, and easy ways to get the most efficient thing for experts.
```rust
let parts = "a,b,c".split(); // Gives an Array/Vec
let count = "a,b,c".split().count(); // Optimized stream, no array allocation
```
It could work like that, and I think almost everyone would be happy. But it doesn't.
Instead, they've created a language that I think could have been nearly as easy as a scripting language, but isn't.
It obviously isn't only collection iterators this applies to. There's dozens of very small places that add up and make what - I believe - is an otherwise relatively easy and sensible language feel too far out of reach for too many people.
`Option<T>`, `Result<T, E>`, `Future<T>` all impact linguistically how you can interact with a Type. I think the impacts of this don't make sense to people who've never encountered this before. `Arc<T>`, `Rc<T>`, `Mutex<T>`, and `RwLock<T>`, etc also have similar consequences.
Not only do people just not get it. But also, the type system quickly becomes "scary". To do pretty basic concurrency, you need to build a pretty "scary" looking type if you come from Python.
Which is why I'm a psychopath and attempting to create a language where it defaults to the things most people want, and it's very easy for experts to override.
Having the result type of a function change based on context sounds like a horrible idea because it would introduce tons of unnecessary ambiguity. If it's an issue that you have to chain one extra collect call, just write a helper function for splitting that returns a vec.
> Having the result type of a function change based on context sounds like a horrible idea because it would introduce tons of unnecessary ambiguity.
I think you're assuming the language won't warn you if you're doing something cost ineffective, and that there aren't modes to compilation which will make you make things explicit whenever its ambiguous.
For a person to get started, they should be able to compile in `easy` mode and do things that make sense to them, and the compiler should only bitch at you to be pedantic when you ask for that.
Especially because an LLM can probably do that pedantic part for you.
You: write code almost as high level as a scripting language, it works, turn on strict mode, most of the time you get auto-fix solutions/options from the compiler.
That's my opinion anyhow. I assume most Rust people won't like it. That's fine. You already have your language!
I'm not trying to make a slightly different Rust for Rust people...
I'm trying to make Rust more accessible to everyone else.
> I never understood why Rust didn't / couldn't make functions able to return different outputs depending on context
Referential transparency probably being the first reason I could see. Having the behaviour of a callee sounds horrible and something we usually try to actively work against, you want to be able to look at the function in isolation and be able to understand how it works and what values it gives back, without jumping around and seeing where it's being called.
And yes, I'd agree with your last part, you do sound a bit like a psychopath ;) With that said, the world needs those too, so I hope your experiment is fun and brings you lots of learnings, enjoy! :)