> Do you not value the increased memory safety?

Sure, but the way that rust does it comes with a heavy cost, including slow compile times and confusing lifetime semantics (and, in my subjective opinion, poor syntax). There are other techniques to achieve memory safety that are simpler and more ergonomic (to me at least) than borrow checking. Vale, for example, has some interesting ideas in this space.

One of the main reasons that people complain about rust is because it has an extremely loud group of evangelists who often shame other people for taking a different approach and essentially refuse to acknowledge that others have a point about its weaknesses. It is always off-putting when a community goes around telling everyone else that they are doing it wrong, particularly when they are ignoring the very real flaws in their own way of doing things.

> One of the main reasons that people complain about rust is because it has an extremely loud group of evangelists who often shame other people for taking a different approach and essentially refuse to acknowledge that others have a point about its weaknesses.

Name them. Maybe you don’t have real names but you can probably cough up some Internet handles.

The “fanatical rustacean” is a bit of a 2018 thing. Out of the few who are actually evangelists I an fact think that they can be way too nice and conflict-averse (“right tool for the job”).

You realize I was responding to a comment in which the OP asked why we don't like memory safety? That is exactly what I an talking about. The coder's internet is filled with this type of attitude. You can disavow these types as not real rustaceans or whatever, but this language definitely attracts purists, which makes sense given that its main selling point is a form of purity.

The loudest voices in Rust that I know (pcwalton, steveklabnik, burntsushi, on HN for example) clearly acknowledge that Rust makes tradeoffs.

No one denies that there are "simpler ways to achieve memory safety". Stop-the-world garbage collection and reference-counting are exactly just that. Vale uses generational references, which, IIUC, has both memory and runtime costs when compared to the borrow checker.

Some incorrect assumptions:

* Rust does not have slow compile times compared to C++. They are often faster. Linking tends to be the slow part. C++ compilation speeds suffer heavily from header files. * Lifetime semantics can be confusing in any language. In C++, you ignore it, you get crashes from dangling pointers. In Rust, you ignore it, you don't get it compiling - which forces you to think about them. The lifetime concerns are always present unless you're using a garbage-collected/reference-counted language.

My experience is that the Rust community is very tolerant and patient. Can you cite an example where a "loud evangelist" shames other people? Also, in my experience, when that happens they are criticised by the same Rust community.

Every single community has the 1% bad apples. As a Rust dev I refuse to be associated with zealots and fanatics. Every single other Rust dev I've ever worked with was a normal programmer, namely a pragmatic analytical type.

Stop parroting memes. "Rust evangelists strike force" and "Rewrite it in Rust" do not actually exist.

Point me at your local hobby or professional club and I bet my neck I'll find you at least one fanatic. But I will not use that to deride your hobby activity. So don't do that for Rust, please. The community is huge and doesn't subscribe under the fanaticism of a few loonies.

Rust restricts what you can do when it can't reason about your code. Some developers don't like those restrictions and feel like they're "fighting the borrow checker". Others don't think it's worth it and go back to managed languages.

It's usually something like "I don't need the compiler holding my hand, I know what I'm doing", or "I'll just write in Go/Java/etc. so I don't have to worry about memory".

From my experience its not the language that is the issue, its usually people with little to no experience in the language parroting what they have heard online.

Whenever anyone that gives it a serious try to build something and does not become a convert that touts its greatness as the one and true go...language they are usually given the no true scotsman treatment or a variation of the emperor's new clothes.

TBH, I don't have a problem with Rust so much as I have/had a problem with a section of the rust community.

The shouting fanbeings of rust put me off looking into it for years, because when I kept getting "rewrite it in rust!" as the answer to "there's a problem with $THIS_CODE" when talking with colleagues, _even when those colleagues had minimal rust experience_, all I could conclude was that the whole thing was an empty promise and that no-one knew how to solve the problem, but everyone "knew" that the New Cool Language was the way to fix everything.

Generalisation from incomplete data - no doubt there was a sensible majority in the rust community, but the fanbeings were _loud_.

FWIW I was wrong: I'm getting into rust now and I like what I see, and the discussions around it online and with colleagues are pretty sensible. But, it's taken a while to get there and when you've been in tech for a couple of decades you see this hype cycle and get jaded to it. Erlang is the new hotness ... OCaml is the new hotness ... Java is the new hotness, rewrite everything in Java, wait C# is the new hotness...

I suspect rust is here to stay, and I'm gonna learn more about it, and I regret some of my past words about it. But my problem was never with the increased memory safety, or the language at all, pretty much, just the early community.

TL;DR: Other humans are the worst, bug reported, fix unlikely :)

Rust's community is huge and I'm a fairly late adopter. I haven't seen any shilling or fanboying.

Let's not judge a whole tech stack by a few loud evangelists?

That tech stack has undeniable advantages. I'm focusing on that and don't pay attention to the emotional types.

And it's IMO a flawed judgement technique to distance oneself from technology because some randos struck you as fanatics.

Go and judge for yourself on the ground, experimenting. It's the only way to be sure.

Glad you're coming around btw.

I would like Rust a lot more if it got rid of methods. Instead of writing something like...

  args.into_iter().skip(1).and_so_on...

Which I can't stand to look at, I'd vastly prefer something like...

  for arg in args[1..*] { ... }

Though my true preference would be S-expressions, but I realise that people lose their marbles when they see something like...

  (for-each do-something
    (slice args #:from 1))

Of course Common Lisp is one of the faster slow-as-molasses languages, but having a language that uses S-expressions which can compile down into a small, fast binary would be the dream. Carp would be interesting if it didn't use Clojure syntax.

Slow as molases? I will assume you have actually written quite a bit in it since you seem to like s-expressions and I really can't think of any other language other than lisps that use them.

With that in mind, what other lisps are running circles against common-lisp? I would love to give those languages a try. From my experience sbcl common-lisp is about equal to Go and Java which I consider pretty fast languages.

Its not as fast as C,C++,Rust but when I think of slow I think of Python, not lisps.

> With that in mind, what other lisps are running circles against common-lisp?

Well, I haven't tried any of the Linear Lisps, but as far as I know it's the fastest Lisp. That said, well-written C or Fortran will run circles around it.

> From my experience sbcl common-lisp is about equal to Go and Java which I consider pretty fast languages.

SBCL is amazing, it's really fast (though LW beats it in certain situations), but it's in the same class as Go and Java, which I consider dog slow. Modern computers are really, really, stupendously, ludicrously fast; but many programming languages don't give our computers a chance to really shine, which is a shame.

Basically it's like... an F1 car is really fast as long as you don't compare it to a fighter jet.

You can write almost exactly what you wrote, if you prefer

    fn main() {
        let args = vec![1, 2, 3, 4, 5];
        
        for arg in &args[1..] {
            println!("{arg}");
        }
    }