What other option is there? I thought the same and wanted a higher-level GC'd language than rust, and played some with Ocaml, Haskell and F#. In theory they should be more productive and I'm sure are for things like compilers and parsers where they have top-quality libraries, but for most things I got the impression that even if I took the time to learn well one of those languages, the quality of libraries and documentation and tooling is so far ahead in rust that it more than makes up for the productivity hit of rust making you concern yourself more with low-level details
Scala is great, but the tooling is what ruined it for me. SBT is far from simple, Scala 3 basically reset the IDE suport, the compiler is abysmally slow (if you think Rust compiler is not fast, don't look at Scala which is like order of magnitude worse).
And also the cost of FP is quite high on JVM. Paying 10-20x performance price for functional transformation chains over similar ones in Rust is a bit too much for me.
I come from traditional "unix hacking" background and don't know at all the JVM or .NET ecosystems, and share the irrational distrust of them many unix hackers have, though I'd get over it I could actually get stuff done faster with them. But some projects I do are lower level or need high performance or reasonably small staticly linked binaries, or instant startup time (cli utilities), so rust is a better choice. For most of the rest a JVM or .NET language would be fine and should be more productive as it's a higher level language, but I don't know if I'd use it enough to learn the language and ecosystem and tooling enough to be as productive as in python or rust which cover pretty much anything I need to do at the moment.
I think that is also why rust ecosystem will keep expanding and improving a lot. They said about python that it's not the best language for anything but 2nd best for everything, which isn't really true as python can't be used when you'd need C or C++ but rust can really be used for anything.
(TL;DR: The JVM was NOT "the epitome of open-source" for many years and it's still struggling with the knock-on effects of spending so many years being one of the only things that you couldn't install through your package manager for purely legal reasons.)
Second, I can't remember which blog post it was, but Eric S. Raymond has mentioned that the reason he found Python much more appealing than Java is that Java's standard library embodied an attempt to push people to write portable code in ways that made life difficult when your goal was explicitly to do POSIX-specific things.
As a Linux user who saw C# for the "Microsoft's take on Java after the Visual J++ lawsuit" that it was and, thus, never really saw any interest in it, I can say that C# gives that same impression of "ill-fitted for POSIX-native stuff" (packing its CLR bytecode into .EXE files doesn't help, even before you get to the assumption that you'll have Wine and Mono fighting over who should open .EXE files when double-clicked.)
Rust, by contrast, produces truly native binaries, has Cargo come standard and makes `cargo add libc` or `cargo add nix` trivial and reliable, etc. etc. etc.
Third, the JVM's tunings, optimized for long-running processes, and the start-up time and approach to memory allocation that resulted, gave it a reputation for being slow and bloated. The POSIX ecosystem has a history of encouraging composition of short-lived processes via shell scripts.
Fourth, Java has always let the quality of the GUI experience on X11 languish.
I still remember how you needed to set environment variables to work around "Java applications produce empty grey windows under non-reparenting window managers" for years and years.
I still remember when you had to open part of the JVM in a hex editor and replace XINERAMA with some nonsense string that doesn't match anything to un-break Java applications on multi-monitor systems.
TO THIS DAY, I still can't find a Java GUI widget toolkit that doesn't have a noticeable responsiveness/input latency problem under X11.
(Swing, SWT, JavaFX... that annoying fraction-of-a-second sluggishness is one reason I'm planning to write my own replacement for the parts of the new JavaFX-based version of PlayOnLinux that I actually use once I stop using the old Python version.)
I haven't tried QtJambi, but given that SWT, which should be using GTK on the backend, exhibits the problem, I don't hold out much hope.
(In essence, in the same way that Swift is ill-suited for stuff outside Apple devices, .NET has gained a stigma of "ill-suited for anything outside Microsoft platforms" (Is Unity's Linux support still only viable for targeting it, not developing on it?), and Java similar, but for JavaEE servers... and since your average POSIX developer sees AbstractThingFactoryBeans as a tired but too-accurate joke about what hell it is to write Java... you do the math.)
“Since this article was first published, Sun (now part of Oracle) has relicensed most of its Java platform reference implementation under the GNU General Public License, and there is now a free development environment for Java. Thus, the Java language as such is no longer a trap.
You must be careful, however, because not every Java platform is free. Sun continues distributing an executable Java platform which is nonfree, and other companies do so too”
Also, Stallman is quite an “extremist” and he is often himself the enemy of open-source by his gatekeeping, so there is that.
Re the GUIs: I think it says a bit also about the state of GUIs on linux, then the reverse - and I say that as someone who has been using linux on every computer I own since forever.
You made some great points, but I think the real reason is even simpler, old graybeard linux users are very conservative in their technology takes. The overabundance of C software (and the unavoidable memory vulnerabilities that come with that) even at places where it makes zero sense is clear sign of that, but so are the “systems/pulse/wayland hater fangroups”.
First, note that I also pointed to Java spending years developing a reputation as one of the only things you couldn't install through the package manager for legal reasons.
People who don't care about Stallman's zealotry do still care about that and it presented a similar lasting problem to Java's Linux uptake as the problem D had more broadly with two competing and mutually incompatible standard libraries (Phobos and Tango) in the early years.
As for the GUIs, I listed three different ways unique to Java that Java GUIs were subpar on Linux:
1. Needing weird workarounds for applications to not display blank grey windows on non-reparenting window managers. (Basically, if the WM was something like a tiling WM that didn't reparent it from the root window to a WM-provided "titlebar and borders" parent window, the app would refuse to render anything without enabling the relevant hack.)
2. Caring so little about solving known bugs that slipped through QA that, for a shamefully long window of time, users with more than one monitor literally had to hex-edit their JVM to intentionally no-op the XINERAMA detection to make applications work. (i.e. XINERAMA being the X11 extension that allows Windows/Mac-style "one desktop stretched across multiple monitors" multi-head instead of the older "Behaves like a software KVM and applications are trapped on the monitors they opened on" Zaphod mode.)
3. Having some kind of input-response latency that I've never seen in another language or toolkit, which is apparently caused by something so fundamentally Java that it's present in every Java toolkit I've checked.
As far as greybeards go, I think we'd need more data points. Eric S. Raymond is quite an old-guard guy and even had some "jumps to conclusions"-y, "it's not enough like C"-ish reasons for choosing Go over Rust (eg. No `select` as part of the standard library, ignoring how Rust intentionally keeps the standard library minimal), but had no problem with using Python where it was suitable, while he didn't like Java because it was was more of the ChromeOS or Android school of doing stuff on top of a POSIX base.
fsharp has csharp problem and sloppy with all that reflection and exceptions. sure csharp moves right dirrection, but it will take longer for ecosystem to be non slopy
I tried elixir and enjoyed it. I'm don't have strong feelings either way on static vs dynamic typing, I think the current craze for static typing is a lot because of people's experience with javascript vs typescript. With elixir I of course had runtime type errors but trivial ones that show up on the first run, I don't think I had any hard to find bugs or bugs that surface later that ML typing would've caught. I'd absolutely pick it over rust for web backends, but I do very little of that, I'm mostly writing cli utilities on unix. I've been experimenting with common lisp lately and it's a lot of fun, as fast to prototype with as python (when it has the libraries you need), performance around the level of java or go, great development environment if you use emacs, instant startup time for cli utilities unlike beam or jvm. I think if it was made easier to make and cross-compile fully staticly linked binaries, and it get's something like maturin for python or rustler for elixir to have easier access to bigger ecosystem when needed it'd be great for my uses but at the moment I can't use it for much
In my case, it's because I've been burned by Python's maintainability issues in ways MyPy isn't sufficient to fix.
It's not just Rust's type system, but:
1. Unlike with Haskell, the Rust compatibility promise has set the tone for how the ecosystem approaches API breakage.
2. Go-like "statically link everything into a single binary" compilation means that "just keep using the old build until things are fixed" is a valid answer to "an upgrade broke the buld process".
3. Rust's type system enables design patterns like the typestate pattern, for encoding as many invariants in the type system for proving at compile time as possible.
4. Rust's design prioritizes removing the need for global reasoning about program behaviour.
Same reason I recently spent $10 on a used copy of the O'Reilly lex & yacc book to learn the warts of LR parsing. I plan to write my parsers via something like LALRPOP or grmtools instead of using nom (parser combinators) or pest (PEG parsing), which are currently more popular in the Rust world. (As with borrow-checking errors, shift/reduce and reduce/reduce conflicts aren't the bug, they're the feature. I read an article about how LR parsing allows the most detection of ambiguities in the grammar at compile time. Cry in the dojo, laugh on the battlefield.)
I'd rather pay up-front to avoid the stress of having a Sword of Damocles hanging over my head and feeling satisfied with Rust takes FAR less time than either burning out trying to replicate its type system in unit tests or playing bug whac-a-mole over the lifetime of the project.
What other option is there? I thought the same and wanted a higher-level GC'd language than rust, and played some with Ocaml, Haskell and F#. In theory they should be more productive and I'm sure are for things like compilers and parsers where they have top-quality libraries, but for most things I got the impression that even if I took the time to learn well one of those languages, the quality of libraries and documentation and tooling is so far ahead in rust that it more than makes up for the productivity hit of rust making you concern yourself more with low-level details