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

281–290 of 811 posts

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

#281

Post by olalonde »

AndrewGaspar wrote: post #195
Hirrolot wrote: post #169

Earlier quoted context omitted.

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.

> This is why I think we need a high-level, no-BS version of Rust. F# is probably what you're looking for if you want functional-lite programming with a strong type system, but don't want to deal with the pains caused by static resource management.

It might sound superficial but the simple fact that there is seemingly a hard dependency[0] on Visual Studio (Code) is a major turnoff for me. I am quite attached to my Vim/command line workflow.

[0] https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/i...

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

#282

Post by lumost »

mikojan wrote: post #260
ThePhysicist wrote: post #250

Just got started with Rust and yeah, my biggest pain point so far were lifetimes and async code. I finally replaced tokio with multithreaded blocking code, which seems to be much simpler and more familiar. The problem with async was that some of the libraries I needed (e.g. for QUIC) didn't support it, so you had an unholy mixture of blocking and non-blocking code. Coming from a C++ background I appreciate Rust's nov…

I've successfully replaced tokio with the lower-level mio in one such case. After all threads and async serve different purposes: Threads when you're computing a lot, async when you're waiting a lot, no?

Threads work OK for concurrency in many apps. The developer cost of async may not be worth it in many cases.

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

#283

Post by ncmncm »

mikebenfield wrote: post #239
LoveGracePeace wrote: post #157

I'm very confused. Rust is mainstream? C, C++, Java, C#, Python, JavaScript are all what I would call mainstream. Rust is not a language that comes to mind at all.

Pretty damn mainstream nowadays, yes. Quite a few big tech companies are either actively doing much of their new systems programming in Rust, or else dipping their toes in. I honestly don't know of a big tech company that is happy with the idea of just continuing to use C++ indefinitely - they are _all_ looking for alternatives, and Rust is the most obvious option.

More people pick up coding C++ professionally in any given week than the total being paid to code Rust full time.

The bigger a company is, the more various languages people there dabble in, and the less it means that somebody there dabbles in your favorite. You would better add up revenue (NB: not market cap) of companies specializing in using your favorite language; but that number would be disappointingly small for any language as far from maturity as Rust still is.

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

#284

Post by [deleted] »

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.

[deleted]

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

#285

Post by lelanthran »

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.

It's a language designed by people who's favourite language is not even pronounceable.

Did you think that such a group of people, who place their love for the language above practical things like readability, would come up with a new language that cared about the user-experience[1]?

As we see all the time WRT to programming languages, readability is more important than the more abstract stuff.

> 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.

That sounds like a different way of saying "the global number of CVEs will be reduced by reducing the number of applications written". After all, if you "disable" the programmers who write systems programs, they aren't going to get magically replaced by programmers who don't write systems programs.

You're just gonna have fewer programmers.

[1] A language is an interface between a user and their problem. If this is not highest priority of a language design, the language may never take off in any meaningful sense. See Monads.

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

#286

Post by renox »

tick_tock_tick wrote: post #126
megous wrote: post #79

Earlier quoted context omitted.

Re: fearless concurrency... Would Rust prevent you in general from writing code that could deadlock, btw? Thread1: takes lock A, ..., tries to take lock B Thread2: takes lock B, ..., tries to take lock A Looks like you should be able to pass Mutex and Mutex to both threads otherwise what's the point of mutex if there's no way to share data protected by it, so it doesn't look like it prevents you from hitting this sce…

I'm pretty sure "fearless concurrency" is just a meme at this point since Rust does very little to make concurrency "fearless".

There are two kinds of threading bugs: deadlocks which are easy to detect and race conditions which are far more difficult to detect and to fix. AFAIK Rust helps with the latter not with the former which is a very big improvement (much more than if it was the other way round)

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

#287

Post by 411111111111111 »

mikojan wrote: post #260
ThePhysicist wrote: post #250

Just got started with Rust and yeah, my biggest pain point so far were lifetimes and async code. I finally replaced tokio with multithreaded blocking code, which seems to be much simpler and more familiar. The problem with async was that some of the libraries I needed (e.g. for QUIC) didn't support it, so you had an unholy mixture of blocking and non-blocking code. Coming from a C++ background I appreciate Rust's nov…

I've successfully replaced tokio with the lower-level mio in one such case. After all threads and async serve different purposes: Threads when you're computing a lot, async when you're waiting a lot, no?

I'm just an average web developer, so I could be wrong here, but that's not my understanding of it.

Your application has n threads to begin with, if you use async, these will be utilized to schedule tasks. You're basically trusting your language to properly pause and restart the procedures.

If you spawn new threads, these will be managed by your kernel. If that kernel is Linux, that it already has a pretty good algorithm to pause and restart them, so you're not really wasting a lot of resources.

So I believe there are effectively two differences: threads can scale up to the limit of your os/kernel and hardware. Async can scale up to the level of the threads your language spawns to handle these tasks. Threads trust the kernel/OS to prioritize workloads, async trusts the language

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

#288

Post by adev_ »

adastra22 wrote: post #240
aphexairlines wrote: post #17

Earlier quoted context omitted.

I think that's ocaml. Higher level, with GC, nice type system, no traits but signatures and higher order modules might be enough for you, and a compiler that produces fast native binaries.

There are plenty of languages to choose from if you allow a GC. I think Rust's niche is systems-level programming where a garbage collector is an impossibility. I wish there was an easier to use language with Rust's features which occupied this niche. I find myself reaching for modern C++ instead of Rust when I want to be productive :(

> I find myself reaching for modern C++ instead of Rust when I want to be productive :(

You are not the only one, this is also my experience.

And if you think about it: This is fine. There is a reason why we are not using TLA+ or format proofs framework when we want to do quick prototyping: Safety has a cost like everything else.

It can be a run-time cost (in case of ARC or GC languages) or a mental effort / productivity cost but it is still a cost.

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

#289

Post by bruce343434 »

lelanthran wrote: post #285
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.

It's a language designed by people who's favourite language is not even pronounceable. Did you think that such a group of people, who place their love for the language above practical things like readability, would come up with a new language that cared about the user-experience[1]? As we see all the time WRT to programming languages, readability is more important than the more abstract stuff. > I hear all the argume…

> It's a language designed by people who's favourite language is not even pronounceable.

Elaborate?

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

#290

Post by conradludgate »

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.

Definitely not. I've been a full time rust developer for a long time now. Whenever I need to write some C# or Go or JS I honestly feel quite blind with a hand tied behind my back. I don't have the expressiveness of rusts type system and I don't have the safety of the strong compiler so I have to test my code a lot more thoroughly to be confident. With rust I'm pretty confident in my code from the start
Post reply on HN