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

381–390 of 811 posts

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

#381

Post by WastingMyTime89 »

Nokinside wrote: post #356
jstx1 wrote: post #311

Earlier quoted context omitted.

No, it's a selection effect. The stackoverflow most loved metric is people_who_want_to_keep_using_the_language / people_who_have_used_it_in_the_past_year Since Rust is so early in its adoption and there are few jobs, many of the responders are hobbyists who are into Rust, like it and want to keep using; not necessarily people who use it for work. And since you only take into account the people who have used it in the…

IMHO it would be good for Rust to become popular niche/specialist language for systems programming. Currently Rust is not as complete or well defined as Ada/SPARK or MISRA C/C++ combined with commercial analyzers (Astree for example). At the same time Rust is "too sound and rigorous" for mainstream programmers. Rust advocates are in the losing battle of of forcing mainstream to adopt "it does not compile unless compu…

I for one as someone who programmed professionally in both Ocaml and Ada still don’t see where Rust is supposed to fit.

If I was doing something high level, I would probably use Ocaml which has nicer features. If I wanted to write safe code, Ada offers a better experience with the availability of SPARK for parts I would probably end up wanting to prove. If I just want to write concurrent code with the certainty I could find someone to maintain it, Go seems the way to go.

Rust seems to want to be a replacement for Ada but seems to actually attract programmers used to high level language chasing the hype.

What’s the story with Rust and verification nowadays?

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

#382

Post by dgb23 »

HacklesRaised wrote: post #294
timClicks wrote: post #278

Earlier quoted context omitted.

No, it really is wonderful once you make it. Which resources have you used to learn?

I did ok with Rustlings and I read the 'The Book', I'd say I am largely struggling with async and lifetimes. I have spent most of my career in C, C++, Objective-C and have recently tried Zig, which I enjoyed, possibly because of it's brevity, and I read through the Jakt programming language docs, which was much more familiar to me but I think if you only used Rust with ARC it would be a simple language to adopt so th…

There are some very practice oriented books for rust: zero to production, rust in action. And a third one that I didn’t read, it is game programming focused and seems pretty good. Something with “handmade”.

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

#383

Post by therockhead »

dgb23 wrote: post #375
drogus wrote: post #349

Earlier quoted context omitted.

No it's not. There are tradeoffs, definitely, and one of them is visible in the article: at the moment doing lifetimes and async is hard. But you don't have to do it, most of the time you use `Arc` or `Arc ` and call it a day. In async web frameworks you very rarely need explicit lifetimes, because the workload is mostly isolated - a handler gets an input from the request, you compute the output, you return it. Any s…

If you default to Arc everywhere, aren’t you essentially just implementing a slow GC? This type of thing comes up of often when people try the language. They re-implement some part of a program, originally written in a fast GC language, and then wonder why it’s slower. I feel like the power of the language comes through in specific workloads, or when you take the additional time to avoid naive code. That’s why it is…

> If you default to Arc everywhere, aren’t you essentially just implementing a slow GC?

Like I posted earlier, you don't do this everywhere, just some sporadic use where it makes life a lot easier. It doesn't have to be all or nothing.

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

#384

Post by jstx1 »

Omin wrote: post #365
jstx1 wrote: post #311

Earlier quoted context omitted.

No, it's a selection effect. The stackoverflow most loved metric is people_who_want_to_keep_using_the_language / people_who_have_used_it_in_the_past_year Since Rust is so early in its adoption and there are few jobs, many of the responders are hobbyists who are into Rust, like it and want to keep using; not necessarily people who use it for work. And since you only take into account the people who have used it in the…

This selection effect cannot explain Rust's standing relative to other new languages and neither can it explain why Rust's popularity (as measured by "most loved") increases over time as more and more companies are using it. Here's the history of Rust's "most loved" percentage going back to 2015 Year - Most Loved Pct. - Rank 2015 - 73.8% - 3 2016 - 79.1% - 1 2017 - 73.1% - 1 2018 - 78.9% - 1 2019 - 83.5% - 1 2020 - 8…

I think that's consistent with my line of thinking - if in 2015 some people tried it and decided that it's not for them, they drop off from the sample and % loved goes up in following years.

Not claiming that this explains the entire increase in the percentage (I have no way of knowing) but I don't think this data contradicts my reasoning either.

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

#385

Post by purkka »

