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

731–740 of 811 posts

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

#731

Post by AnIdiotOnTheNet »

noisy_boy wrote: post #718
sph wrote: post #578

Earlier quoted context omitted.

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.

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.

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

#732

Post by Diggsey »

ncmncm wrote: post #610
Diggsey wrote: post #409

Earlier quoted context omitted.

> Rust provides very substantially less support to library designers than C++ does. Anyone creating ambitious libraries finds Rust a big step down. Before I used Rust my main language was C++ where I specialized in writing libraries, and this is a ridiculous statement. It's only recently that the C++ standard library has gained enough functionality to do even some basic things in a portable way, so you're relying on…

What makes UB in C++ is spelled out in its International Standard; there is no specification for Rust, just an implementation. It has been many years since C++ preprocessors differed notably from one implementation to the next. Nothing in C++ is global except what you choose to make global. In fact today C++ lifetimes are expressed in the type system, and this is an example of what C++ enables a library to provide. I…

> What makes UB in C++ is spelled out in its International Standard

That's not true, the standard only specifies that some things are UB, it is not exhaustive, nor is it unambiguous. Furthermore, no current C++ compiler is compliant even with those parts of the standard which everyone agrees on (eg. see proposals to introduce a "bytes" type to LLVM to resolve known miscompilations). There is work to improve this, such as defining an explicit memory model, but Rust is ahead of C++ on this.

> In fact today C++ lifetimes are expressed in the type system, and this is an example of what C++ enables a library to provide.

Do you have an example of this, or are you talking about using smart pointers? Smart pointers are about ownership, not lifetimes.

> Your remarks suggest that libraries you delivered were closer to C than C++.

Most of my remarks were about consuming other libraries from my library, which is not something I have control over. Sure, I can use smart pointers and other modern C++ features in the API I expose... That doesn't change any of the points I mentioned.

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

#733

Post by capableweb »

gwbas1c wrote: post #716
capableweb wrote: post #546

Earlier quoted context omitted.

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.

I'm not arguing, just adding some detail to a slightly incorrect fact.

It's true that you usually don't have to ask anyone to install anything else to run a Rust program, because the default experience of using Rust + Cargo bundles the runtime for you. But the same can be done with the languages you used as examples as well. Many programs do in-fact include .net, a JVM or a Python runtime so the users don't have to care about it.

Biggest example is probably Blender, which ships with Python (and doesn't require a installer). Many IDEs made with Java also ship their own JVM runtimes.

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

#734

Post by Aardwolf »

AnIdiotOnTheNet wrote: post #731
noisy_boy wrote: post #718

Earlier quoted context omitted.

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

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, which also costs time.

But it's then also possible that due to commenting out line X, there's now yet another unused variable (or more) somewhere. Etc... (Unless the language offers a way to fake-use the variable, like (void) cast in C++. Then at least you only have one wasted compile and not recursively more)

And then if you want to enable the original line that you commented out again, you need to also remember to uncomment out those other lines.

Repeat this process many times a day when really in progress of developing something, and due to the total time it costs for this silliness it's just a bad tool, not a good tool for efficient programming in the flow.

The goal of the unused variable as error is to prevent bad submitted code, but that should not cost you time during development. Only enforce that check at the end, not during.

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

#735

Post by kaba0 »

gwbas1c wrote: post #545
logicchains wrote: post #535

Earlier quoted context omitted.

People talk about C++ suffering from its commitment to zero-cost abstraction, but the same thing applies to Rust async. While async may theoretically be the fastest possible way to write asynchronous code, it feels like an order of magnitude more painful than the CSP/channel-based approached used in languages like Go and Clojure (and the upcoming Java Loom). Personally if I had to write async code that required anyth…

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…

> No overhead of a GC, but overhead of context switches and multiple stacks.

Is it really an overhead if it happens in parallel? You have real parallelism, not only concurrency.

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

#736

Post by skohan »

CraigJPerry wrote: post #725
skohan wrote: post #715

Earlier quoted context omitted.

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

That’s fascinating, what would you say obscures clarity? Go: https://go.dev/play/p/s4TTZeo7Gse Rust: https://play.rust-lang.org/?version=stable&mode=debug&editio... For me, i reckon the Go type machinery is more verbose in this case, e.g. the isShape method to tag Circle as a shape - that just feels awkward to me. The cyclomatic complexity is identical for both though.

Yeah exactly, imo the way the Go version requires you to declare an interface, in this case with a no-op method essentially acting as a tag, and declare conformance on your types is quite noisy and feels like a hack.

Also I prefer with Rust-style sum types that the declaration happens in one place. In the Go version your Shape types could be scattered around all over the place, which makes it harder to parse and understand if you're reading unfamiliar code.

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

#737

Post by kaba0 »

AnIdiotOnTheNet wrote: post #731
noisy_boy wrote: post #718

Earlier quoted context omitted.

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

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.

Yeah, basically what the other commenter wrote - it requires potentially many changes recursively.

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

#738

Post by [deleted] »

foldr wrote: post #674
ngrilly wrote: post #650

Earlier quoted context omitted.

> I can assure you that you cannot access undefined memory regions by doing this in Go. Current implementation of slices and interfaces in Go is not memory safe in presence of data races: https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...

This is the kind of edge case you can find in lots of languages, including Rust (which has plenty of past and present soundness bugs).

[deleted]

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

#739

Post by michaelcampbell »

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…

> It doesn't allow you to build quick and easy solutions that allows you to lie to yourself (or your boss.)

A quick and easy solution is still a solution, which is what most bosses want.

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

#740

Post by SleepyMyroslav »

Animats wrote: post #722
SleepyMyroslav wrote: post #688

Earlier quoted context omitted.

Cool video that matches best practices. Reducing memory footprint is always good and laying out things in memory is also good way to speed things up without changing amount of work. I have trouble with concept of WGPU. GPUs are complex by themselves to bolt on top any abstraction that is coming from Web. But its just me, its not important since I am not a 3d programmer myself. I am more Engine / CPU optimization guy.…

We'll see how it works out. WGPU's API is basically Vulkan. It exists mostly to deal with Apple's Metal. Metal has roughly the same feature set as Vulkan, but Apple just had to Think Different and be incompatible. I'm not supporting the Wasm or Android targets. Android and browsers have a different threading model, and I don't want to deal with that at this stage. Linux/Windows/Mac is enough for now. Thought for the…

Gaming solved same problem by opting out of Apple rendering API support. ( ahaha ). Those who have to support mobile can't skip it ofc.

I dont work with VR/AR myself so I dont know.

Post reply on HN