Programming languages, much like the jackass in the middle, are tools. Different tools are for different things. The right tool for the job can make your day. The wrong tool can make you question your entire career.
Exactly. And what is the best tool? The best tool for the job
And what is the best tool?
AI! (This message brought to you by The Microsoft Marketing Dept.)
That’s just not terribly meaningful, though. Was JavaScript the “best tool” for client-side logic from the death of Flash until the advent of TypeScript? No, it was the only tool.
You’re halfway there.
Yes, it was the best tool, in context
In that context, what was better?
Exactly, the hivemind is strong in this thread
If it was the only tool it was both the best and the worst by definition.
Flash was awful. I was contracted to un-fuck a custom video player and that experience convinced me that Flash was a dumpster fire that needed to die. Fortunately it did.
And what is the best tool for the job? The best tool for the job.
deleted by creator
Sometimes I just want to use a particular tool, and care less what I’m making with it.
I rarely get this pleasure at work.
Almost any language is OK, but Rust is just so, so fucking ugly
Almost any language is ok but some ecosystems make me want to turn into a murder hobo (looking at you, JavaScript).
Also looking at Rust. Yeah, I totally like recompiling thousands of crates for a single webapp single-threaded.
Try using luarocks with luajit.
what? what part of rust is ugly?
Literally every single bit of the syntax.
The majority of its syntax is very similar to many other languages. Can you give an example of a language with pretty syntax?
Key point being, similar to some random languages. JS and Python Syntax don’t fit a typed and compiled language at all.
Pretty syntax would probably be something like C, where not every single character already widely reserved for specific keywords (like !, ', =) is reused in completely random ways.
Ah yes I also found macro syntax like
vec![andprintln!(to be a bit jarring at first. However I don’t know if I would say that C’s approach to macros is any nicer, with it’smagic
Being unable to give an actual example proves you’re just a foaming-mouth hater with nothing to contribute.
From the first syntax examples on Wikipedia:
fn main() { let foo = 10; // Suddenly, types are implicit now. A safe language should never have implicit types (now it's the (IDEs) implementations judgement which type that is. Combined with the variable shadowing "feature", this seems like a major clusterfuck. Now the IDE is the sole thing to tell you that you totally fucked up the logic, and both declarations/definitions (well which one is it? Would be nice to always have a direct KEYWORD telling you which type this fucking variable has. But no, the lazy piece of shit Rust 'programmer' left that as an exercise to the dear reader. Because in they just need to leave that part out instead of explicitly stating "I'm a lazy piece of shit" by *instead* typing 'auto'.) This is just Python-level BS. Yes, I also hate C++ for its auto keyword - but at least it explicit. println!("The value of foo is {foo}"); let foo = 20; println!("The value of foo is {foo}"); }fn add_two(x: i32) -> i32 { // That is, again, the syntax of Python. Why? Because Python is explicitly untyped. So having types be a *literal* afterthought is Ok. They're fully optional anywhere there. Now we're in Rust. They're sometimes optional, sometimes not, but they're always preferred. Yet, they're also an afterthought, seemingly. x + 2 // Implicit statements are bad. Very bad. They so much invite to glossing over stuff, especially when your brain expects to see something else. Also, having every statement ended with ;, except context blocks, but suddenly *not* having statements ending with ;, is fucking ugly (which is the entire point of this rant). It's completly inconsistent. Which in itself is a huge magnet for errors. }if x > 5 { // Now why would you leave the parantheses, which are a major contributor to readability, away. Or even allow this. Rust is just memory safe, like dozens of other mainstream languages, but continues by allowing, promoting and requiring hazardous practices. println!("value is greater than five"); }Now I’m slowly getting annoyed from typing on phone (at least in nvim), and my throat gets clogged with mucus again.
Remember, some of that are subjective preferences and opinions. And the core idea of Rust - fast but safe programs - is good, yet very obvious and not innovative at all, while the syntax and implementation (of cargo (yes I like to wait an hour for a simple webapp to compile because there aren’t binary crates and cargo just doesn’t multicore 99% of the time)) is subpar to something that’s hailed as the savior for everyone and everything by such a large cult.
Types are not implicit, they’re inferred by the compiler when there is no ambiguity about what the type needs to be. This is a huge benefit for refactoring code and reducing maintenance. I acknowledge that sometimes you might care to know the exact type of the variable, and sometimes that’s not as easy for a human to infer as it is for the compiler, but every decent IDE will provide inline type hints for you. Interpreting code by reading it in plaintext is an exercise in masochism.
Python is actually the opposite on this, and it’s one of Python’s worst characteristics. The type is unknown until runtime unless you annotate it, and then the annotation isn’t really enforced. It’s the worst of every dimension.
C++11 introduced auto, and now the community is split between “almost always auto” and “never auto”.
JavaScript needed a whole new compiled language (Typescript) to fix its type system problems, and Typescript is only an incremental improvement at best.
Rust has the best type system of any modern language by far. If you’re tripped up by not always seeing the type declarations then you’re either focusing on the wrong details in the code or you just need a little more practice. The key thing that needs to sink in for new Rust users is that the compiler is always providing safety rails. That means it’s no longer your job to verify that every aspect of the code is correct. You can relax a little and actually have something akin to duck typing without all the pitfalls that usually come with it.
In practice, type inference in Rust is not a problem since the language is so strongly typed. In fact, it is more strongly typed than both C and C++, and will force you to cast values explicitly in cases where C and C++ will happily mess up your variables without warning. The absence of type inference would also be a major pain, since nested types such as iterators can get quite complex and very verbose. If you’ve programmed using older C++ standards, then you know this pain
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 {This is on the level of the esolang I made at 8 y/o, with random characters denoting random actions everywhere, at random positions.
It’s incredibly disingenuous to call this average Rust code and further erodes your credibility. I may as well point to hundreds of lines of preprocessor macros in a C++ header and call it average C++ code.
This is not what an average Rust developer is writing 99% of the time. If someone on my team submitted a PR with an implementation of
sumthat usesmacro_rules!I would almost certainly reject it.
Removed by mod
You can use spaces in Python.
Two, three or four spaces? If you answer wrong I’ll never forgive you
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.
Per the Linux kernel coding style:
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.
First off, I’d suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it’s a great symbolic gesture.
Depends on the mood.
Indentation-driven control flow is one of the most cursed things ever invented, excluding things explicitly designed to inflict pain or death.
White space sensitive languages are evil.
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 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.
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 * 2
Wasn’t the python convention to use spaces (4 iirc)? Which is just plain wrong imho.
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.
None of these are sins of Rust, …
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:
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 havingxin 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.
Not to stereotype too much but I think this is the first Blåhaj I’ve seen (in a programming context) that wasn’t team Rust.
What your programming language of choice (if you don’t mind sharing)?
Compared to untyped languages? Sure. Compared to C or C++? Then maybe it’s a skill issue 😋
The programming language promotes a thinking model and the ecosystem defines a modus operandi.
Of course they matter.The language is as important as architecture and stuff.
Pick the right language for the right task.
Performance? Don’t use python.
Everything else? Use python because everyone does.
/s
I despise python syntax.
as someone who uses python daily: what is syntax? /s
sin-tax
That’s a strong opinion. What’s the problem with python syntax?
That’s why we use JavaScript on the front end, JavaScript on the back end, and you can streamline it even more by using JavaScript for the db layer too. After all, if you have too much data to be reasonably parsed in a single .json file, you are probably just architecting wrong.
Every time you get over 200k lines of JSON you gotta split it into another app, so you can webscale.
I miss the old tts voices and now everything is ai generated garbage :( Bring back the robot voices!
This is pretty smart for the left guy. He’s usually down at the level of “HTML is a programming language” or “What’s a programming language?”.
That said, the first one of those isn’t mutually exclusive with what he says in the meme.
It mostly reflects my own story. From a beginner enthusiast of multiple “cool” languages (Scala was all the rage back then), through considering myself more “mature” and thinking about business priorities, ending at understanding that using a good programing language is a business priority.
If the team works with a language they enjoy, they will be happier (and more productive). Doesn’t even matter if the code is written by humans or machines.
What do you mean by “monad has no business value”? /s
But, Haskell…, it’s so well thought out, so evolved, the best of all functional programming in one, the ability to handle infinite lists, the lazy evaluation, the strict type checking, the compiler that catches whole classes of bugs, the curt syntax, the ability to breathe it like pure thought, the clarity like maths…
Okay, sorry, I better leave the room too.
Sorry, Clojure is newer and fancier.
Better if you need the ability to unintentionally shoot yourself in the foot.
Haskell is pretty cool, I really like Scala too. It’s a bit easier to understand for me :P
I’m only a hobbyist no skin in the game but as an engineer first programmer second I feel like how you design the architecture of your logic and how you choose to prioritize computational optimization or feature implementation have a much bigger impact than language. Obviously theres a time and place like using luajit instead of lua if you really need that speed boost, but in big complex programs I’m willing to bet lazy programmers skip optimization steps and copy paste thousands of lines to ship quickly regardless how performance optimized the underlying language is.
I make a module that does a specific thing for version 1, after initial bug patches and maybe a feature addition theres usually an epithany that the logic can be generalized into an api type registry structure that allows the code to be reused and configured as needed on per item basis. Along the way you do stuff like ask what the not expensive calls are, add accumulator timers to reduce unneeded CPU usage , ensure early returns are up top when it makes sense, choosing to render a cleverly crafted sprite instead of a full 3d entity.
A conditional if then logic loop Is a logic loop no matter what Turing complete language its written in. What really matters is how you use the loop not which syntax its written in.
Any function can be written in any Turing complete programming language. That doesn’t mean a sane person would use malboge or brainfuck for a production system. Language choice can have a huge impact on productivity and maintainability and time is money.
No one actually copy/pastes thousands of lines of code. We use libraries.
Languages do matter a lot. Yes, they are all technically equivalent, but the craft of software engineering is much, much more about social/cultural/community considerations than it is computational ones. What the community around a programming language values matters, because it informs a great deal about what’s idiomatic in a language, what libraries are available, what kind of bugs are possible (or not), how easy code is to read, comprehend, and maintain, and much more.
What makes a language good is not what programs you can write in it, but how it constrains what you can do such that you naturally writing good code. For example, null pointer exceptions (or segfaults in C, etc.) are a classic problem that plagues many mainstream languages like Java, C#, Python, etc. In Haskell (and a handful of other languages, including Rust), null pointer exceptions are not possible, because nulls do not exist in these languages. Taking away this language “feature” actually increases the power of the language, because you can guarantee that a certain class of common bugs are not possible in your program. So languages that restrict known bad programming practices lead to programmers writing better programs and, more generally, a community around the language that resonates with these philosophies.
“We have decided that we will use deck screws to build our deck, it’s the right pattern and architecture for the job. Now get started with this hammer, the tool you use doesn’t matter as long as it’s functional as a tool. If it’s not working well that’s an optimization problem because you’re bad at your job.”
It’s extremely important, because you’re never really picking a programming language, you’re picking a stack
You can technically write an android app in Python, but should you? You’re now locked into a framework used to run apps in Python, which are going to be much more limiting than other languages and frameworks. But you’ll also have access to Python libraries, which gives you options in that direction
Then you examine the context. How good are you at learning other languages? How long/complicated is what I want to do? Does this need to be performant? How long do I need to keep this working?
And most importantly, and you really have to think this one through… Will I need to extend the original goals in the future?
So really, yes, it’s very important. A bad decision in the beginning could cause problems for decades
deleted by creator
Represent



