pas wrote: post #334
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 young, very ambitious, of course general purpose enough to do everything in it, but its ecosystem has serious gaps. (And some of those are dependent on planned language level features.) ... I spent a lot of time reading r/rust, various blog posts before going beyond helloworld in it. To me it's in the same category as Scala (ZIO) or TypeScript. Both are very powerful, a joy to work with them, until the low-le…

Totally agree. Scala and TypeScript are both usually wonderful to write.

Though I might argue that one of Scala's biggest issues in my eyes, performance, is mostly _not_ a JVM limitation.

For example, a Scala for-loop calls functions on each iteration, and immutable containers need to be garbage collected for each modification. Both of these could be compiled away in many common cases (like C++ or Rust do, but Scala's compiler doesn't, unless they've changed that in the last couple of years).

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

#386

Post by whazor »

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 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 to be doing this in Rust, whereas I would not want to try this in C++. The code I am writing is much simpler than the existing C++ code.

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

#387

Post by lelanthran »

pjmlp wrote: post #305
lelanthran wrote: post #206

Earlier quoted context omitted.

> Which parts of Rust would you give up to make this happen? And how would this be implemented? Traits, maybe? Switch to an OO model more closely aligned to what the majority of developers understand. Dump all of the line-noise-type syntax. My Own Toy Language (ComingRealSoonNow)^tm that I started designing had exactly one goal - prevent the majority of memory errors, not prevent ALL memory errors. All I wanted was t…

Actually something like traits (as concept) is what powers COM, WinRT, the basis of Objective-C protocols that influenced interfaces in more common OOP languages. Also the basis for one programming language that used to be widespread in the enterprise for quick and dirty solutions, VB and its ecosystem of OCX libraries. It is more widespread that people think, because when many argue about OOP, they miss the full spe…

> Actually something like traits (as concept) is what powers COM, WinRT, the basis of Objective-C protocols that influenced interfaces in more common OOP languages.

So? Giving up Rust-Traits doesn't mean that I will give up on interfaces as a whole.

I don't like the way C++ does interfaces, for example, but that doesn't mean that my ideal language won't have interfaces.

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

#388

Post by the_duke »

pcthrowaway wrote: post #317
conradludgate wrote: post #290

Earlier quoted context omitted.

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

> 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 How would you compare it to Typescript? Having become a recent convert, I feel the same way going back to Javascript now

Typescript is great, but it is ultimately a gradually typed language that is built around compiling to Javascript, and that has extensive interaction with untyped Javascript code.

You often end up with obscure issues that a good type system should prevent. Maybe because the third party typings for a package are faulty or incomplete, maybe because the compiler just gave up on a complex expression and fell back to any, or because the developer just gave up and used `as any`.

Typescript is also really constrained by keeping JS compatibility. A prime example is the lack of real sumtypes. Instead you have to use objects with a string tag and do if/switch on that tag to disambiguate the concrete type, which is incredibly awkward when compared to proper compiler sum type support.

I'd much rather use Typescript than Javascript, but it's far from perfect.

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

#389

Post by shultays »

valenterry wrote: post #345
yeputons wrote: post #15

Earlier quoted context omitted.

> I care about speed and correctness but Rust makes me also care about ownership and lifetimes even when I don't really want to care about that stuff. I don't think one can care about speed and correctness without caring about lifetimes and ownership. Even if you do not care about memory ownership and use garbage collection, there are plethora of other things that you take care of. For example, if you've juts sent an…

I think after the (correct) first sentence you are a bit mistaken here. The example you describe can be solved correctly and also with good performance in garbage collected languages such as Haskell or Scala. I would even say that those languages make a correct solution easier than in Rust, but they trade in a bit of performance for it (e.g. by using immutable datastructures instead of an ownership model). But for as…

"good performance" is a relative term. You may consider Haskell or Scala having "good performance" but for others having garbage collection itself is a big no. So you are either left with Rust's approach where you limit the programmer, or C++'s approach where you leave memory management mostly to the programmer

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

#390

Post by p0nce »

kitd wrote: post #337
adeon wrote: post #10

I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, the nice type system, traits, the idea that my code generally runs pretty fast even if I'm being lazy about writing good code, and my code usually working correctly if it compiles. I care about speed and correctness but Rust makes me also care about ownership an…

D lang is incorporating a borrow-checking system. I'm not certain how far along they are with it. Walter Bright posts here often and will know. D has a wide range of GC and non-GC techniques that may meet your needs.

And no D programmer says "it was really hard but worth it in the end". It's worth it right from the start.
Post reply on HN