So you just end up with python at the end?
Rust's Ugly Syntax (2023)
101–110 of 171 posts
Re: Rust's Ugly Syntax (2023)
#102My hot take is that Rust should have been a Lisp. Then it could also have had readable macros.
What if Rust was an OCaml-ish.
Re: Rust's Ugly Syntax (2023)
#103Earlier quoted context omitted.
A lifetime keyword would actually go a long way in improving ergonomics. You could even make it synonymous with '. Then people can choose. Maybe one will get much more traction and the other can be deprecated.
why? It makes type information unnecessarily longer without adding information, and feels like writing "end_stm" instead of ";" after every line
It's more like if a ; was allowed somewhere else and had a different meaning there.
enum foo; blah ...;
Re: Rust's Ugly Syntax (2023)
#104Earlier quoted context omitted.
That's because the code triggering compilation error is using reference. If you use Rc or Arc (which pays runtime cost) there should be no lifetime at all. Albeit I admit there somewhat exists a community sentiment like "if you use Rust, you should maximize its zero cost abstraction feature so lifetime is good and generics good", and my (minor) opinion is that, it's not always true to all users of Rust. And the clums…
> And the clumsy Arc >> makes users feel bad about using runtime cost paid types Yeah, this would look worse than any of the "complicated syntax" examples in the blog post. A language should be designed so that the typical case is the easiest to read and write. Syntax for the most common abstractions. Rust forces you to be explicit if you want to do an Arc >>, but lets you inherit lifetimes almost seamlessly. That me…
Simple != idiomatic. It's perfectly idiomatic to `Arc>` in Rust, and it is more complex because it deals with more concerns than a simple reference, namely being thread-safe. Sometimes you need that, sometimes not, but you have to be explicit about it.
Re: Rust's Ugly Syntax (2023)
#105People that complain about Rust's syntax never have never seen C++ at its worst
Re: Rust's Ugly Syntax (2023)
#106Earlier quoted context omitted.
why? It makes type information unnecessarily longer without adding information, and feels like writing "end_stm" instead of ";" after every line
That's the trade off isn't it. ' is unnecessarily short and doesn't convey any information at all, or worse, the wrong information. There are other comments that point out that ' is valid in identifier, or used to indicate that something is derived from something else. Some will prefer the short nature of just typing ', where people like me would prefer that you just add a few more characters so it reads more easily.
It is, but not a trade off many would make.
' itself (!) may not convey information, but it's existence does convey information.
While making it a keyword may help beginners to understand code and wish they could see the meaning directly, because they don't know the meaning of certain symbols yet, people who know the language and productively produce code are more concerned about content rather than syntax.
Content meaning the name of the life time, the name of the types, the name parameters, the structure of the types, the constraints on the types, etc.
Especially for Rust, there is a lot of the things mentioned above, and since the concepts in Rust aren't easy, it's important that these things get as much space as possible from the limited space on the screen, instead of wasting it by self explaining syntax elements, which are trivial to memorize.
Thus { instead of begin_function_body, *; instead of statement_end, ? instead of 'if err != nil then return err' and ' instead of lifetime.
Re: Rust's Ugly Syntax (2023)
#107Earlier quoted context omitted.
why? It makes type information unnecessarily longer without adding information, and feels like writing "end_stm" instead of ";" after every line
It's more like if a ; was allowed somewhere else and had a different meaning there. enum foo; blah ...;
like parenthesis for functions, tuples and for denoting prioritized evaluation?
Re: Rust's Ugly Syntax (2023)
#108Earlier quoted context omitted.
When GP said “most”, I interpreted it more broadly. Most applications simply do not require the guarantees of a non-GC language. When you expand that horizon, list of contenders becomes considerably larger - even when restricted to statically typed languages.
Yes for example many Python users switched to Go, a native code GC language, and are satisfied with the performance. There’s also the middle ground of Swift’s memory management which uses compiler-elided refcounting - i.e. the compiler detects when a count goes up then down again and removes those operations.
> There’s also the middle ground of Swift’s memory management which uses compiler-elided refcounting - i.e. the compiler detects when a count goes up then down again and removes those operations.
In the face of threading that's not a safe optimisation; if another thread decrements the refcount inbetween those two removed operations, boom. The compiler will have to track every variable that crosses threads or something.
EDIT: spelling
Re: Rust's Ugly Syntax (2023)
#109Aw, no Rasp variant? Let's brainstorm it up...
(defun read (path)
(declare (generic P (AsRef Path))
(type P path)
(returns (io:Result (Vector U8))))
(flet ((inner (path)
(declare (type (Ref Path) p)
(returns (io:Result (Vector U8))))
(try-let ((file (File:open path))
(bytes (vector)))
(declare (mutable file bytes))
(try (read-to-end file bytes)
(Ok bytes)))))
(inner (as-ref path))))Re: Rust's Ugly Syntax (2023)
#110Earlier quoted context omitted.
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.
It ends in ";;". If that's not a typo, and it's semantically significant that there are two semicolons instead of one, that sounds quite finicky.
The answer to the question “When do I need the ;; within OCaml source code?” is never.
It's not a part of the language and is only used by the interpreter as an end of input mark.
Historical note: In CAML Light, the predecessor of OCaml, double semicolons were mandatory. For this reason they are quite common in old code originally written in CAML Light or written in the early days of OCaml. These days they are considered a bad style.