Rust Is Hard, Or: The Misery of Mainstream Programming • Hacker News Board

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#741

Post by AnIdiotOnTheNet » Sat, Jun 04, 2022, 2:20 PM UTC

Aardwolf wrote: post #734

AnIdiotOnTheNet wrote: post #731

Earlier quoted context omitted.

For a variety of reasons, Zig doesn't do warnings. Personally I don't get the big deal with unused variables being errors, from either direction. I'm not sure what it accomplishes to make them errors and I'm not sure why people complain so much about having to comment them out.

If you comment out a statement, you cannot know for sure how many unused variables this caused unless you visually scan the entire previous code, which can cost time. So the only way to find out is to compile and then have the compiler tell you that it refuses to continue because there's an unused variable at line X. So now you needed to do not one but 2 compiles, to do something that should have taken 1 compile, whi…

> Unless the language offers a way to fake-use the variable

Zig actually does have this:

  _ = my_variable;

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#742

Post by spopejoy » Sat, Jun 04, 2022, 2:58 PM UTC

Hirrolot wrote: post #169

mwcampbell wrote: post #156

Earlier quoted context omitted.

> So much of this pain is caused by premature optimization. Part of the problem is that Rust itself has such lofty aspirations to do it all (particularly "abstraction without overhead"), and is largely successful at that. So if I compromise on efficiency, it feels like my code is unworthy of the language it's written in. Also, it's easy to feel that the slightest inefficiency puts us on a slippery slope to the bloat…

I agree; if you use dynamic `Arc`s almost everywhere in your code, what's the point in a systems PL whose essence is in managing static lifetimes? Sometimes people use Rust just because many other languages suck; they are choosing between two evils: tedious programming in Rust or inadequacies of another language. It should not be like this. This is why I think we need a high-level, no-BS version of Rust.

Vote here for Haskell, which receives great hate on HN because it allows essentially unlimited abstraction.

Meanwhile it has one of the fastest concurrent+GC runtimes, obliterating Ocaml in this regard, and competing handily with JVM or CLR langs.

Finally, it has standard abstractions for concurrency and parallelism that are basically flawless.

Clearly, the hate comes from the association of Haskell with category theory, which is frankly useless/borderline harmful to the working Haskell programmer.

CT was critical to core library devs being able to deliver the main workaday abstractions that make Haskell such an unreasonably productive app languages. But since 2012 you can simply use these main abstractions and enjoy a level of safety and maintainability that rust, c++, ocaml, kotlin, java can't touch.

It's not perfect, but there's been huge improvements of late to tooling (cabal) so there's never been a better time. I really wish the tide could turn, because if you're willing to take on rust for low-level, you're missing out if you don't try haskell for everything else server-side.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#743

Post by llllllllllll9 » Sat, Jun 04, 2022, 4:29 PM UTC

steveklabnik wrote: post #717

llllllllllll9 wrote: post #710

i haven't met one dev whose interested in rust for solving a problem. they just want to rust for its sake. which is ok. whatever. but that tells you something.

Hi. Rust uniquely solves problems for us, and that’s why we use it.

awesome.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#744

Post by mikebenfield » Sat, Jun 04, 2022, 4:36 PM UTC

ncmncm wrote: post #681

mikebenfield wrote: post #646

Earlier quoted context omitted.

Rust is indeed changing pretty fast. But it's new. And most of the design decisions work well together. The language as of 2015-2016 was a reasonable language, and the changes since then have very rarely been of the form "This earlier design was a mistake, and we need to fix it all." But C++, even in its pre-template 1980s form, was already full of wrong decisions (granted, many of those decisions were done for compa…

In just another few years, if Rust does not fizzle, you will feel the same way about code in Rust as it evolves and improves. But how C++ was coded to older Standards was not wrong at the time. That code was chosen judiciously according to features of the language as it existed then, and our understanding of it and our world. Changes in languages are not random. Every last change in each new C++ Standard was in respo…

> In just another few years, if Rust does not fizzle, you will feel the same way about code in Rust as it evolves and improves.

I've written fairly extensive amounts of code in C, C++, Rust, Python, Java, OCaml, Haskell, Clojure, Common Lisp, Scheme, and probably some others that aren't coming to mind right now. All of these languages except Rust have been around for decades (and I guess Clojure is about a decade and a half). My opinion of these languages vary. They all have their warts. Some of these languages I don't particularly like. Some of them are complicated, some are fairly simple.

But C++ is the only one where I feel like the basic features of the language are actively working against me. It's the only one where I feel like such a huge portion of language design decisions were utterly baffling and wrong.

IME some members of the C++ community can be fairly insular. They just can't see how things are done outside their world. You expect me to believe that I'll eventually feel the same way about Rust as I do about C++, but I know that's unlikely to be true because C++ is the only language that I feel this way about.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#745

Post by adgjlsfhk1 » Sat, Jun 04, 2022, 4:51 PM UTC

pjmlp wrote: post #729

adgjlsfhk1 wrote: post #720

