I feel Go and Rust are great options for writing modern server side applications today, but they exist on two different ends of the spectrum. The Go language is highly minimal, constrained, and forces devopers to write unified code, that performs extremely fast idiomatically. This uniformity is helpful for open source collaboration. Rust is a much more robust language (eg generics), but is more complicated to pick up and harder to read by comparison. Imho, Go is ideal for general web services, while Rust is better for system apps, tools, or complex web services like real-time exchanges or financial systems. This is just a general guideline though in my mind.
Why is Rust difficult?
31–40 of 260 posts
Re: Why is Rust difficult?
#32Isn't the problem with Rust that it uses crappy pessimistic heuristics (borrow checker) for essentially NP-C problem, causing complaints where code is perfectly OK? IMO interesting design decision but I am staying away precisely because of this.
"Crappy pessimistic heuristics" Are you talking about the borrow checker from half a decade ago? [0] Have you used the language since then? This is FUD -- it's really not hard to get code past the borrow checker anymore. Maybe every thousand lines or so you'll need to add a block or pull a temporary variable out of a one-liner, but the compiler basically tells you exactly what to do when something like that is releva…
Oh, I'd love if that were true. But in my limited experience with Rust it was still the borrow checker that absolutely made writing in the language hard. That was in 2017. My mental model of what should be safe was not at all the model the borrow checker had. And I really read the documentation about that part of the language.
I guess a confirmation that there were problems there is that they tried to improve the borrow checker in the releases after that.
Re: Why is Rust difficult?
#33One of these days I'll get around to Rust. I don't think it's fundamentally difficult, just different from most people's cowboy programming. I'm much more excited these days about program extraction from verified programs written in Idris or Coq, which is on a whole other level of pain and suffering.
Re: Why is Rust difficult?
#34Earlier quoted context omitted.
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 un…
> 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).
Re: Why is Rust difficult?
#35One of these days I'll get around to Rust. I don't think it's fundamentally difficult, just different from most people's cowboy programming. I'm much more excited these days about program extraction from verified programs written in Idris or Coq, which is on a whole other level of pain and suffering.
Does anyone have any experience regarding TLA+. Does it make formal verification at least slightly less painful?
Re: Why is Rust difficult?
#36Earlier quoted context omitted.
This is not my experience using Rust. I had six months of programming experience when I first tried Rust. I definitely got confusing errors at first, but I grasped the system within a month or two. And that was in 2014 - the borrowchecker and especially its errors have way improved since then! But this is also a very different objection from your initial objection, which was just a statement of fact about type system…
I'll take a look once I am done learning another hot language ;-) Thanks!
So your issue isnt about rust, its about changing popularity and language trendiness?
Re: Why is Rust difficult?
#37I like Rust so far, but there's a few things I think aren't true:
* That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how. I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equally memory-safe languages that go about enforcing safety in entirely different manners than with ownership and lifetime semantics.
* In fact, the entire idea that Rust enforces correctness. Only if your definition of 'correctness' to be memory-safety, but I would normally define 'correctness' to include rigorous mathematical proofs. Rust's safety guarantees are often accidentally blown out of proportion; they mainly aid in preventing security and concurrency bugs, but only a certain class of each. This is still useful, but this caveat really needs to be in your face more often, as a lot of people will not mention it when touting the benefits of Rust, and beginners can get easily confused about what exactly Rust prevents you from doing.
* The idea that Rust's approach is always worth the trade-offs. Go is another programming language I like, and there are definitely things that are simply easier to write in Go with few disadvantages. Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems like, often, web servers, where each thread is usually independent in terms of mutable state, Go works wonderfully. It also lets you shoot yourself in the foot in a way that Rust wouldn't, but often for a lot of simpler apps it still ends up being easier.
* The idea that solving the compiler errors makes you understand the problems correctly. For example, you could always just clone memory at every occasion, return the input instead of borrowing, etc. In fact, these things might be easier for a beginner to do. There will probably be a ton of Rust anti-patterns that come about from trying to resolve compiler errors.
Re: Why is Rust difficult?
#38Is 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…
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.
Re: Why is Rust difficult?
#39Earlier quoted context omitted.
Is it? Could you give an example? I've found a borrow checker bug in the current release but the rest of the time its behavior is perfectly predictable. Granted, I wouldn't be surprised if the documentation was horrible, my understanding of the checker is based on one way I would do it.
It's simply one more thing you need to keep in your internal "context" while writing a program, taking mental resources you could spend elsewhere. Perhaps an IDE guiding you and outright rejecting the code or offering code completion that is compatible with borrow checker might be a solution, though we aren't there yet I believe.
You have to keep the kind of problems the borrow checker nags you about in your mind anyway. Memory errors and concurrency problems don't go away because the compiler doesn't complain about them. Personally, I find it easier to use Rust than C++, because I don't have to worry so much about iterator invalidation and stuff like that.
Re: Why is Rust difficult?
#40Is 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…
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.