I'm experimenting with #Rust again, and my eyes always bleed with the "lifetime annotation syntax" - why does it have to use an apostrophe 馃槱 .
&'a mut i32
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
impl<'a> System<'a> for LeftWalker {
type SystemData = (ReadStorage<'a, LeftMover>,
WriteStorage<'a, Position>);
But this time I'll try not to rage quit in digust again. I'll stick until this experiment ends. #rustlang
Another one:
- Generics in every language: Vector<MyType>()
- Rust:
Nope:
Vec<u32>::new();
This works:
Vec::<u32>::new();
And this ALSO works:
(Vec <u32)>::new();
So I can't use the universal language of: Vec<u32>::new();
But I can do (Vec <u32)>::new();
What kind of syntax is that? For the past 28yrs I used more than 12+ langs in every kind of project & the ugliest language I've seen is Rust.
Yes, EVEN UGLIER THAN ERLANG, at least Erlang is consistent and makes sense.
DREAM:
- Systems programming language w/ the safety of Rust
- a package manager
- the ecosystem/community size of Rust
- C/C++ tooling (debugger and LS)
- C/C++ interop
- ALL OF THAT with a Ruby-like syntax
The answer could be Crystal, but unfortunately it has a tiny tiny ecosystem and Windows is a 2nd class citizen and Crystal has probably the slowest compiler on Earth.
Nim is probably the answer (it's Pascal-like), but Nim loses on tooling.
Other suggestions?
TIL
Rust's `::<>` is called turbofish!
https://github.com/rust-lang/rust/blob/master/tests/ui/parser/bastion-of-the-turbofish.rs
https://turbo.fish/
Not everything is ugly with the #RustLang syntax! I just stumbled upon two pieces of #Rust code that I found to be elegant.
I just love pattern matching.
@adolfoneto I don't know in terms of what is accepted in the Rust world in general since I'm still not that much involved with it.
But as compared to the rest of the syntax which can be really ugly, alien and esoteric, I personally found those 2 segments to be elegant.
@berkes Elixir is the queen of pattern matching, but it's not because it's dynamic, it's because it's a functional immutable language. In Elixir you rarely (or never) use if's, loops and the like, instead, you rely on pattern matching functions and cases, everything is pure.
I'm working w/ Elixir right now & in the screenshot is a function I was looking at, it's all the same function, but with different matches.
(also I work with Elixir full time since 2015, so also I might be biased too)
In my opinion, for the first piece, this is slightly better.
@mo8it oh no problem with Rust's LS.
The main point is that I want: "ALL OF THAT with a Ruby-like syntax"
@alfredbaudisch For me personally, although I had experience in C++, I did not like the syntax of Rust at the beginning. I wished a syntax like that of Python or Julia.
But this picture is the best description of my experience:
https://infosec.exchange/@AstraKernel/109628938569008449
After understanding more of the concepts behind the syntax (for example lifetimes etc.), I do appreciate the syntax. At the end, a statically typed general purpose language that can be used as a low level one can not look like Python or Ruby.
Attached: 1 image #Rust #rustlang #rustaceans #rusties
use instead of using
fn instead of function or even def
Rc, Arc, Cow, etc. All very good abbreviations (that last one is also funny :P)
i64 instead of Int64
f64 instead of Float64
...
I don't say that it is perfect. Indeed, I don't know if turbo fish was the best solution... Maybe it was the easiest solution, but I would not say that it is good piece of syntax.
What I want to say is: The subjective impression of the syntax changes while digging deeper ;)
@mo8it
"a statically typed general purpose language that can be used as a low level one can not look like Python or Ruby."
Actually Crystal is exactly that: https://crystal-lang.org/
It even has C and C++ interop, but unfortunately it didn't take off.
Crystal is low level while looking almost identical to Ruby, being very beautiful and readable.
Unfortunately, the catch is that a simple "hello world" can take 30 seconds to compile.
@gustav I agree with both of your statements and think my Rust experiment will end in failure once again due to that, I just cannot convey the ugliness (especially because the language I use for my full time work since 2015 is Elixir, and Elixir is all about being simple and elegant, yet EXTREMELY powerful).
Of course on side projects and experiments I use all kinds of languages, but still most of my heart is on Elixir since 2015, so I'm biased towards that.
@gustav @alfredbaudisch Every unfamiliar language looks like a complicated alien language if you are used to a specific style of other languages.
The subjective opinion of me and others I know is that Rust is not as complicated as C++ after you learn it. I did work with both C++ and Rust. Rust is not even comparable to the legacy complexity of C++.
Can you really look at this documentation page of "modern C++" and still call Rust uglier?
@alfredbaudisch It's not on version 1 yet, so I wouldn't recommend it for production use, but have you looked at V lang? Maybe something to keep an eye on.
@adpbsc From what I have seem in the website and some sample code, I'm in love! Now I'm going to experiment with it to come to a conclusion.
Thanks!
@berkes it's kind of self-explanatory. It would be a syntax that is similar to Ruby, as opposed to being C-like.
- Screenshots 1, 2 and 4: Elixir, (the power of Erlang but with Ruby-like syntax).
- Screenshot 3: Crystal (a low level language, but Ruby flavored).
I.e.:
- No ; and no {} blocks
- snake_case
- Favor expressiveness
- Favor clarity (so no &, *, <> everywhere)
@alfredbaudisch all those languages "lack" features though. No type constraints, no borrowing/memory fiddling.
Scoping and closures aren't controllable.
So a lot of the "clarity" seems to come from "not having these features".
Sure, rust-ish could have do-end instead of {}, remove ;, or have unless or even postfix "if". but does that really make a big difference? Is that what makes Ruby, Crystal or Elixir more readable?
Or is it the memory model, omission of types and features?
@berkes
> Is that what makes Ruby, Crystal or Elixir more readable?
Yes, keeping as close to English as possible is what makes those languages more pleasing to the eyes.
The simple removal of ";" and "{}" do great work already.
> all those languages "lack" features though.
Ruby? Sure. But Elixir? Elixir is not the fastest language out there, but it has processes, supervisors, distribution, self-healing and more out of the box, while being Ruby-like!
@berkes but then Elixir is not meant for Desktop applications, so that's why I'm seeking other alternatives. Otherwise, I'd also stick with Elixir for that.
My intended usage would fit Elixir processes perfectly, i.e. 100s of thousands of parallel, self-contained and isolated individual entities with a background of culture and needs evolving in real-time - this is a breeze AND REALLY EASY to do with Elixir (and safe for being immutable).
@alfredbaudisch maybe that's more the actors pattern than language syntax?
In rust, there's actix, tokio-rs, riker or any of the many actors libs that offer the same. 3rd party, so not as available as in elixir, but the outcome is the same.
I love the actor pattern. Used it in Ruby (w celluloid), Go, Rust and Erlang. Erlang's is the most natural, and mature, but still a bit of a leaky abstraction.
@berkes I know the Elixir stuff is not because of syntax, I cited them because you said "they are Ruby-like but maybe they lack features" - yes they lack low level memory management et all, but definitely then you have all that other pros (in Elixir the Erlang VM and OTP and the Actor model for "free", etc).
Anyway thanks for the tokio recommendation. I'll experiment with it this week - seems right up my alley :)
@alfredbaudisch I've dabbled with actix, tokio-rs, a DIY actor system (not too hard) and Riker.
Riker is, by far, my favorite. Best documentation, simple and complete. Main downside is that it appears abandoned. Last commit over 2y ago馃槺.
If you find anything better, please let me know:)
@alfredbaudisch That's a bug in your LSP, see how it thinks it's a bool? It's interpreting the < and > as comparisons.
If you actually compile it then you get the errors you should be https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b83316313aed20276a5fd9a8b5f7a8c8
@salsagal found the full code, it compiles, but yeah as a bool: https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=6953e52ea50aaea2e25468796e3c9511
But that's the point of my rant (ugly ass syntax):
- Every language that has generics, at least C-based languages follow Vec<type>()
Rust when faced with `<` thinks it's a comparison operator, so you need: `Vec::<type>`
@alfredbaudisch @salsagal the point of the ::<T> syntax is explicitly to disambiguate the case you're showing here with comparison operators. I won't argue that it's elegant, but it does the job 馃槈
There's a fantastically mad test case around parsing this sort of thing in rustic itself: https://github.com/rust-lang/rust/blob/master/tests/ui/parser/bastion-of-the-turbofish.rs
Vec::<u32>::new() is a general syntax used for adding generics when calling a function.
(Vec<u32>)::new() does not work because it tries to interpret stuff in () as an expression.
<Vec<u32>>::new() works because <> are like () but for types. This is often used to call a function from a specific trait when multiple options exist. example: trait A has do_thing(), trait B too, but want to call that of trait A:
```
let v = Vec::new();
// these are equivalent due to the argument allowing type inference
<Vec<u32> as A>::do_thing(&v);
A::do_thing(&v);
// this one needs the cast to know which type that implements B to call it on
<Vec<u32> as B>::do_thing();
```
playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0e2187a7649ab5f3caeb1ce56d63970b
@alfredbaudisch it's a you problem.
(I don't especially like Rust syntax, but it's very fine in practice.)
@alfredbaudisch
Where did you got (Vec <u32)>::new() working ???
If this compiles then there is a bug. It does not compile for me in nightly 1.72.0 2023-06-20.
About the needed "::", it's because type and paths are two different things. A method or an associated type implies a path (with all the :: everywhere), but a generic type is just a type.
This seems ugly but it's actually needed to avoid some ambiguous situations where the < > may be interpreted as comparisons.
Alfred R. Baudisch
Adolfo Neto
Sergey Bugaev
ccQpein
B猫r Kessels 馃悵 馃殣 馃弰 馃尡
Tricky Fat Cat
Sekhat Temporus
Josu茅 Boisvert 
Mo Bitar 
gustav
Anthony Perrett
Brian Kung
SalsaGal
Sminez 
TudbuT
webshinra
tuxmain