Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Is Hard, Or: The Misery of Mainstream Programming

hirrolot.github.io

Post reply on HN
Print view View original

711–720 of 811 posts

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

#711

Post by leshow »

fizzynut wrote: post #572
crabbygrabby wrote: post #549

Earlier quoted context omitted.

Won't let me reply to fizzynut, but this is a reply to you. Yes making data structures is important, and the reality of that is, there are people in the ecosystem creating fancy ones which can be leveraged for your use case. If that doesn't exist then yea you have to write them. Sometimes that's difficult(you need to use unsafe), sometimes it's easyish and you can use all safe(I did this for a graph type). It can be…

Lots of people writing their own data structures and libraries should be a reflection of the different needs and diversity of the ecosystem, but if it's a reflection of difficulty then it tends to lead to a much narrower ecosystem. That isn't to say a narrow ecosystem is necessarily bad, it can often be good if a particular language is used for a specific domain as all the libraries and data structures will likely be…

The fact is that writing a doubly linked list correctly is hard and it's easy even for veterans to miss things. Rust is going to put those invariants in your face.

My advice would be not to judge any language on how easy it is to implement a doubly linked list. 99% of code you write will likely not be that, and that particular data structure exposes a lot of choices and trade offs at a time when youd be better served learning other parts of the language.

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

#712

Post by llllllllllll9 »

HacklesRaised wrote: post #275

Is rusts most loved status simply Stockholm syndrome? I've really tried with rust, and we simply don't get on. I hear all the arguments about CVEs and wonder if rust will reduce the number of these problems simply by disabling the programmers that create them. I understand the draw, I want to love it, but i think I might not be smart enough.

rust == https://en.wikipedia.org/wiki/New_Math

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

#713

Post by llllllllllll9 »

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…

https://dropbox.tech/application/our-journey-to-type-checkin...

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

#714

Post by Hirrolot »

orangetuba wrote: post #274
VWWHFSfQ wrote: post #8

I've been programming in Rust for the last few years. My daily work is mostly just fumbling through compiler errors until the code works. Some observations: - The compiler is always right. - Do what clippy and rust-analyzer says. Don't ask questions. - If you're fighting the compiler, clippy, AND rust-analyzer, then you're almost definitely wrong. Virgins try to use &str everywhere. Chads just use String.

I wonder what approach acts as the best mentor for someone who wants to eventually develop a good mental model for how systems work. The C approach where you suffer at runtime and then have to debug ferociously, or the Rust approach where your mentor hits you with a stick all day?

I had C programming experience before touching Rust. I may be biased, but I think this is the right way to understand how computer systems work. Otherwise, Rust's design choices will make little sense to you.

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

#715

Post by skohan »

CraigJPerry wrote: post #678
skohan wrote: post #596

Earlier quoted context omitted.

I'm not a go expert, but imo the main difference is ergonomics and clarity. Rust/Swift style ADT's plus pattern matching gives you a very concise and readable way to declare and use sum-types, and the Go way seems to have more boilerplate. Also with Rust for instance you have more robust pattern matching. So you don't have to match only on type, you can match on complex criteria (i.e. foo is a Circle, with foo.radius…

>> I'm not a go expert Yeah me neither, i’ve just been dabbling for fun recently. I’ve been dabbling with rust for longer >> the Go way seems to have more boilerplate … switch t := s.(type) { case Circle: if t.radius https://go.dev/play/p/s4TTZeo7Gse Definitely less boilerplate in the rust version, but i don’t think i go along with it being incomplete or less clear.

I think this is less clear than. The rust/ swift version.

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

#716

Post by gwbas1c »

capableweb wrote: post #546
gwbas1c wrote: post #543

I've been toying with Rust on and off for a few years. I find it very difficult to be productive for many of the same reasons that TFA lists. > Finally, imagine that Rust’s issues dissapear, it is high-level, and has uniform feature set. That would presumably be close to the theoretical ideal of a high-level, general-purpose programming language for the masses. Funnily enough, designing such a language might turn out…

Minor correction: Rust does need a runtime (normally), it's just very small and embedded in the binary, so it mostly seems nonexistent, but it's there :) More info: https://prev.rust-lang.org/en-US/faq.html#does-rust-have-a-r... Not to take away from your overall point, which I agree with.

Oh, don't argue semantics. It's not like I have to tell someone to install .Net, Java, Python, ect, in order to run a Rust program. (Or figure out how to bundle it in an installer.)

By your logic every language, except for assembly, has a runtime.

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

#717

Post by steveklabnik »

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.

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

#718

Post by noisy_boy »

sph wrote: post #578
Aardwolf wrote: post #528

Earlier quoted context omitted.

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…

This is one recent change in Zig which really annoys me: unused variables are now errors. Languages that complain every time there's a unused variable become useless during experimentation and quick hacking. They turn my hyperfocus into a death from a thousand paper cuts. I hate it with a passion. Please respect my mental flow, if I'm trying some ideas out, it's just rude to stop me in my tracks to tell me I forgot t…

I have to agree with you. Zig already has a Debug build mode, they can just warn if you are running Debug build.

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

#719

Post by adgjlsfhk1 »

crabbygrabby wrote: post #654
WuxiFingerHold wrote: post #615

Earlier quoted context omitted.

Or use a GC language with a great typesystem and have both safety and fast efficient development cycles.

That is an option, or if you don't want to deal with a GC because it's eating 70% of your clock cycles under load you can use rust get performance gains and still be writing safe code...

if your GC eats 70% is your clock cycles, your language has a broken GC. in modern Java/C#, GC time is rarely more than 10%

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

#720

Post by adgjlsfhk1 »

pjmlp wrote: post #481
School-Cotton wrote: post #469

Earlier quoted context omitted.

Rust is supposed to be a better C++, and resoundingly succeeds at that goal.

It partially succeeds at that, because while it has a much better story in being safe by default, there are plenty of C++ use cases where Rust still hasn't a story to sell. HPC, HFT, GPGPU, LLVM/GCC infrastructure, GUI, console SDKs, drivers SDKs, security certification ,....

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