Comment by sillysaurus3 | Hacker News Reader

Comment by sillysaurus3 | Hacker News Reader

Is there a way to avoid the true-believer syndrome for Rust?

I want to embrace Rust, but everyone ~100% of the time comes away chanting about how awesome Rust is. So much so that it's a bit unsettling. Zealotry in general is bad, but especially in programming: once you identify as an X programmer, you lose out on ideas from Y and Z.

Every tool has its flaws, but for whatever reason it seems extremely rare to discuss Rust's. When you try, it's like you're the Pied Piper: your song brings seemingly the entire community scurrying towards you, ready to force-push you why you're wrong and why Rust is awesome.

How about no REPL? We Go now. Slow compiler? Check. Performance is nice, and so is parallelism, but it costs static typing. It's a nice tool to have in your pocket as a fallback, but where's the niche? The ecosystem is huge, too: run `du -hs ~/.cargo/` and see how many GBs you're losing. This is a really tough sell on a 256GB SSD.

"So get a bigger SSD!" "Yeah but the compiler is always improving" "Yes but real programmers don't really need a REPL" "Yeah but static typing is worth the tradeoffs"

These refrains have been identical for nearly a year. Is there anything new to say, or is it time to agree to disagree?

- We are directing material resources (as in, hours of paid work) to improving compiler performance. We consider this a serious problem, and "the compiler performance is always improving" is not an accurate gloss of the amount of work people are putting into solving it.

- We would love to have a REPL but there are nontrivial technical challenges, and it has not been a major requested feature by our users.

- I have never heard the complaint about the size of packages before now; I have no idea how we compare to other languages in this regard.

I've witnessed some of the conversations you're talking about (I think I engaged with you about REPLs in the past), and I think the "true-believer syndrome" has more to do with how you interpret the answers you receive than with the behavior of anyone else.

Only listening to current users for feature requests is selection bias.

I'm not currently using rust, and lack of a repl is a big strike against it. Not as much of a strike as the lack of a good stable async story, but still.

We explicitly reach out to willing non-users to try and counteract said bias.

Remember that Rust is competing with C and C++.

Neither of them have REPLs. Both are statically typed (actually a lot of C programs are pseudo-dynamically typed with void * but pretty much nobody thinks that is better than actually using a dynamic language, or using something that has better generics). C++ is famous for long compilation times.

For the class of problems in which your choices are C or C++, Rust is such a compelling 3rd option that it's hard not to gush. It was clear to me within hours of first learning rust that the designers had exactly the same problems with C++ that I had.

Many communities tend to push back against questions about a language's weaknesses, (both real and imagined). To me, this appears to be mainly just a case of it being the n-100th time someone has said something like "Language X sounds interesting to me, but I heard it has a problem with Y" to a group of people who have all either are not at all worried about Y, or have decided that giving up Y is worth it. This is amplified on a group discussion board (such as usenet or irc[1]), since you get multiple responses simultaneously, and is made worse when people who don't actually understand the tradeoffs try to repeat points they've heard from people who have. Also the less-hot-headed members of the community are typically uninterested in getting involved in a flamewar, so it's not "the entire community scurrying towards you" but rather the most obnoxious subset of the community.

If you want a reasonable discussion about strengths and weaknesses of a language, your best bet is to have a one-on-one discussion with someone who actually had to make these trade-offs.

Note also that the question of typed vs untyped languages is always going to be a distraction, and "agree to disagree" is the only likely consensus here[2].

1: Usenet is better than IRC often because threading means that after the dust has settled, there is sometimes a thread or two with gems that can be mined from the muck.

2: I'm firmly in the "typed languages are betterHop on comp.lang.lisp " camp, but I write almost all of my hobby software in Common Lisp, which is quite firmly in the untyped camp, despite having some language support for static typing. Static analysis (which typing is a subset of), is one of the less fun parts of writing software, but if correctness is important, then, IMO it's reckless not to do it.

> Neither of them have REPLs.

Sure they do, FOSS developers just don't look into the right places.

Already in the 90's there were companies selling C interpreters.

CERN created CINT and Cling for C++.

Microsoft has quite a good interactive debugger, and edit-and-continue, which is a kind of very poor man's REPL.

> Neither of them have REPLs.

https://github.com/root-project/cling

https://github.com/Keno/Cxx.jl

I find it pretty strange to read you say "it costs static typing". Static typing is a feature. There's a reason people are starting to switch to TypeScript instead of JavaScript.

(ง'̀-'́)ง

Static typing is useful in large codebases at big companies because it forces you to communicate your intentions clearly. It's also useful in large OSS projects because it allows your IDE to auto generate tooling and documentation. If someone is using TypeScript, it's far more likely the codebase will have clear, documented interfaces.

But TypeScript is optional. It doesn't hold you down and yell at you until you obey it. Even when you're using it, you can simply ignore the warnings/errors if you want to be naughty, and TypeScript will simply shrug and say "if you insist. You'll realize later I was right." But in the meantime your code actually runs.

In Rust, it's the opposite. You have to think about every single aspect of what you're doing. Making a cathedral out of toothpicks would also force you to plan your actions very carefully, but you wouldn't really say it's a feature per se. More like the tradeoffs of the medium.

Rust is consciously designed for large code bases. shrug

> Even when you're using it, you can simply ignore the warnings/errors if you want to be naughty, and TypeScript will simply shrug and say "if you insist. You'll realize later I was right." But in the meantime your code actually runs.

