Rust Is Hard, Or: The Misery of Mainstream Programming • Hacker News Board

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

#511

Post by bluGill » Fri, Jun 03, 2022, 1:22 PM UTC

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

You might be right for the majority, but there are many other large groups who don't have computers that are more than fast enough. There are a lot of interesting and complex problems that can be solved in something like rust that the languages you name cannot be used for. Right now I'm using C++, but rust is of real interest to me (as is ADA, which in some variants lets me prove my code correct)

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

#512

Post by hailwren » Fri, Jun 03, 2022, 1:23 PM UTC

jstx1 wrote: post #384

Omin wrote: post #365

Earlier quoted context omitted.

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.

In order for this line of thinking to explain the statistics, either (1) Rust would have had no users over the time period or (2) more than the loved percentage of new users like the language (mean goes up).

It's pretty trivial to see that Rust adoption is increasing, so you can discount (1).

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

#513

Post by ipodopt » Fri, Jun 03, 2022, 1:25 PM UTC

jen20 wrote: post #178

ipodopt wrote: post #39

Earlier quoted context omitted.

It has been a sec but if I were to do another multi-threaded async Rust project I would do one thread per async runtime and explicitly pass anything that needed to be shared. This should be more ergonomic as this should get rid of everything needing to have send/sync traits. I also suspect it may be more performant as I am not sure how good the async runtimes are about keeping scopes pinned to a particular core so it…

Look at Glommio, it’s essentially what you describe.

Thanks for the link, very helpful :)

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

#514

Post by garethrowlands » Fri, Jun 03, 2022, 1:27 PM UTC

blub wrote: post #396

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

How you feel relates to you and your preferences and doesn't really say anything about Rust versus let's say Go. Is your software more performant and does this translate to additional customers or reduced costs? Is your software more stable and does this result in reduced support costs or happier customers? Testing effort is likewise not a decisive matter. In fact it's quite likely that what one wins time-wise on the…

Rust and Go are surely different classes of programming language. Rust is a systems language and Go is garbage collected. That is, Go is in the camp with Ruby, Python and Javascript, whereas Rust is in the camp with C and C++. Garbage collected languages are easier to use than non-garbage collected languages, so if you can use them, you should.

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

#515

Post by Georgelemental » Fri, Jun 03, 2022, 1:29 PM UTC

crabbygrabby wrote: post #502

wheelerof4te wrote: post #318

Earlier quoted context omitted.

This comment right here. For most people who program for a living, the hype over Rust means little. They need to use what is in the industry right now. Often, that is a tried and true language that is relatively easy to learn and use. Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast.

Rust only limits you from writing nonsense code. Seriously that's what the compiler is doing, and that's what people are complaining about. "Why won't this language let me write bad code!". I get it it's hard to learn at first, but, it sounds a little silly to people who have spent the time learning the language... Believe it or not industry has and is continuing to adopt rust. Microsoft, AWS, government agencys in E…

> Rust only limits you from writing nonsense code

This is the ideal, but not always the reality. The Rust borrow checker isn't perfect, so sometimes it rejects code that should work perfectly fine. Hopefully as the language matures (Polonius, GATs, HRTBs…) these cases will become rarer.

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

#516

Post by hawski » Fri, Jun 03, 2022, 1:30 PM UTC

drogus wrote: post #344

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…

Just use `Arc`, it's fine, it will be plenty fast.

I always wonder about code bases using bolt-on reference counting. I would count C++ shared_ptr and Rust's Arc among them. At this point wouldn't it be better to just use a regular GC language? What I don't like in modern C++ is that almost everything seems to be heap allocated, when it certainly doesn't need to be. In case of GC language you at least get fast allocations and heap compaction. But it is true that resource release is more predictable with RC. On the other hand you get those cascades of releases in RC.

As always it is a game of trade offs, but it is something that bothers me.

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

#517

Post by notriddle » Fri, Jun 03, 2022, 1:31 PM UTC

anonymoushn wrote: post #417

TazeTSchnitzel wrote: post #339

