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

621–630 of 811 posts

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

#621

Post by foldr »

Shikadi wrote: post #613
foldr wrote: post #601

Earlier quoted context omitted.

There seems to be a myth that Rust is unusual in being memory safe. All modern GCed languages are memory safe (assuming you don't do anything obviously unsafe like manipulate raw pointers, which some languages might let you do if you really want to). >It is ironic to build super safe software, then deploying them on kubernetes, written in a GC'd language prone to nil dereference errors. Nil dereference errors don't d…

I'm not sure if you understand what safe means in this context. One common example is modifying a vector element by reference. If you grab a reference to an item, push something else to the vector, then try to access through that reference, the vector may have re allocated during the push and you're either no longer looking at valid memory because it's been freed, or you're looking at a stale copy of the element. I d…

I'm 100% sure that I understand what safe means in this context. All modern GCed languages are memory safe and will not access invalid memory regions unless you use specifically unsafe features.

> One common example is modifying a vector element by reference. If you grab a reference to an item, push something else to the vector, then try to access through that reference, the vector may have re allocated during the push and you're either no longer looking at valid memory because it's been freed, or you're looking at a stale copy of the element.

There aren't that many languages which both use GC and allow you to take references to elements of a vector. Go would be one example. I can assure you that you cannot access undefined memory regions by doing this in Go. (What would happen is that the original allocation backing the vector would be retained in addition to the new allocation.)

>If no code handles the nil exception for example then it's no better than crashing as you would in C

C programs are not guaranteed to crash when a pointer has an invalid value. Dereferencing a NULL pointer will reliably cause a crash if you're running the code on top of a modern general purpose operating system with memory protection, but invalid pointers (which don't necessarily have to be NULL) have the potential to access arbitrary memory regions without raising any kind of error.

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

#622

Post by marcosdumay »

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 is really great for a large subset of problems where there are really no good alternative. (Low level problems, where the next best alternative is C or C++. And if C++ looks better than C, it's probably not low level enough.)

But if you deviate from those, into higher level programs, a language with garbage collection will always be much more productive than Rust. So we have a set of people doing the things that Rust does best, and celebrating that they have a great language, and a set of people trying to fit the square language into a round hole, and complaining that it doesn't fit at all.

Added to that, there is a wide space of problems where high-level languages do not have appropriate support, but you can always hack your way in with a low level one. Those are the worst, because there is just no good option, there's just one that you can beat into working.

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

#623

Post by the__alchemist »

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…

On embededded, you can write straightforward asynchronous code without using *Async*. You do it using DMA, and interrupts, perhaps with static analysis etc. There are efforts to use Async on embedded rust to abstract these, but it's not required.

Of note re networking: My observation is that the Rust Async ecosystem only covers TCP and higher. There are loads of Async TCP, HTTP etc libs, but nothing that can do anything lower than that! At that point, you're looking at perhaps `socket2`, and `smoltcp`; the latter, of note, also works on embedded, and goes lower than TCP, despite its name.

My best guess is that a lot of people are using Rust for TCP and HTTP level web programming, eg servers, where spawning 100s or more IO-bound processes at once makes sense; the area where Async shines. Why I'm confounded: #1: Rust excels at low-level programming; ie it's one of a select group capable of this (Along with C, C++, ADA, and zig) #2: Web application programming in Rust has a long way to go to get to the level of Django and Rails. It only has Flask analogues.

Neither of those goals are served by the existing Async-based ecosystem; it occupies a spot in between.

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

#624

Post by wheelerof4te »

sph wrote: post #451
karmakurtisaani wrote: post #441

Earlier quoted context omitted.

I kind of hit a wall with Rust after realizing that something like doubly linked lists are difficult because when two nodes are referring to a node between them, you don't have a clear owner. So basically all situations where you have two or more references to an object need to be thought out carefully, and for me it was a bit of a let down (even though I fully understand the reasoning behind it and why it's useful).…

Unpopular opinion but the whole memory safe idea is more niche than HN commenters would have us believe. Most of us are writing web apps and services that do not have strict memory requirements nor catastrophic failure modes. Dynamic languages and GC'd languages cover most of what our employers are paying us for: web apps, backend services. It is ironic to build super safe software, then deploying them on kubernetes,…

"It is ironic to build super safe software, then deploying them on kubernetes, written in a GC'd language prone to nil dereference errors."

This is something that escapes a lot of people nowadays.

Everyone uses a browser and they are inherently unsafe.

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

#625

Post by Shikadi »

logicchains wrote: post #541
whazor wrote: post #386

Earlier quoted context omitted.

