Live data from Hacker News

Rust Is Hard, Or: The Misery of Mainstream Programming

hirrolot.github.io

351–360 of 811 posts

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

#351

I've only written php, Python and R to any large-ish extend and way back in the day i was introduced to programming using Delphi. I have absolutely no idea about what is going on in that article. Is Rust just completely different from everything else, or have I been completely shielded from "actual programming"?

1. garbage collection is amazing for developer productivity if you can afford it.

2. if you don't know if you can afford it, you can.

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

#352

Rust does not have to be this hard. Most of the pain here come from the unholy trifactor: combining async, lifetimes and dynamic dispatch with trait object closures; which is indeed very awkward in practice. Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. There are lots of ideas, some progress on the fundamental language features required…

The last paragraph is the key. Just use `Arc` or `Arc`, it will be fast enough. That's why my first article on a new blog is precisely about that: https://itsallaboutthebit.com/arc-mutex/

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

#353
post #86

Earlier quoted context omitted.

>"I don't understand why so many people lately seem to want to use Rust for web domain stuff." >"Rust is the new C++. Let's just stick with that." I write "web domain stuff" in C++ and it is incredibly easy (well for me at least). In C++ I could always use my own styles / paradigms / patterns etc. etc. Not forced to any particular way. And modern C++ is incredibly safe if one wishes. So if it is bad idea to write "we…

That's not my experience. I'm 3 times more productive at writing web apps in C# than in C++ and that is not even taking into account compile times and hot reload and doing unit tests. Maybe I'm the worst C++ programmer in history and maybe I didn't spent too much time in trying to write web apps in C++ - it was just to test if it's a viable approach - but that was my particular experience. Aside from doing more boile…

>"I didn't spent too much time in trying to write web apps in C++ - it was just to test if it's a viable approach - but that was my particular experience."

I rewrote web apps written in PHP and Python. Those were rather decent size and in my case app specific code was about the same size in C++ as in the other 2. The performance was of orders of magnitude better.

My applications do not contain millions line of code and maybe because of this and the way the code is organized I do not really suffer long compiling times. Usually it is just few seconds. Good enough for me.

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

#354

Earlier quoted context omitted.

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

There is no hard dependency on VS Code:

https://github.com/ionide/Ionide-vim

https://github.com/fsharp/emacs-fsharp-mode

https://www.jetbrains.com/help/rider/F_Sharp.html ...

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

#355

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.

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

This is not the case if you are designing a library. Much of what is routinely used to capture semantics into mainstream C++ libraries is wholly impossible to express in Rust. (C is not even a participant, here.) This is not about template metaprogramming, just ordinary stuff.

Most of that difference is in things that happen at compile time, so this is not a question of Turing completeness.

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

#356
post #311

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.

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 computer says its ready" style. Reliability and soundness comes with a cost.

Most software is not worth of the cost. When you adopt subscription model, fixing bugs is where the money is. If your app works flawlessly without updates, Apple removes it after few years.

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

#357

Earlier quoted context omitted.

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…

I personally don't like Rust (I like to have a garbage collector for what I do), but I don't think it's a hard to read language. Readability is an incredibly subjective thing. For example, APL might look like an absolute mess to most people but to the people who know it, it's incredibly easy to read. All "readability" means in this context is that it's familiar to you. In my opinion, the only truly hard to read langu…

> For example, APL might look like an absolute mess to most people but to the people who know it, it's incredibly easy to read.

But if we use that as a bar ("you have to know it"), then all languages are equally readable.

Pretty much all the popular languages converge on similar syntax an/or grammar.

You can say that it is because that particular set of syntax is the first, or you can say that languages that didn't have similar syntax was abandoned by developers.

There is an equal evidence/lack of evidence for either claim.

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

#358

Earlier quoted context omitted.

Step one is just clone() everywhere all the time. Then you should cut back AFTER analyzing where all of your memory is being lost to.

Can one really escape clone hell afterwards, though?

I generally go by the principle to borrow if I can without effort, otherwise I think a second of the code is in the critical path or the object is megabytes in size. If neither is the case, I clone without shame. The remaining 0.1% gets my attention (Arc, lifetime annotations, refactoring, or whatever is appropriate).

The important part is perspective. Nobody cares if you clone your command line arguments ten times during startup. As Dijkstra said, optimize the 2% of your program that matter, keep the rest simple

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

#359

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.

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

#360
post #83

Earlier quoted context omitted.

>"if the borrow checker is screaming at me when I hit a patch of code, I probably have a design flaw not a programming problem". This reminds me: "you are holding it wrong"

In industrial machines, there's such a thing as holding it wrong. In some cases, that means getting maimed (that old-school table saw doesn't care whether it chews on wood or flesh) or precluded through a clunkier mode of operation (you need to press these two buttons separated at roughly arm length to make sure that they can't be actioned while you have an arm in the way of the heavy arm-eating chunk of metal). The…

>"You're trying to draw a comparison with a consumer product with a design flaw."

Not at all. I just do not like to dance around bonfire with tam-tam and being told that this is the one and only way

Post reply on HN