I can actually see where this is coming from, as I found Rust hard to read when I started out. I do really like Rust for reference, but I do agree Rust is hard to read for someone that has not learned it.
For example:
return statements that are implicit just because the semicolon isn’t there. Even better if they occur inside a if block or something like that. Very hard to understanding when you don’t know the syntax rules.
Lambda functions, especially when using move semantics too. They are quite simple, but if you don’t know the meaning, it’s more arcane characters. Especially when this is used inside lots of chained methods, and maybe a multi-line function in the lambda.
A lot for the if let x =… type of stataments are tough the first time around. Same for match statements.
Defining types for use with function::<Type>() and such.
Lifetimes, especially when they are all named a, b, c etc. It quickly gets messy, especially when combined with generics or explicitly defined types.
Macros, though not entry level rust to begin with, they are really cumbersome to decode.
None of these are sins of Rust, but for new people they are a hill to climb, and often hard to just “get” based on previous programming experience and reading the code. Rust can be really hard to approach because of these things. This happens in other languages too, but I do feel Rust has a particularly large amount of new concepts or ways to do something. And this is on top of learning lifetimes and borrow semantics.
This is the most sober take in this thread. I was bothered by all these things you mentioned for the first two weeks of using the language. I begrudgingly accepted them for the following two months because I felt the benefits of the language were worth it. Now all of these things feel natural and I don’t give them a second thought.
They might not be strictly language issues, but if they are symptomatic of idiomatic rust then they are “sins of rust”. Something about the language promotes writing it using these kinds of idioms.
Just like French speakers don’t pronounce 80% of the written syllables because it’s impractical to speak fast with all of them…language features (or lack of them) drive how the language is used.
(BTW the implicit return behaviour on a missing semicolon sounds like Chekhov’s footgun)
Something about the language promotes writing it using these kinds of idioms.
As someone who has used Rust professionally for 3 years, the idioms are good. I wouldn’t want the idioms to go away, and I don’t particularly want the style/aesthetics of the language to change unless it can be done without negatively affecting the idioms.
It’s not a situation where the aesthetics are actually bad, it’s just different than what most programmers are used to, but almost all of the differences are for pretty good reasons. With enough familiarity and practice you’ll start to recognize those differences as benefits of the language rather than detriments.
But I think a lot of people have so much inertia about tweaking their way of thinking that they don’t feel motivated to try long enough to make it over that hump, especially when their expectations get set by rabid Rust promoters like myself who insist that Rust is vastly superior to any other languages in almost all situations. The stark contrast between how good they’re told the language is and how they feel when first exposed to it might be too much whiplash for some people.
I recognise that different languages have different styles, strengths and idioms. One of my pain points is when people write every language as if it’s naughties java. Enough with the enterprise OoP crap.
I’ve also learnt languages like Haskell to expand and challenge the way I think about software problems. I learnt a lot doing it. That doesn’t stop a lot of Haskell code looking like line noise to me because it over-uses symbols and it being close to impenetrable in a lot of cases when you read somebody else’s code.
I think the aesthetics of Rust are the wrong side of the line. Not as bad as something like Haskell (or Perl), but still objectionable. Some things seem to be different even though there’s pre-existing notation. Things seem to be dense, magical, and for the compilers benefit over the readers (as an outsider).
I’ve been learning Zig recently and the only notational aspect I struggled with was the pointer/slice notation as there’s 5 or 6 similar forms that mean fairly different things. It has other new concepts and idioms to learn, but on the whole it’s notation is fairly traditional. That has made reading code a lot more approachable (…which is a good thing because the documentation for some aspects sucks).
I’m not sure, what you mean by “Chekhov’s footgun”, but well, it isn’t a footgun, so you won’t accidentally return a wrong value from the function, if that’s what you’re thinking.
It’s not a Rust invention, most functional programming languages have implicit returns, but basically think less of them as a function return and more just as the value that a scope evaluates to.
So, here’s a simple example:
letsum = {
letx = 5 + 9;
3 * x
};
Obviously, this is an extremely contrived example, but yeah, as you can see, it does not even have to involve a function. The implicit return makes it so that sum is set to the result from 3 * x.
And the scope-braces are nice here, because you can do intermediate steps without having x in scope for the rest of your function.
In practice, if you see scope-braces and the line at the end does not have a semicolon, then that’s the value that the whole scope evaluates to. Those scope-braces can also be the braces of a function, but then you need to annotate what the function is going to return, too, so it’s practically impossible to return a wrong value.
Well, and I would actually argue that explicit returns are a footgun in comparison.
Because someone might introduce clean-up code at the end of the function and not realize that an explicit return skips that clean-up code, somewhere further up in the function.
The implicit return always has to be at the end of the scope, so it’s not possible to accidentally skip code.
The implicit return is perhaps the most dubious of them. I don’t mind it for simple functions, but they are not so good in anything large and with multiple return sites. Even more so when developers choose to implicitly return 4 chained method calls inside a closure with else cases.
But the rest aren’t really sins, they are mostly new or different concepts or ways to do something. And if there is a sin, it’s largely because the language itself has a complexity larger than others.
Taking my own examples here, lambdas are just fine, but the move semantics are cumbersome to deal with. But we need to do it some way, to indicate that a value is actually being moved into the closure. Maybe there are better ways and they make into the language in the future.
Conditional values and let statements and such is a good consequence of Rusts design choice with returning Results or Option types. Just because it’s different doesn’t make it a sin. Just takes time to learn the right way. I think most come from an exception based language, and that has a differnet code flow than what Rust has.
Lifetimes are hard though, and I feel a lot of the introduction is made excessively hard with the simple naming. It’s as of every programming tutorial used single letter variable names. Lifetimes isn’t something I’m that good with either, mostly because I haven’t had to use that complexity yet.
Maybe Emacs has fried my brain, but that is perfectly readable. Common Lisp has one of the most advanced object systems around, so yea you can write hard to read stuff if you want
Entirely readable to someone who knows Common Lisp, and unreadable to someone who doesn’t know any kind of Lisp. Mostly readable to someone who knows Emacs Lisp, Clojure, or Scheme.
Being able to correctly guess what the syntax does without knowing the language is a function of similarity to familiar languages more often than it is a characteristic of the syntax itself.
I imagine the tricky part for someone unfamiliar with Lisp would be that there’s no syntactic clue that a particular thing is a macro or special form that’s going to treat its arguments differently from a function call. Someone who knows Scheme may have never seen anything like CLOS, but would see from context that defmethod must not be a function.
You don’t even need to define a class to define methods. I’m sure that’s surprising to people coming from today’s popular language, but the original comment was about syntax.
Whether Lisp syntax is ugly is a matter of taste, but it’s objectively not unreadable.
In most languages, I would agree with that. In Lisp, I think I might not. If Common Lisp didn’t come with CLOS, you could implement it as a library, and that is not true of the object systems of the vast majority of languages.
Sorry, I love Rust but I can’t really agree with you here. They only showed a macro_rules!definition, which is definitely rust syntax. Lifetime annotations are relatively common.
I will concede that loop labels are incredibly rare though.
Loop labels are rare, but they lead to much simpler/clearer code when you need them. Consider how you would implement this kind of loop in a language without loop variables:
'outer: while (...) {
'inner: while (...) {
if (...) {
// this breaks out of the outer loop, not just the inner loopbreak'outer;
}
}
// some code here
}
In C/C++ you’d need to do something like
bool condition = false;
while (...) {
while (...) {
if (...) {
condition = true;
break;
}
}
if (condition) {
break;
}
// some code here
}
Personally, I wouldn’t call it ugly, either, but that’s mostly a matter of taste
Well, you’d typically put the loops into a function and then do an explicit return to jump out of there. I believe, there’s some use-cases where this isn’t possible, which is why I’m cool with loop labels existing, but I’ve been coding Rust for seven years and have not needed them once…
I guess I see what you mean if we want to get very technical about what a syntax extension is. But I think for the purpose of this discussion, it’s reasonable to think of macro_rules! as a part of the Rust language. Practically speaking, it is syntax provided by the language team, not just users of the language who are free to extend the syntax by usingmacro_rules! to do so.
You used macro_rules, which is not common at all. Most rust files don’t contain any macro definition.
This code doesn’t even compile. There is a random function definition, and then there are loose statements not inside any code block.
The loop is also annotated, which is not common at all, and when loops are annotated it’s a blessing for readability. Additionally, the loop (+annotation) is indented for some reason.
And the loop doesn’t contain any codeblock. Just an opening bracket.
Also, the function definition contains a lifetime annotation. While they are not uncommon, I wouldn’t say the average rust function contains them. Of course their frequency changes a lot depending on context, but in my experience most functions I write/read don’t have lifetime annotations at all.
Yes, what you wrote somewhat resembles rust. But it is in no way average rust code.
Definitely not your average Rust code, more like a very ugly example of it.
Also, as the syntax first put me off as well, I gave it a chance years afterwards, and have now (or rather years ago) officially joined the church of Rust evangelism.
A lot of the syntax you define as ugly makes sense when you learn it, it’s just so much more explicit than a more dynamic language, but that exactly saves your ass a lot (it did for me at the very least) (I don’t mean macros, macros are ugly and should be avoided if possible)
You can’t imagine how often I just sweared today about js. What did go through the mind of their designers, when they created this growing disease, and why did web browsers accept this as the lingua franca for the web. So… much… pain…
well if you are recompiling thousands of crates with a single thread, for a simple webapp no less, then you are doing something wrong. multiple things, actually, I count 3.
Actually, my (not that small) Rust projects now take officially less time to cold compile than the “hot” reloading of our next.js monster in my job. Incremental compilation is at least an order of magnitude faster. And cherry on top, dumb code is often 100x faster than js.
Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
Whatever your place defines as a standard. I’ve seen ugly code in C, JavaScript, Java, etc., that uses them all over the place because they’re not mandatory.
If you don’t have consistent indenting, your code looks like copy/paste from several sources; but if you do have consistent indenting, then the indenting of Python is a non-issue.
Haskell has the choice of both indentation based and brackets for things like do blocks, but most people use indentation based cause it’s the norm and looks cleaner
List comprehensions are much stranger than tabs vs spaces. There are very very very few languages that use them, and python’s is by far the worst out of the popular ones.
I’m not saying I don’t understand them. I’m saying the syntax is terrible. Compare it to Ruby (or any other modern language) and it’s abundantly clear.
python (uses syntax not available in any other top 25 language)
print([j**2 for j in [2, 3, 4, 5]]) # => [4, 9, 16, 25]
ruby (normal chain syntax with map)
puts [2, 3, 4, 5].map{|j| j**2}
even kotlin is more readable, even though you have to convert to a double and back
kotlin
val list = listOf(1,2,3,4)
println(list.map{it.toDouble().pow(2.0).toInt()})
For nested cases it’s even more apparent:
python
digits = [1, 2, 3]
chars = ['a', 'b', 'c']
print([str(d)+ch for d in digits for ch in chars if d >= 2if ch == 'a'])
# => ['2a', '3a']
val digits = listOf(1, 2, 3)
val chars = listOf('a', 'b', 'c')
println(digits.flatMap { d ->
chars.filter { ch -> d >= 2 && ch == 'a' }.map { ch -> "${d}${ch}" }})
just from a base level, you have to read the middle of the comprehension first, then the end, then the beginning. It’s a completely backwards way to write and read code. unlike other languages that use a ‘functional’ approach, where it’s chained methods or pipes, etc. Even Elixir, which does have list comprehensions, reads and writes in the proper order:
This is the one thing I hate about python, because the spacing would differ between editors. I used vim to create the files on one system, and geany to edit them on another. Via uses 8 spaces in a tab (at least for me), while geany uses 4. This makes python mad, and drives me crazy.
Also, the rules for whitespace separation between things like loops, methods, and the rest of the code is annoying/ wierd (at least to me).
and that indentation defaults in decent editors are usually language dependent. I’m not familiar with these editors, but… come on - if they use one default for all files, OP should use a better tool.
Yes, but I don’t normally program in python, so I never did. When I had to, I never thought of changing it (it wasn’t for long anyways and was less of a thought out decision to do programming in vim)
One of the reasons i find it so hard to use non-Rust languages is how ugly they typically are by comparison. “fn” instead of “function” is such a great example of saving key presses where they’re most needed. And you get very used to seeing compact abbreviations. Idk if that’s what you’re talking about though.
C++ is even worse, due to templates and the so-called most vexing parse. Initializing with {} mitigated the latter somewhat, but came with its own set of woes
To be honest, I think, they both have their place. In Rust, you typically wouldn’t return just a bool, but rather the element that you removed, so like this:
I believe that it is useful in a few places. cppreference.com mentions templates as one case:
Trailing return type, useful if the return type depends on argument names, such as template<class T, class U> auto add(T t, U u) -> decltype(t + u); or is complicated, such as in auto fpif(int)->int(*)(int)
The syntax also matches that of lambdas, though I’m not sure that adding another way of specifying regular functions actually makes the language more consistent, since most code still uses the old style.
Additionally, the scope of the return type matches the function meaning that you can do
“fn” was just one example. There’s also other abbreviations like “pub”, “impl”, “extern”, “mut”, “ref”, “bool”, “u64” And it’s true that some of these keywords are only relevant in Rust, however other langues have their own specific keywords, and they tend to be longer. In languages like Java (which is the worst example I can think of), you see things like “private static boolean” as function definition. In c++, you have to type “unsigned long” or even “unsigned long long” to represent “u64” (depending on data model).
I really don’t agree with saving keypresses being a useful metric, since auto-completion is a thing and code is read significantly more often than it is written. I am also a staunch opponent of abbreviations being used for variable names.
But I will say that I don’t mind abbreviations in keywords, since well, you need to learn the meaning either way.
And yeah, I’ve come to somewhat like them being used for keywords, since it reduces visual noise where it really isn’t useful, and it distinguishes keywords from actual code.
Ultimately, keywords are just syntax where letters were used instead of a symbol. You do read them like a symbol, so if they don’t look like a real word, that seems to work quite well for my brain.
Ooh yeah, overall coding culture is definitely not affected by the preferred nomenclature for identifiers. The person who’s habituated to fn over function will absolutely never name their functions in the vein of chkdsk. The two are completely disconnected in the brain of the programmer who read too much K&R in their childhood and was irretrievably traumatized by it for life.
I’d say it’s much more influential the names of the identifiers of the standard library.
A language with function keyword that names it’s stdlib functions strstr and strtok will inspire way worse naming than on that has fn keyword with stdlib functions str::contains and str::split.
We could search for a random crate on crates.io and see what identifiers people actually use, or we could spread misinformation on Lemmy.
Almost any language is OK, but Rust is just so, so fucking ugly
I can actually see where this is coming from, as I found Rust hard to read when I started out. I do really like Rust for reference, but I do agree Rust is hard to read for someone that has not learned it.
For example:
return statements that are implicit just because the semicolon isn’t there. Even better if they occur inside a if block or something like that. Very hard to understanding when you don’t know the syntax rules.
Lambda functions, especially when using move semantics too. They are quite simple, but if you don’t know the meaning, it’s more arcane characters. Especially when this is used inside lots of chained methods, and maybe a multi-line function in the lambda.
A lot for the if let x =… type of stataments are tough the first time around. Same for match statements.
Defining types for use with function::<Type>() and such.
Lifetimes, especially when they are all named a, b, c etc. It quickly gets messy, especially when combined with generics or explicitly defined types.
Macros, though not entry level rust to begin with, they are really cumbersome to decode.
None of these are sins of Rust, but for new people they are a hill to climb, and often hard to just “get” based on previous programming experience and reading the code. Rust can be really hard to approach because of these things. This happens in other languages too, but I do feel Rust has a particularly large amount of new concepts or ways to do something. And this is on top of learning lifetimes and borrow semantics.
This is the most sober take in this thread. I was bothered by all these things you mentioned for the first two weeks of using the language. I begrudgingly accepted them for the following two months because I felt the benefits of the language were worth it. Now all of these things feel natural and I don’t give them a second thought.
I think that’s a great set of criticisms.
They might not be strictly language issues, but if they are symptomatic of idiomatic rust then they are “sins of rust”. Something about the language promotes writing it using these kinds of idioms.
Just like French speakers don’t pronounce 80% of the written syllables because it’s impractical to speak fast with all of them…language features (or lack of them) drive how the language is used.
(BTW the implicit return behaviour on a missing semicolon sounds like Chekhov’s footgun)
As someone who has used Rust professionally for 3 years, the idioms are good. I wouldn’t want the idioms to go away, and I don’t particularly want the style/aesthetics of the language to change unless it can be done without negatively affecting the idioms.
It’s not a situation where the aesthetics are actually bad, it’s just different than what most programmers are used to, but almost all of the differences are for pretty good reasons. With enough familiarity and practice you’ll start to recognize those differences as benefits of the language rather than detriments.
But I think a lot of people have so much inertia about tweaking their way of thinking that they don’t feel motivated to try long enough to make it over that hump, especially when their expectations get set by rabid Rust promoters like myself who insist that Rust is vastly superior to any other languages in almost all situations. The stark contrast between how good they’re told the language is and how they feel when first exposed to it might be too much whiplash for some people.
I recognise that different languages have different styles, strengths and idioms. One of my pain points is when people write every language as if it’s naughties java. Enough with the enterprise OoP crap.
I’ve also learnt languages like Haskell to expand and challenge the way I think about software problems. I learnt a lot doing it. That doesn’t stop a lot of Haskell code looking like line noise to me because it over-uses symbols and it being close to impenetrable in a lot of cases when you read somebody else’s code.
I think the aesthetics of Rust are the wrong side of the line. Not as bad as something like Haskell (or Perl), but still objectionable. Some things seem to be different even though there’s pre-existing notation. Things seem to be dense, magical, and for the compilers benefit over the readers (as an outsider).
I’ve been learning Zig recently and the only notational aspect I struggled with was the pointer/slice notation as there’s 5 or 6 similar forms that mean fairly different things. It has other new concepts and idioms to learn, but on the whole it’s notation is fairly traditional. That has made reading code a lot more approachable (…which is a good thing because the documentation for some aspects sucks).
I’m not sure, what you mean by “Chekhov’s footgun”, but well, it isn’t a footgun, so you won’t accidentally return a wrong value from the function, if that’s what you’re thinking.
It’s not a Rust invention, most functional programming languages have implicit returns, but basically think less of them as a function return and more just as the value that a scope evaluates to.
So, here’s a simple example:
let sum = { let x = 5 + 9; 3 * x };Obviously, this is an extremely contrived example, but yeah, as you can see, it does not even have to involve a function. The implicit return makes it so that
sumis set to the result from3 * x.And the scope-braces are nice here, because you can do intermediate steps without having
xin scope for the rest of your function.In practice, if you see scope-braces and the line at the end does not have a semicolon, then that’s the value that the whole scope evaluates to. Those scope-braces can also be the braces of a function, but then you need to annotate what the function is going to return, too, so it’s practically impossible to return a wrong value.
Well, and I would actually argue that explicit returns are a footgun in comparison.
Because someone might introduce clean-up code at the end of the function and not realize that an explicit return skips that clean-up code, somewhere further up in the function.
The implicit return always has to be at the end of the scope, so it’s not possible to accidentally skip code.
The implicit return is perhaps the most dubious of them. I don’t mind it for simple functions, but they are not so good in anything large and with multiple return sites. Even more so when developers choose to implicitly return 4 chained method calls inside a closure with else cases.
But the rest aren’t really sins, they are mostly new or different concepts or ways to do something. And if there is a sin, it’s largely because the language itself has a complexity larger than others.
Taking my own examples here, lambdas are just fine, but the move semantics are cumbersome to deal with. But we need to do it some way, to indicate that a value is actually being moved into the closure. Maybe there are better ways and they make into the language in the future.
Conditional values and let statements and such is a good consequence of Rusts design choice with returning Results or Option types. Just because it’s different doesn’t make it a sin. Just takes time to learn the right way. I think most come from an exception based language, and that has a differnet code flow than what Rust has.
Lifetimes are hard though, and I feel a lot of the introduction is made excessively hard with the simple naming. It’s as of every programming tutorial used single letter variable names. Lifetimes isn’t something I’m that good with either, mostly because I haven’t had to use that complexity yet.
Go look at that Lisp kojumbo then tell me Rust is ugly.
(defmethod wake ((object magic-packet) address port) (let* ((payload (encode-payload object)) (size (length payload)) (socket (usocket:socket-connect nil nil :protocol :datagram :element-type '(unsigned-byte 8)))) (setf (usocket:socket-option socket :broadcast) t) (usocket:socket-send socket payload size :host address :port port) (usocket:socket-close socket)))Actually unreadable.
Maybe Emacs has fried my brain, but that is perfectly readable. Common Lisp has one of the most advanced object systems around, so yea you can write hard to read stuff if you want
Entirely readable to someone who knows Common Lisp, and unreadable to someone who doesn’t know any kind of Lisp. Mostly readable to someone who knows Emacs Lisp, Clojure, or Scheme.
Being able to correctly guess what the syntax does without knowing the language is a function of similarity to familiar languages more often than it is a characteristic of the syntax itself.
If someone knows elisp, they would have no trouble with that. Emacs has EIEIO, which is basically like CLOS lite
I imagine the tricky part for someone unfamiliar with Lisp would be that there’s no syntactic clue that a particular thing is a macro or special form that’s going to treat its arguments differently from a function call. Someone who knows Scheme may have never seen anything like CLOS, but would see from context that
defmethodmust not be a function.Yea, and CLOS is pretty weird, with putting methods outside the class definition.
You don’t even need to define a class to define methods. I’m sure that’s surprising to people coming from today’s popular language, but the original comment was about syntax.
Whether Lisp syntax is ugly is a matter of taste, but it’s objectively not unreadable.
Where you can define a method is syntax
In most languages, I would agree with that. In Lisp, I think I might not. If Common Lisp didn’t come with CLOS, you could implement it as a library, and that is not true of the object systems of the vast majority of languages.
It’s like comparing Hitler to Stalin. Both are pretty shit… Two things can be ugly at the same time. 😅
Compared to untyped languages? Sure. Compared to C or C++? Then maybe it’s a skill issue 😋
Hard disagree. Super beautiful.
Average Rust code:
macro_rules! sum { ( $initial:expr $(, $expr:expr )* $(,)? ) => { $initial $(+ $expr)* } } fn remove_prefix<'a>(mut original: &'a str, prefix: &str) -> &'a str let mut up = 1; 'outer: loop {Hell I don’t want to know what you define as ugly then.
Sorry, I love Rust but I can’t really agree with you here. They only showed a
macro_rules!definition, which is definitely rust syntax. Lifetime annotations are relatively common.I will concede that loop labels are incredibly rare though.
Loop labels are rare, but they lead to much simpler/clearer code when you need them. Consider how you would implement this kind of loop in a language without loop variables:
'outer: while (...) { 'inner: while (...) { if (...) { // this breaks out of the outer loop, not just the inner loop break 'outer; } } // some code here }In C/C++ you’d need to do something like
bool condition = false; while (...) { while (...) { if (...) { condition = true; break; } } if (condition) { break; } // some code here }Personally, I wouldn’t call it ugly, either, but that’s mostly a matter of taste
Well, you’d typically put the loops into a function and then do an explicit
returnto jump out of there. I believe, there’s some use-cases where this isn’t possible, which is why I’m cool with loop labels existing, but I’ve been coding Rust for seven years and have not needed them once…https://fprijate.github.io/tlborm/mbe-macro-rules.html#%3A~%3Atext=macro_rules!+With%2Cfollowing+form%3A
I guess I see what you mean if we want to get very technical about what a syntax extension is. But I think for the purpose of this discussion, it’s reasonable to think of
macro_rules!as a part of the Rust language. Practically speaking, it is syntax provided by the language team, not just users of the language who are free to extend the syntax by usingmacro_rules!to do so.What language are they then? They’re not Python, JS, <insert any other language here>
You used macro_rules, which is not common at all. Most rust files don’t contain any macro definition.
This code doesn’t even compile. There is a random function definition, and then there are loose statements not inside any code block.
The loop is also annotated, which is not common at all, and when loops are annotated it’s a blessing for readability. Additionally, the loop (+annotation) is indented for some reason.
And the loop doesn’t contain any codeblock. Just an opening bracket.
Also, the function definition contains a lifetime annotation. While they are not uncommon, I wouldn’t say the average rust function contains them. Of course their frequency changes a lot depending on context, but in my experience most functions I write/read don’t have lifetime annotations at all.
Yes, what you wrote somewhat resembles rust. But it is in no way average rust code.
I don’t know if anyone would argue Rust macros are beautiful. If someone does they should be checked out by a doctor.
Speaking as a fan of Rust.
Definitely not your average Rust code, more like a very ugly example of it.
Also, as the syntax first put me off as well, I gave it a chance years afterwards, and have now (or rather years ago) officially joined the church of Rust evangelism.
A lot of the syntax you define as ugly makes sense when you learn it, it’s just so much more explicit than a more dynamic language, but that exactly saves your ass a lot (it did for me at the very least) (I don’t mean macros, macros are ugly and should be avoided if possible)
Brainfuck Cobol Perl
for a start
Almost any language is ok but some ecosystems make me want to turn into a murder hobo (looking at you, JavaScript).
You can’t imagine how often I just sweared today about js. What did go through the mind of their designers, when they created this growing disease, and why did web browsers accept this as the lingua franca for the web. So… much… pain…
Try using luarocks with luajit.
Also looking at Rust. Yeah, I totally like recompiling thousands of crates for a single webapp single-threaded.
well if you are recompiling thousands of crates with a single thread, for a simple webapp no less, then you are doing something wrong. multiple things, actually, I count 3.
Actually, my (not that small) Rust projects now take officially less time to cold compile than the “hot” reloading of our next.js monster in my job. Incremental compilation is at least an order of magnitude faster. And cherry on top, dumb code is often 100x faster than js.
FORTRAN isn’t a beauty either.
And Python is strange as hell with its mandatory tabs.
You can use spaces in Python.
Two, three or four spaces? If you answer wrong I’ll never forgive you
Per the Linux kernel coding style:
Depends on the mood.
No one will ever know. That is my editor’s job. XD
Whatever your place defines as a standard. I’ve seen ugly code in C, JavaScript, Java, etc., that uses them all over the place because they’re not mandatory.
If you don’t have consistent indenting, your code looks like copy/paste from several sources; but if you do have consistent indenting, then the indenting of Python is a non-issue.
I’m rather partial to five myself but only when I’m feeling fancy.
Yes
Indentation-driven control flow is one of the most cursed things ever invented, excluding things explicitly designed to inflict pain or death.
Haskell has the choice of both indentation based and brackets for things like
doblocks, but most people use indentation based cause it’s the norm and looks cleanerWhite space sensitive languages are evil.
List comprehensions are much stranger than tabs vs spaces. There are very very very few languages that use them, and python’s is by far the worst out of the popular ones.
Skill issue. Once you learn them they are quite fun.
The concept of a list comprehenshion is sinple but syntax is awful, as if Yoda was writing a for loop. “x for x in y it is, hmm yes”.
I’m not saying I don’t understand them. I’m saying the syntax is terrible. Compare it to Ruby (or any other modern language) and it’s abundantly clear.
python (uses syntax not available in any other top 25 language)
print([j**2 for j in [2, 3, 4, 5]]) # => [4, 9, 16, 25]ruby (normal chain syntax with
map)puts [2, 3, 4, 5].map{|j| j**2}even kotlin is more readable, even though you have to convert to a double and back kotlin
val list = listOf(1,2,3,4) println(list.map{it.toDouble().pow(2.0).toInt()})For nested cases it’s even more apparent:
python
digits = [1, 2, 3] chars = ['a', 'b', 'c'] print([str(d)+ch for d in digits for ch in chars if d >= 2 if ch == 'a']) # => ['2a', '3a']ruby
digits = [1, 2, 3] chars = ['a', 'b', 'c'] digits.product(chars).select{ |d, ch| d >= 2 && ch == 'a' }.map(&:join)kotlin
val digits = listOf(1, 2, 3) val chars = listOf('a', 'b', 'c') println(digits.flatMap { d -> chars.filter { ch -> d >= 2 && ch == 'a' }.map { ch -> "${d}${ch}" }})just from a base level, you have to read the middle of the comprehension first, then the end, then the beginning. It’s a completely backwards way to write and read code. unlike other languages that use a ‘functional’ approach, where it’s chained methods or pipes, etc. Even Elixir, which does have list comprehensions, reads and writes in the proper order:
elixir
for x <- 0..100, x * x > 3, do: x * 2Wasn’t the python convention to use spaces (4 iirc)? Which is just plain wrong imho.
most repos use 4 spaces
This is the one thing I hate about python, because the spacing would differ between editors. I used vim to create the files on one system, and geany to edit them on another. Via uses 8 spaces in a tab (at least for me), while geany uses 4. This makes python mad, and drives me crazy.
Also, the rules for whitespace separation between things like loops, methods, and the rest of the code is annoying/ wierd (at least to me).
You know that editors let you change their defaults, right?
and that indentation defaults in decent editors are usually language dependent. I’m not familiar with these editors, but… come on - if they use one default for all files, OP should use a better tool.
Yes, but I don’t normally program in python, so I never did. When I had to, I never thought of changing it (it wasn’t for long anyways and was less of a thought out decision to do programming in vim)
Get a code formatter. Ruff is popular. So is black. Never think about it again.
One of the reasons i find it so hard to use non-Rust languages is how ugly they typically are by comparison. “fn” instead of “function” is such a great example of saving key presses where they’re most needed. And you get very used to seeing compact abbreviations. Idk if that’s what you’re talking about though.
Rust:
fn getofmylawn(lawn: Lawn) -> bool { lawn.remove() }C:
bool getofmylawn(Lawn lawn) { return lawn.remove(); }With Rust you safe 1 char, and gain needing to skip a whole line to see what type something is.
Honestly, the Rust way of doing things feels much more natural to me.
You can read it as
getoffmylawn,Lawnargument namedlawn,boolWhereas the C function is read as
bool? Could be a variable, could be a function, could be a forward declaration of a function,getoffmylawn,(, so all options are still on the table,Lawnargument namedlawn, that returns abooltypes in C are pretty weird
int *acan be read as*ais a intais a pointer tointint *a, bis read as*aandbareintais a pointer tointandbis aintbool getofmylawn(Lawn lawn)getoffmylawn(Lawn lawn)is aboolgetoffmylawnis a function that takes aLawnand returns aboolAnd then you have function pointers
bool (*foo(int a))(float b)(*foo(int a))(float b)is abool*foo(int a)is a function fromfloattoboolfoo(int a)is a function pointer fromfloattoboolfoois a function that takes aintand returns a function pointer fromfloattoboolreally weird in my opinion.
C++ is even worse, due to templates and the so-called most vexing parse. Initializing with
{}mitigated the latter somewhat, but came with its own set of woesSo that’s why people like C-style return types. That actually makes a lot of sense. I do too now.
To be honest, I think, they both have their place. In Rust, you typically wouldn’t return just a
bool, but rather the element that you removed, so like this:fn getofmylawn(lawn: Lawn) -> Option<Teenager> { lawn.remove() }And then with such a more complex return-type, C-style means that you can’t see the function name right away:
Option<Teenager> getofmylawn(Lawn lawn) { return lawn.remove(); }I also really don’t think, it’s a big deal to move your eyes to the
->…Amusingly, modern C++ allows you to copy the rust signature nearly 1:1:
auto getofmylawn(Lawn lawn) -> Option<Teenager> { return lawn.remove(); }Huh, did that emerge out of unrelated design decisions or did they just figure
I believe that it is useful in a few places. cppreference.com mentions templates as one case:
The syntax also matches that of lambdas, though I’m not sure that adding another way of specifying regular functions actually makes the language more consistent, since most code still uses the old style.
Additionally, the scope of the return type matches the function meaning that you can do
auto my_class::my_function() -> iterator { /* code */ }instead of
my_class::iterator my_class::my_function() { /* code */ }which is kinda nice
Very interesting, thanks! 🙂
“fn” was just one example. There’s also other abbreviations like “pub”, “impl”, “extern”, “mut”, “ref”, “bool”, “u64” And it’s true that some of these keywords are only relevant in Rust, however other langues have their own specific keywords, and they tend to be longer. In languages like Java (which is the worst example I can think of), you see things like “private static boolean” as function definition. In c++, you have to type “unsigned long” or even “unsigned long long” to represent “u64” (depending on data model).
I really don’t agree with saving keypresses being a useful metric, since auto-completion is a thing and code is read significantly more often than it is written. I am also a staunch opponent of abbreviations being used for variable names.
But I will say that I don’t mind abbreviations in keywords, since well, you need to learn the meaning either way.
And yeah, I’ve come to somewhat like them being used for keywords, since it reduces visual noise where it really isn’t useful, and it distinguishes keywords from actual code.
Ultimately, keywords are just syntax where letters were used instead of a symbol. You do read them like a symbol, so if they don’t look like a real word, that seems to work quite well for my brain.
To be fair, in C/C++ you can include
stdint.hwhich defines type aliases such asuint64_t.Yeah, the most beautiful code is where all variables are just letters of the alphabet.
Keywords aren’t variables
Ooh yeah, overall coding culture is definitely not affected by the preferred nomenclature for identifiers. The person who’s habituated to
fnoverfunctionwill absolutely never name their functions in the vein ofchkdsk. The two are completely disconnected in the brain of the programmer who read too much K&R in their childhood and was irretrievably traumatized by it for life.I’d say it’s much more influential the names of the identifiers of the standard library.
A language with
functionkeyword that names it’s stdlib functionsstrstrandstrtokwill inspire way worse naming than on that hasfnkeyword with stdlib functionsstr::containsandstr::split.We could search for a random crate on crates.io and see what identifiers people actually use, or we could spread misinformation on Lemmy.
Tell me this is sarcasm