Earlier quoted context omitted.

imo, Julia is a better fit than rust or C++ for hpc/gpgpu

It might someday, still lots of room to improvement regarding current workloads. I not not seeing Fermilab or CERN doing real time beam processing in Julia anytime soon. Or stuff like having graphical shader debugging tools for Julia.

Julia already is starting to be used for high energy physics (see https://arxiv.org/pdf/2003.11952.pdf and https://www.youtube.com/watch?v=QlfAa-LN1SA for details). It's definitely not the default yet, but there absolutely is effort to use it for particle accelerators.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#746

Post by roblabla » Sat, Jun 04, 2022, 4:56 PM UTC

NoGravitas wrote: post #580

roblabla wrote: post #333

Earlier quoted context omitted.

> Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast. This is so interesting to me. I'm a Rust programmer by trade (as in - I'm not a hobbyist, I actually write Rust for work). We've found that, while the feature work is a bit slower in Rust than in other languages the company used to use (mostly Python), they tend to requ…

> We've found that, while the feature work is a bit slower in Rust than in other languages the company used to use (mostly Python), they tend to require a lot less maintenance down the line (less bugs, easier refactoring), and so it ends up canceling out a bit. Python to Rust is a pretty radical swing from one approach to language design to another. I'd expect you could solve most of the maintenance problems with Pyt…

Well, we have other reasons to chose rust rather than a GC'd language (mostly has to do a lot of FFI, which Rust makes much easier than go or Java). I do agree that, if GC'd language fits the problem space, they tend to be much better.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#747

Post by Larrikin » Sat, Jun 04, 2022, 6:47 PM UTC

WuxiFingerHold wrote: post #608

gwbas1c wrote: post #545

Earlier quoted context omitted.

I made the mistake of trying to learn Rust while doing async programming. IMO, when it comes to concurrent, it's a matter of picking your poison: Threaded Rust: No overhead of a GC, but overhead of context switches and multiple stacks. NodeJS: No overhead of context switches and multiple stacks, but the overhead of a highly optimized GC. (And I suspect that the GC can do tricks like run when the process is waiting on…

Unless you really need the best performance possible there're pretty good alternatives. Mainly C# or Go and soon JVM with Loom. Some numbers: https://web-frameworks-benchmark.netlify.app/result?l=rust,g...

Why the need to wait for loom when there is Kotlin and coroutines?

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#748

Post by iex_xei » Sat, Jun 04, 2022, 7:01 PM UTC

Aardwolf wrote: post #528

iex_xei wrote: post #426

Another data point: After writing / (re)writing 20K+ lines of code as a CLI side project in Rust (without touching async), I think I can say it's the best language for me after 20+ years of experience in other languages. I like the compiler, and I learn a lot from clippy. The "hard" part about Rust is you have to "unlearn" some of the basic mechanisms like scope and ownership that you bring from other languages. It d…

IMHO the time for doing analysis like this is before submitting code, not before compiling it. Ideally you want code without unused variables, implicit type casts, ... in a repository. But when you are locally testing out code you're in progress of writing, it is very unproductive if you have to care about unused variables because you're commenting out one line to see the difference, or change casts everywhere becaus…

I'm using cargo-limit crate for "cargo lcheck", "cargo ltest" or "cargo lclippy" to show errors before warnings before clippy warnings. You're right that "cargo check" gives the same priority to warnings as errors, and it's annoying.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#749

Post by iex_xei » Sat, Jun 04, 2022, 7:06 PM UTC

bergenty wrote: post #706

iex_xei wrote: post #426

Another data point: After writing / (re)writing 20K+ lines of code as a CLI side project in Rust (without touching async), I think I can say it's the best language for me after 20+ years of experience in other languages. I like the compiler, and I learn a lot from clippy. The "hard" part about Rust is you have to "unlearn" some of the basic mechanisms like scope and ownership that you bring from other languages. It d…

>unlearning scope As a programmer that hasn’t worked with Rust, what does that mean.

e.g. You can use a variable twice when calling a function in most languages without thinking twice. I had to unlearn this :)

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#750

Post by iex_xei » Sat, Jun 04, 2022, 7:10 PM UTC

hirrolot wrote: post #507

iex_xei wrote: post #426

Another data point: After writing / (re)writing 20K+ lines of code as a CLI side project in Rust (without touching async), I think I can say it's the best language for me after 20+ years of experience in other languages. I like the compiler, and I learn a lot from clippy. The "hard" part about Rust is you have to "unlearn" some of the basic mechanisms like scope and ownership that you bring from other languages. It d…

> without touching async The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code. Or he/she writes very-very straightforward, if not primitive async code and doesn't touch HOFs, traits, and similar stuff at all. However, when you write networking code, you typically use async. The worst role i…

That's probably true. I've experimented a bit with tokio for local IO bound tasks, but decided it's unnecessarily complex. I think some patterns will emerge from current Rust async development eventually. Good parts will be easier and bad parts will be removed, but digestion of such concepts usually require time.