Just give me Rattlesnake or CrabML and I'll stop complaining :-)
Wanted to say the same. He straight up conjured a good looking code in CrabML as an example of similar level of "ugliness", while it has about three times less syntax noise.
Rust's Ugly Syntax (2023)
41–50 of 171 posts
Re: Rust's Ugly Syntax (2023)
#42Re: Rust's Ugly Syntax (2023)
#43Kinda disingenuous, you don't reskin one language in another to make an argument about syntax -- you develop a clear syntax for a given semantics. That's what rust did not do -- it copied c++/java-ish, and that style did not support the weight. When type signatures are so complex it makes vastly more sense to separate them out, Consider, read :: AsRef(Path) -> IO.Result(Vec(U8)) pub fn read(path): inner :: &Path -> I…
Rust target user is C/C++ developer. not using brace is out of options.
Re: Rust's Ugly Syntax (2023)
#44Re: Rust's Ugly Syntax (2023)
#45Just give me Rattlesnake or CrabML and I'll stop complaining :-)
Choked on my coffee when I got to Rattlesnake. Great name.
Re: Rust's Ugly Syntax (2023)
#46I think the article makes a good point, but the actual example isn’t Rust’s worst, not even close. It gets really hard to follow code when multiple generic types are combined with lifetime markers. Then it truly becomes a mess.
IMHO the mentioned examples of complexity like multiple type variables and lifetimes with bounds are for who "really" wants compile-time contracts. These are mostly opt-in so higher level use cases(like writing backend business logics) should not care about that, just wrapping everything with Boxes and Arcs. Of course Rust is not perfect; there is some 'leakages' of low level aspects to high level like async caveats(…
I do remember the compiler constantly suggesting lifetimes to me as a newcomer to the language, so it didn't really feel that opt-in. Quite a lot of the suggestions also started to look like someone poured alphabet soup all over the code.
Re: Rust's Ugly Syntax (2023)
#47I think the article makes a good point, but the actual example isn’t Rust’s worst, not even close. It gets really hard to follow code when multiple generic types are combined with lifetime markers. Then it truly becomes a mess.
I always, always forget what `'a: 'b` means, because I remember it always being the opposite of what I think it is, but memorizing that obviously doesn't work because then it will just flip again the next time. It's so annoying.
It was a good signal to me that you are overthinking into the architecture if that is really required. Rust makes something pretty much impossible in C/C++ possible, but not necessarily easy, and that would be one such example.
Re: Rust's Ugly Syntax (2023)
#48> The next noisy element is the > constraint. It is needed because Rust loves exposing physical layout of bytes in memory as an interface, specifically for cases where that brings performance. In particular, the meaning of Path is not that it is some abstract representation of a file path, but that it is just literally a bunch of contiguous bytes in memory. I can't understand this. Isn't this for polymorphism like wh…
Rust needs to know the exact size, layout, and alignment of every argument passed to a function to determine how it gets passed(register(s) or spilled to stack) and used. For example PathBuf and String can both be turned into a reference to a Path, and while they have the same size their layout and implementation of `as_ref` differ. As for `impl`, fn foo(a: impl ToString) is syntactic sugar for fn foo (a: S) The reas…
Then if Path is not about abstraction, why not use a raw byte slice like &[u8]
Re: Rust's Ugly Syntax (2023)
#49I think the article makes a good point, but the actual example isn’t Rust’s worst, not even close. It gets really hard to follow code when multiple generic types are combined with lifetime markers. Then it truly becomes a mess.
throw in some async too and I really lose myself most of the times
Re: Rust's Ugly Syntax (2023)
#50I wonder. How does Rust syntax compares with https://www.hylo-lang.org/ syntax?
That also is memory safe, typesafe, and data-race-free.