That is why ?. should be there.
Old code:
try!(try!(foo.bar()).baz())
“My code”:
try!(foo.bar()?.baz())
1 Like
Or pick a different operator, let’s say : just for the sake of argument, then combine them! ^.^
foo.bar():.baz()?.morestuff()
I really don’t like reading try! at the beginning, it means I have to jump back and forth when reading to see what the final type is instead of just ‘reading down the call pipe’.
1 Like
My point that I have pointed out in the RFC discussion is that ? is:|
- much harder to catch
- much harder to search for without real parser
In general IMHO ?. trades writer convenience over reader convenience, and as code is more often read than written, it is not something that I like, but now I need to live with it (and I even use it from time to time).
1 Like
Hmm? Finding ? in source code has always been exceedingly obvious for me. And unlike something like your chaining version it works with chains of not the same types, whether option, result, or something custom.
Why would you not have a parser?
For stuff like project-wide search? Because that would mean that I need separate tooling for searching in each project independently. With try! I could easily do:
rg '\btry!'
With ? you can get much more false-positives.
1 Like
Isn’t that a part of every IDE?
I’m curious what false positives? Or do you mean just because it’s a more common thing in comments or so (barely)? Also I’m unsure why you’d ever grep for ?, regardless of its name, lol. ^.^;
For me the biggest problem of Rust is that it has quite a difficult learning curve.
I would feel very comfortable writing my next web application in Rust, however I would not feel comfortable teaching a team Rust on the job. It’s quite a large time and effort investment, so I can’t justify it in a commercial setting when we could get many of the benefits for low cost with another language.
3 Likes
Knowing C++, and Haskell, Rust was utterly trivial to pick-up for me, it’s really an evolution of all of those languages, but this is what contributes to its learning curve, it has the speed and power of C++ but the safety and type system similar to Haskell (with a touch of other things). That’s not a simple topic to build on, but that is also what contributes to helping someone program well, and hence why going from Rust to other languages then you will almost definitely be a better programmer there than someone who has not learned Rust.
Honestly though, I’d still call it easier than C++. Not C though, but a whole lot safer.
3 Likes
That’s a good point! If I was working with a Haskell or C++ team I would feel more comfortable for sure. In my mind the team was used to a language like JavaScript, Elixir, Ruby, Java, etc.
3 Likes
Yeah, Rust is really one of these things to which you have to allocate a serious chunk of time and energy in order to learn well. Onboarding somebody in Rust in a work setting is quite inefficient. Only people with a ton of other background can pick it up quickly.
2 Likes
What alternative do you think best fits here?
1 Like
I think the best language (or tool in general) often depends largely on the team, with the business problem coming after that.
If I need something relatively fast like Rust, but don’t feel the team will be productive with Rust, I would consider Go for most the teams I’ve worked with. It’s not as fun to write though!
2 Likes
My biggest problems with rust are:
- The very slow compile times
- The large number of transient dependencies being pulled in when you want to use a library (which in itself makes #1 worse).
The willingness to rely so much on dependencies is what make me shy away from it (perhaps I am too old for this modern e npm ecosystem style of development). I don’t think it is maintainable in the long run. For example I added actix-web = “0.7” to my Cargo.toml file. It pulls in no less than 163 dependencies. Good luck auditing all of those and keeping them up to date as your project progresses. Compare with erlang yaws which only relies on erlang stdlib which I’m pretty sure has a lot to do with its longevity.
That said, rust is nice language and it is fast and actually not too verbose (perhaps a bit too many symbols (&,&’,*,<>,{}) which makes it look more complicated than it should). I implemented a svndump reader in elixir and rust and perhaps the elixir version was slightly more pleasant to write and read but it was not that much of a difference. And the rust one was so much faster.
2 Likes
True this! Using a C++ compiler infrastructure as the backend is fantastic for compiled code speed, but it’s of no help of compiling speed, lol.
They are working on cranelift still though, basically a fast JIT for running debug code near instantly, not as fast but it makes for a fast turnaround time. Then the final Release build will be a full optimization build. 
It can compile dependencies in parallel so it’s not that big of an issue unless you have a really really deep tree or lots of procmacro’s (macro-by-example’s are more fine) helper libraries like syn. There’s a big push to optimize a lot of these paths and remove the noise from the ecosystem, so it is getting better here too. ^.^
1 Like
The fact that x..y represents [x..y) instead of [x..y].
3 Likes
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html
Read that, like its really important about how to properly represent ranges.
However, rust does have a way to represent inclusive ranges, x..=y.
2 Likes
It does, it just makes no sense to me to why inclusiveness on one end should be represented differently from inclusiveness on the other. I believe Python does the same thing with ranges, whereas Haskell, Elixir, Erlang do not, so in this regard they are clearly superior as far as the way my brain works is concerned 
3 Likes
And now let’s take a look at ruby, where 1..10 is inclusive and 1...10 is not, or is it the other way around?
2 Likes
1...10 should be ditched 
Don’t think I have ever used it…
2 Likes
Because mathematically ranges should always be inclusive…exclusive, else a lot of math becomes just a lot harder. It’s a similar reason as to why we start at 0 instead of 1, mathematically it makes so much more sense and simplifies code and reasoning in the vast vast majority of cases. See the prior link (for note, Dijkstra is a pretty huge name in both math and programming).