Rust makes it easier and faster to create certain classes of applications, specifically applications that originally would be written in C and C++. Things that are hard in Rust, are even harder in C and C++. So Rust is liberating and 'rewriting' complicated applications can be satisfying because you can move faster. For me personally I am playing with Wayland and display streaming and it is very satisfactory so far t…

>Things that are hard in Rust, are even harder in C and C++ This is absolutely not true. Something hard in Rust but almost trivial in C++ (via fold expressions): mapping or folding a function or operator over a tuple of heterogeneous types. E.g. to sum over a tuple of arbitrary numeric types: auto mySum = std::apply([](auto... x){ return (x + ...); }, myTuple);

Wouldn't this be a nearly identical call, but specifying the add trait? I'm still learning so I'm not sure if I'm missing something

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

#626

Post by WuxiFingerHold »

heurisko wrote: post #359
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.

I am interested in Rust because of its safeguards around multithreaded programming. This is is my main motivation to learn it. What I've found good about rust is its modern toolchain and documentation.

The hardest multithreading related bugs are deadlocks, which Rust doesn't prevent. So this "fearless concurrency" mantra is not entirely true.

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

#627

Post by tarator »

Excuse my ignorance but my small experience in Rust convinced me that the language actually promotes functional programming (you get bizarre errors when trying golang or c++ style of programming). Registering handlers doesn’t sound functional at all. Quick search about reactive functional streams leads me to interesting solutions. For example tokio::sync::broadcast. I would love to hear your opinion on this.

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

#628

Post by andrepd »

logicchains wrote: post #567
HWR_14 wrote: post #561

Earlier quoted context omitted.

> 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. Async code is a pain in almost any language. Certainly any language that differentiates between async code and non-async code has the async code be a pain.

Writing this kind of async code in Haskell (and to some extent OCaml) is much nicer, because you can abstract over the asyncness of code. This can't be done in Rust or C# because the type system isn't powerful enough (no higher-kinded types). To be fair, adding HKTs to Rust's existing type system is a challenging theoretical problem in itself.

Sure, but the exchange is that you get worse performance.

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

#629

Post by Animats »

SleepyMyroslav wrote: post #418
Animats wrote: post #279

Earlier quoted context omitted.

> Rust is normally used only when high performance is of uttermost importance, so it will always attract people who want to optimise everything. Which is not the way to do things. Profile, then optimize. I'm writing a metaverse client that's heavily multithreaded and can keep a GPU, a dozen CPUs, and a network connection busy. Only some parts have to go fast. The critical parts are: * The render loop, which is in its…

Coming from gaming industry i think you might want to measure how far you can go with a single threaded rendering. There is limit of content and code that can be a brick wall later. Here is an example from SIGGRAPH 2021 where Activision presents how multithreaded rendering looks like: https://youtu.be/9ublsQNbv6I ps I don't work with Activision its just a public example that illustrates industry practice.

I'm using Rend3/WGPU, where multithreaded rendering is coming, but isn't here yet. Work is underway.[1]

The Rust game dev ecosystem is far enough along for simple games, but not there yet when you need all the performance of which the hardware is capable.

[1] https://www.youtube.com/watch?v=DDG4bcGs7zM

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

#630

Post by Shikadi »

sai_c wrote: post #447
Dowwie wrote: post #391

Earlier quoted context omitted.

It's not a matter of smarts but grit. Modern society cultivates short attention spans, impatience, and a need for instant gratification. It's really uncomfortable, and costly, for many to spend hundreds of hours cultivating a new skillset. So, many give up shortly after starting to pursue it. However, those who persist and achieve capabilities come to value what those capabilities offer over alternatives.

If you ask an embedded developer (as in bare metal, no OS), who is also into electronics, instant gratification and especially instant feedback, is what actually makes you choose this path of interest in the first place. It's a matter of style and character how you cultivate new skills, and Rust wants you to cultivate them in a certain, some people are just not made for. YMMV.

I'm an embedded developer, and for me it's the opposite. Not saying everyone is like me, just saying not everyone is like you. I find regular software development to provide more instant gratification, I like the result of systems interacting with each other physically. Something about that just feels really cool to me. So much that I spent a few years as an FPGA developer, designing hardware and writing drivers for it, and also writing C on a soft core microcontroller running on an FPGA, touching registers that configure things, messing with i2c busses, I just find it all really amazing, in the same way I find car engines spinning at 6000+rpm and managing timings is incredible. Regular software development has faster results and gratification, at least from my perspective. And to be clear, I'm not saying you're wrong, or that your perspective is any less valid than mine
Post reply on HN