Live data from Hacker News

Rust Is Hard, Or: The Misery of Mainstream Programming

hirrolot.github.io

471–480 of 811 posts

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

#471
I think a big factor that makes rust hard is the prevalence of special syntax everywhere. These are special character sequences that could have been expressed another (more verbose) way, that were introduced for dev convenience. It makes the code extremely hard to read for me.

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

#472
post #282

Earlier quoted context omitted.

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.

I would say that threads work _very well_ for concurrency in _most_ apps. Thread context switches have gotten much much cheaper over the years, and the idea that threads are heavyweight is very outdated.

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

#473
post #451

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,…

> Most of us are writing web apps

Indeed. I'm a Rust dev somewhere it actually matters (video dev - we have to process 60 frames a second, for hours/days on end, with completely predictable performance, without crashing once) and I'd never pick it if I just wanted to build a webapp where nothing really matters and if the whole thing falls over we can just put it in a retry loop.

There's plenty of code out there that /cannot/ be written in Ruby/Python/Go/C#. Rust solves some really hard problems for people working on that type of code. But it's not what most people on HN are working on.

I think the problem is that a lot of web developers do not really understand that this type of code exists, and that languages which do not target web development can be exciting.

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

#474
post #209

Earlier quoted context omitted.

Hide memory management under a language runtime. Make a single Fn trait/string type instead of multiple ones. Add effect polymorphism to deal with function colours. Remove async/.await and express it using algebraic effects, do the same for streams and iterators. How it'd be designed and implemented is probably a theme for a separate blog post, not a HN comment.

So basically OCaml.

OCaml is great, but it lacks traits / type classes. That plus some syntactic tweaks would make OCaml amazing for most general purpose programming.

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

#475
post #451

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,…

This feels a bit like complaining that a tank is badly designed because nobody drives them on the highway...

My understanding is that Rust was designed to be a safe(er) language to write low-level system code than C/C++, not to compete with Python/Ruby/Java for web development applications.

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

#476
post #397
post #384

Earlier quoted context omitted.

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.

How is it different than in case of every other language? Also, why not another newer language tops the list?

Clojure is the second most loved in 2021, and it isn't like every company is rushing out to adopt it.

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

#477

Earlier quoted context omitted.

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 cou…

>> What’s the story with Rust and verification nowadays?

It is in progress but likely several years to go before a MVP is released. Ferrocene [1] is the primary effort that I am aware of and that seems to be making progress towards a verified rustc suitable for safety critical work.

Ferrous Systems is working with AdaCore and just released the Ferrocene Language Specification [2] to formally document the Rust subset that Ferrocene will use.

[1] https://ferrous-systems.com/ferrocene/

[2] https://ferrous-systems.com/blog/ferrocene-language-specific...

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

#478
post #330

Compare the Rust Handler-Dispatcher program with the Go Handler-Dispatcher program and look at the truly extraordinary complexity that Rust adds to what is effectively a simple design problem that any of us have implemented several times, if your career has had a few years of original coding. Handler-Dispatcher is not some complicated design pattern. It is very basic. Its implementation in any language should be shor…

I don’t think it’s true that any given “basic” design pattern should should necessarily be simple in every language. Certain things are short and elegant in Rust. Certain things are short and elegant in Python. Each optimises for different things. I also don’t believe it places “extraordinary complexity” on the shoulders of the programmer; this complexity is often a sign you’re doing something wrong, or working again…

Ok, what is wrong about the Rust solution given by the author of this article ? What is he doing wrong ?

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

#479
post #475
post #451

Earlier quoted context omitted.

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,…

This feels a bit like complaining that a tank is badly designed because nobody drives them on the highway... My understanding is that Rust was designed to be a safe(er) language to write low-level system code than C/C++, not to compete with Python/Ruby/Java for web development applications.

True, yet what you see around HN and other places are people trying to use it for web development.
Post reply on HN