Earlier quoted context omitted.

> complex language which limits you Rust really does not limit you. Anything possible in C or C++ can be done in Rust if you're willing to use unsafe code.

I'm not sure this is true. The aliasing model of unsafe Rust seems much more difficult to write correct code for than these other aliasing models.

Use UnsafeCell if that’s your problem.

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

#518

Post by spoiler » Fri, Jun 03, 2022, 1:33 PM UTC

synergy20 wrote: post #501

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…

using c++17/c++20 with g++'s sanitizers(e.g. undefined behavior) and static analyzers, along with clangd the LSP, they too caught most if not all coding errors at editing time and compiling time. In recent two years once my c++ program compiles warning free, it seems bug-free at the same time.

In my experience this is untrue... I've worked with C++ on and off (albeit, sometimes reluctantly, so maybe I'm projecting some misery) and a lot of errors in C++ can not be caught until it starts pasting the templates. Sometimes it also fails when linking. Sure, you can always go through the whole build/compile process, but for serious C++ projects that's impractical (even with stuff like (s)ccache) because of how long it takes. And I'm a code quality tooling/intellisense freak to the point it can be annoying for others, and I've never seen a truckload of tooling come even close to simply running "cargo check"

I've only experienced waiting ~10 minutes at most (on decent dev machine) and it frustrated me to no end, but even more serious projects sometimes take hours. Maybe concepts help with this?

And the "jUsT dOnT uSe HaLf tHe LaNgUaGe" argument holds as much as a leaky bucket, because it's hard to agree on what the good parts are in a large team, unless its strictly enforced and audited somehow

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

#519

Post by crabbygrabby » Fri, Jun 03, 2022, 1:34 PM UTC

styluss wrote: post #463

native_samples wrote: post #379

Earlier quoted context omitted.

This feels like a common pattern. Languages like Rust and Go seem to pick up a lot of users from the world of dynamic languages, who then incorrectly associate the productivity gains of static typing with the specific language they picked. A lot of programs written in Rust would almost certainly be better off being written in Kotlin. The one in the article is a good example. Why are they writing a messenger bot in Ru…

> Why are they writing a messenger bot in Rust? AFAICT Rust is a general purpose programming language. People can use it how they want. How do you learn a recent programming language? "hey boss I'm going to write production code in a new language that I haven't learned. Lol YOLO"

The funny thing about this is, using rust for production is way safer than an old language like C or even C++. So the YOLO part isn't crazy here. If you don't use unsafe you cannot, read can not, get data races, among a host of other common bugs.

Now if we were talking about some other "new languages" not naming names, you can memory leak kilobytes writing hello world... Yikes.

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

#520

Post by eternalban » Fri, Jun 03, 2022, 1:34 PM UTC

crabbygrabby wrote: post #497

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…

Its so hard for me to think someone actually thinks this. Rust really is a great programming language that solves a lot of other problems other languages don't. It does so by introducing a pretty clever paradigm. The rust community is the least toxic programming community I've ever seen. Leaps and bounds away from go lang, python, and light years away from c, etc. Like use your head, is vba therefore the language whi…

> Rust really is a great programming language that solves a lot of other problems other languages don't. It does so by introducing a pretty clever paradigm.

Were you around when Scala was the end all be all of programming shiny things?

"Early on, Scala rode a wave of hype that frankly surprised even me: hype around pushing syntactic boundaries, hype around reactive architectures, hype around functional programming, hype around the Apache Spark project. Much of that hype has since died down, and there was a period of backlash and negativity both within the Scala community and outside of it. Since then, even the backlash has faded, and what is left is a reasonable, boring language steadily advancing and providing a great platform for general software engineering."

source: https://www.lihaoyi.com/post/TheDeathofHypeWhatsNextforScala...

Not every concern needs to be solved at source level. My brief crit of both Scala and Rust is that they do not take a modular approach and instead have opted for a 'comprehensive' approach that necessarily entails (arguably) unreasonable levels of complexity at syntactic and semantic layers of source code.