This is because, well, TypeScript is sufficiently close to the target language---JavaScript. There exists some reasonable JavaScript translation of many "bad" TypeScript code. Rust (among other languages) is compiled down to the machine code and you won't have such luxury there. After all you need the exact enough type [1] to translate the damn thing to the binary anyway.

[1] Yeah the generic type "erasure" is a thing. That's reasonable only because those languages target slightly above the machine code (managed environments).

Sounds like you might like Lua+Rust or Scheme+Rust. Rust is still extremely young and all the first people to show up are by definition, the early, willingly converts. As it attracts more folks, it will get a wider spectrum of programmer and opinion. You could make an `Any` enum type and implement a ton of default traits for it, it might feel a little dynamic.

Luajit with it's ffi library for zero overhead ffi is amazing.

Even if you don't use Rust you can increase performance and reduce memory usage massively by simply defining the memory layout for your existing lua code.

http://luajit.org/ext_ffi.html#cdata

Static typing is useful in large codebases at big companies because it forces you to communicate your intentions clearly.

I disagree with the implication that static typing is not useful for small applications. Last week, I was writing a tiny GTK+ application (still < 1KLOC). GTK+ is not thread-safe, so you can only call GTK+ functions on the main thread. In this application, I wanted a separate worker thread, so that I could already visualize data while the application is still reading.

In Rust, you can only send data of a type that implements Send to another thread and share data of a type that implements Sync. Since Send/Sync are not implemented for gtk-rs types, sending/sharing data to/with another thread is a compiler error. This was immensely helpful in writing a program that uses GTK+ in a safe way. One could say this as the compiler being annoying, but having lived through enough C++/Qt threading bugs, I would rather have the compiler bail out with a clear error than debugging these issues at runtime.

> Static typing is a feature.

A feature is just an objective quality of a product that isn't contrary to the creators intent.

Features often have costs; but the desirable ones have benefits in some use that outweigh the costs in that use.

It's true that mandatory static typing with a sufficiently expressive type system is beneficial in some uses. It's also true that pure dynamic typing or optional static typing (of the mypy/Typescript sort) are. Now, obviously, the circumstances and users for which eachh is most are beneficial are different.

> but for whatever reason it seems extremely rare to discuss Rust's

At least within Rust spaces these get discussed at a regular cadence, in my experience. The usual pushback you see is "we're working on it", which is a valid response. I'm curious to see examples of what you're talking about, we try to push back hard on language zealotry in Rust spaces.

there is a culty vibe.

if i had to speculate why, it's that a lot of the more zealous Rust programmers simply have never had the skills or wherewithal to write in a systems programming language before. (I'd count myself in this category. I knew how to write half-assed scientific C++ but that's it.)

it's pretty intoxicating to finally be able to write code without a garbage collector and not screw it up, and be able to use a modern package manager at the same time to get all kinds of nice dependencies.

and getting over the borrow checker hump actually is one of those mind-expanding things like learning Lisp or Haskell is supposed to be. when I have to write C or C++ code now I have a little borrow checker living in my head helping me avoid mistakes.

these are very exciting experiences and the kind of thing that inspires zealous evangelism.

more experienced systems programmers, people who maintain major packages, and the Rust core team all seem to be a little more moderate in their enthusiasm even if they are huge fans of the language.

Seems like it’s time to decide for yourself?

I don’t spend much time or thought on what others have to say about which tech is the best for X/YEverything. I just learn it use it, and then make up my mind.

I like to look beyond to other languages, like Idris, ATS, Sixten, F*, Lean, Koka, etc. Rust has many clunky parts that become more obvious through use, even though it is still my goto language. I find often the most zealous folks are those who come from scripting language or Java/C#-ish backgrounds, and have not yet delved further into the possibilities of static types and higher order abstractions.

"Yes but real programmers don't really need a REPL" I'm hearing this for the first time. I don't call myself a real programmer but REPL is a godsend. There's no quicker way to test something - a small function, a numpy matmul etc

This is the exact reason I won’t learn Rust past looking quickly the doc: the promotion made by some very vocal people is a huge turn off. Notably by saying that everything must be rewritten in Rust, it implies that every other language is sh*t and people using them are dumb. Of course I don’t like that view for my work nor I won’t to be associated with this kind of people. This is a bit sad because the language probably have some interesting points, but the social aspect of it just don’t fit the bill.

> every other language is sh*t

Looking at how many CVEs are caused by undefined behavior and insecure properties of C, there is merit to the claim that Rust is objectively better than C in the strictness department and if safety/security is a major concern to you, you should absolutely choose Rust over C in new projects.

As for rewriting existing C software in Rust, the usual caveats for rewrites apply. Decades-old software like coreutils has had many eyes on the code, so the chance of catastrophic bugs decreases over time (but never to zero).

Just for the record, the annoying vocal promotion is not coming from the Rust team. The people who actually know the language know its limitations, and discourage overhyping it. Language flamewars are banned on all forums moderated by the core Rust community.

Where are you seeing these kinds of comments? Can you link me to them? I’d like to tell them to cut it out.

It's calmed down the past year or so but before that it was so insane (especially here on HN) that the impression will be hard to erase for those who were around to see it.

I was around, but still didn't actually see it. I see people complaining about it more than I actually see the comments themselves. That's why I always ask for concrete examples, and people never actually show them to me.

Reply on news.ycombinator.com