As someone with a background in linguistics, my jimmies are indeed rustled.

IDK, comparing Javascript to English while Java to German seems to either overblow the value of javascript or diminish the value of English.

How so? Except the first sentence which is obviously not serious, I would agree with all linguistic statements or at least not disagree with any.

True, but only because it actually is. Except weirdos who saw php code 20 years ago say it sucks.

BASIC: Am I a joke to you?

Phoenician wants a word.

The whole (Mediterranean) universe.

Esperanto always struck me as more perl-like with each part of speech having its own suffix like perl has $ for scalars, @ for arrays, and % for hashes. Though perl is probably more like a bunch of pidgins…

Esperanto’s equivalent would probably be Haskell.

Python is probably more like Spanish. Very easy basics, but then people from different regions of where it’s has spread out barely understand each other

Nobody mentioned number of speakers though

It’s a post by the lemmy dev, so yeah that’s a given

Yes, but “Proto Indo-European” doesn’t exactly roll off the tongue. /s

I think ppl just got pissed with the fanboys unironically asking to RIIR everything. The language itself is comfy AF, tho

I think rust has good ideas and may even become the default systems language in the mid-term. I find it irritating that there is a very vocal subset of rust proponents that tend to insist that every project in every language needs to be rewritten in rust immediately. I suspect that is also why other people are down on rust.

Butthurt C devs don’t want it replacing their language.

I don’t think many ppl are down on rust… it’s won developer’s most favorite to use for like 5+ years now in a row on stackoverflow.

For me “The Critical Flaw” of rust is its compiler. And requirent of 12 GB of disk space to compile just the frontend of compiler. Even GCC will all frontends(C, C++, Ada, Fortran, Modula-2, JIT) requires less space.

But joke is probably about “rewrite in rust” culture.

Imo it’s bc it’s the new kid on the block. Yes it’s 10 years old but barely becoming common use in production and government mandates are only speeding that up. In actuality it’s a great language and has been hyped for a few years by people who actually use it. Python went through the same thing in the 2010s where devs really tried clowning on it, now it’s used everywhere.

i think it’s mainly people being cranky and set in their ways. they got used to working around all the footguns/bad design decisions of the C/C++ specifications and really don’t want to feel like it was all for nothing. they’re comfortable with C/C++, and rust is new and uncomfortable. i think for some people, being a C/C++ developer is also a big part of their identity, and it might be uncomfortable to let that go.

i also think there’s a historical precedent for this kind of thing: when a new way of doing things emerges, many of the people who grew up doing it the old way get upset about it and refuse to accept that the new way might be an improvement.

It’s like a good C++ that is actually able to replace it. There are lots of places where a good C++ is useful. Like everything that needs low latency and low resource usage.

But it’s not an easy language, so (I’m guessing) people who see everyone loving it but are unable to learn it start to suffer some sort of cognitive dissonance. If it’s too difficult for me to learn, that must be its fault, not mine.

Cause it’s a C++ replacement when said audience never asked for one. It’s great but it’s still waaaayy too early, people need to slowly get comfortable with it.

Haskell is Esperanto. The difference being that Rust is actually catching on.

Rust is used more Ethan you think

Python is Spanish; a ton of people learned a bit in school and never picked it back up again. Places that speak it natively all have their own conventions because, even though the native languages were replaced by colonizers, a lot of the native languages patterns remained in place. Most places that speak it are super welcoming and stoked that you’re trying to learn.

Its standard library reads like someone’s Object Oriented Programming 101 final project, and they probably got a B- for it. Everything works and follows OO principles, but they didn’t stop to think about how it’s actually going to be used.

Let’s try to read a file line-by-line:

BufferedReader reader = new BufferedReader(new FileReader("sample.txt"));
String line = reader.readLine();

We’re having to instantiate two objects (FileReader and then BufferedReader) just to get an object that has a readLine() method. Why? Can’t BufferedReader take a file name on its own and work it out? Or FileReader just provides readLine() itself?

Not only that, but being parsimonious with what we import would result in:

import java.io.BufferedReader;
import java.io.FileReader;

But we’re much more likely to be lazy and import everything with import java.io.*;. Which is sloppy, but I understand.

I can see what they were thinking when separating these concerns, but it resulted in more complexity than necessary.

There’s a concept of “Huffman Coding” in language design. The term itself comes from data compression, but it can be generalized to mean that things you do often in a programming language should be short and easy. The above is not good Huffman Coding.

I think a lot of it is “ceremony”, so it’s pretty common in java to:

• create a get method for every object variable
• create a set method for every object variable

Then add on top that you have the increased code of type annotations PLUS the increased code of having to check if a value is null all the time because all types are nullable.

None of that is hugely complicated compared to sone of the concepts in say Rust, but it does lead to a codebase with a lot more lines of code than you’d see in other similar languages.

Java itself is kind of blissful in how restricted and straightforward it is.

Java programs, however, tend to be very large and sprawling code-bases built on even bigger mountains of shared libraries. This is a product of the language’s simplicity, the design decisions present in the standard library, and how the Java community chooses to solve problems as a group (e.g. “dependency injection”). This presents a big learning challenge to people encountering Java projects on the job: there’s a huge amount of stuff to take in. Were Java a spoken language it would be as if everyone talked in a highly formal and elaborate prose all the time.

People tend to conflate these two learning tasks (language vs practice), lumping it all together as “Java is complicated.”

$0.02: Java is the only technology stack where I have encountered a logging plugin designed to filter out common libraries in stack traces. The call depth on J2EE architecture is so incredibly deep at times, this is almost essential to make sense of errors in any reasonable amount of time. JavaScript, Python, PHP, Go, Rust, ASP, C++, C#, every other language and framework I have used professionally has had a much shallower call stack by comparison. IMO, this is a direct consequence of the sheer volume of code present in professional Java solutions, and the complexity that Java engineers must learn to handle.

Some articles showing the knock-on effects of this phenomenon:

• https://stackoverflow.com/questions/11865307/how-to-expand-size-of-java-stack-trace-to-see-bottom-of-stack-triggering-a-sta
• https://www.reddit.com/r/java/comments/16g30jx/can_java_errors_stack_traces_be_longer/
• https://www.quora.com/Why-does-the-Java-Spring-Framework-produce-gigantic-unreadable-stack-traces
• https://community.splunk.com/t5/Splunk-Dev/What-are-the-best-extraction-methods-for-Java-Stacktrace-Errors/m-p/380397
• https://stackoverflow.com/questions/65436457/springboot-stack-trace-logging-filter-only-from-my-packages

Char count for same functionality is still at least double in java vs python. It just feels like a chore to me. jetbrains helped, but still python is just so light

Yeah, I enjoyed learning German… Java on the other hand…