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 get it there are people who want to play around and have language/compiler babysit them, but there are also people like me who want to see exactly what something is.
This is a false dichotomy when it comes to Rust. Despite everything I said and despite Lucy’s complaint, there is nothing that actually stops someone from explicitly annotating the exact type when declaring a variable. It’s just not required by the language, and most developers eventually realize that it’s not actually useful.
You’re right that these preferences are subjective, be although much of that subjectivity has more to do with how our past experiences have shaped what we’re familiar with, rather than any intrinsic characteristics of person. By that I mean, someone who uses Rust enough will most likely come to like the way the general community styles its code, sooner or later. In the meantime you’re welcome to do things in a way that suits your needs.
The only thing that Rust’s type system is weak on is runtime reflection. There are ways to achieve it within Rust’s type system, but it’s considerably more work than what you get in Python and JavaScript. Imo the only reason to choose a language other than Rust for a greenfield project is if you have a strong need for runtime reflection all over the place and aren’t very concerned about performance, threading, or avoiding entire categories of bugs that the Rust compiler protects you from.
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 sum that uses macro_rules! I would almost certainly reject it.
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.
It’s hilarious to me that people talk about “ugly” as if their opinions are objective.
I found Rust unpleasant to look at for the first two weeks of learning it, and now that I’ve been using it professionally for three years I loathe when I need to read code in other languages.
No other language can rival Rust in showing the exact information needed to understand the code — never too much and never too little — while being concise, correct, and handling all edge cases.
You can be more concise in other languages, but it will come the loss of handling every little possible bug. You can be prettier in other languages, but it will come at the price of adding a lot of useless boilerplate.
Of course there are cases where Rust can be verbose or confusing, but that’s when you’re doing very esoteric things that would be just as confusing in other languages.
Like any opinion on aesthetics, how someone feels about the prettiness of a language will have far more to do with familiarity than with any objective metrics.
Being unable to give an actual example proves you’re just a foaming-mouth hater with nothing to contribute.
I imagine this should count as illegal stock market manipulation, but the government would be too toothless to prosecute it.
I assume you’re referring to the technicality that the thirteenth amendment allows unpaid labor to be legally compelled out of prisoners, and that’s a valid thing to be outraged about, but your statement is wildly misleading to anyone who isn’t already aware of that technicality.
The existence of the loophole is terrible and should be amended, but it’s nowhere near the humanitarian crisis that widespread chattel slavery was. Ironically that will probably make it that much harder to be fixed since it’s more difficult to draw pubic outage towards it.
Your description actually illustrates how terribly inaccurate the metaphor was. If enslaved people imitated the people who enslaved them, they’d be sitting in a rocking chair on a porch sipping lemonade.
The US has a unique and relatively recent relationship with chattel slavery so people are more sensitive to it now.
The earliest record of the master/slave terminology being used in engineering is 1904 by which point slavery was already outlawed in almost every country, including the US. You’re right to say that chattel slavery in the US was a uniquely grotesque form of slavery, but there is no system of slavery in history where slaves are primarily imitating their masters. No matter what anyone’s sensitivity to the topic is, it’s a bad fit for what’s being described.
Outside of my own specialty I can people in the software industry bogged down by managing excessive boilerplate. I think this happens most often in web dev and data science.
In my opinion this is an indication that the software tools for those ecosystems need improvement, but rather than putting in the design effort to improve the tools in the ecosystem, these Big Data companies see an opportunity to just throw LLMs at it and call it a commercial product.
As a senior dev I hate vibe coding. I can write code an order of magnitude faster than I can review it, because reviewing code forces you to piece together a mental model for something made by someone else, whereas when I write the code myself I get to start with the mental model already in my head.
Writing code is never the bottleneck for me. If I understand the problem well enough to write a prompt for an LLM, then I understand the problem well enough to write the code for it.
I don’t think this is a fair comparison because arithmetic is a very small and almost inconsequential skill to develop within the framework of mathematics. Any human that doesn’t have severe learning disabilities will be able to develop a sufficient baseline of arithmetic skills.
The really useful aspects of math are things like how to think quantitatively. How to formulate a problem mathematically. How to manipulate mathematical expressions in order to reach a solution. For the most part these are not things that calculators do for you. In some cases reaching for a calculator may actually be a distraction from making real progress on the problem. In other cases calculators can be a useful tool for learning and building your intuition - graphing calculators are especially useful for this.
The difference with LLMs is that we are being led to believe that LLMs are sufficient to solve your problems for you, from start to finish. In the past students who develop a reflex to reach for a calculator when they don’t know how to solve a problem were thwarted by the fact that the calculator won’t actually solve it for them. Nowadays students develop that reflex and reach for an LLM instead, and now they can walk away with the belief that the LLM is really solving their problems, which creates both a dependency and a misunderstanding of what LLMs are really suited to do for them.
I’d be a lot less bothered if LLMs were made to provide guidance to students, a la the Socratic method: posing leading questions to the students and helping them to think along the right tracks. That might also help mitigate the fact that LLMs don’t reliably know the answers: if the user is presented with a leading question instead of an answer then they’re still left with the responsibility of investigating and validating.
But that doesn’t leave users with a sense of immediate gratification which makes it less marketable and therefore less opportunity to profit…
Wise people plant trees whose shade they’ll never stand in.
If two characters are hurting your 260 character limit then you have other more serious problems to contend with.
Until people start applying the same logic everywhere for consistency, not just in file names.
Just you wait…
Did the software industry learn nothing from Y2K? Was it too long ago already for people to remember the mess we made for ourselves?
Saving two characters in a file name is not worth the hell you are leaving in your trail by shoving this nonsense in an obscure corner of production code that people are going to forget about until it’s too late.
I recently had an accountant file something for the IRS that was dated as expiring in 1940 when it should’ve been 2040. I had to catch it myself after reading through 70 pages of dense forms before it was sent off, and I could’ve easily missed it.
Digital records have existed long enough now that it’s downright irresponsible to leave off the century for anything where having an accurate date might even slightly matter.
There’s a lot to be said for the scale of damage that can be done with something, especially relative to the effort needed to do that damage.
These days tech companies are doing enormous damage to people’s brains (saturating our dopamine receptors to the point that many people have depression and executive dysfunction) to turn us all into consumption machines that can only find happiness by consuming content and buying commercial products and services.
Imagine how much more harm they’ll do when they have direct access to our neurons, without even LED pixels as a buffer in between.
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.