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.
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”).
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.
* 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.
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.
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".
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.
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 :)
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.
C offers an appropriate level of memory safety for the problems it solves. I take managing my own memory over unreadable code and dependency hell any day. The fact that C will run on DSPs with 27-bit pointers is just an added bonus. The ease of manual memory management in C is an advantage, not a downside.
And the tooling for C will exist long after rust has been abandoned.
args.into_iter().skip(1).and_so_on...
for arg in args[1..*] { ... }
(for-each do-something
(slice args #:from 1))
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.
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.
fn main() {
let args = vec![1, 2, 3, 4, 5];
for arg in &args[1..] {
println!("{arg}");
}
}