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

461–470 of 811 posts

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

#461

Post by ModernMech »

avidphantasm wrote: post #434
roblabla wrote: post #333

Earlier quoted context omitted.

> 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. This is so interesting to me. I'm a Rust programmer by trade (as in - I'm not a hobbyist, I actually write Rust for work). We've found that, while the feature work is a bit slower in Rust than in other languages the company used to use (mostly Python), they tend to requ…

I’m still learning Rust, but the idea of having to use unsafe features to implement something as simple as a linked list seems “wrong” to me. What am I missing?

You’re missing that you don’t have to use unsafe, you use a wrapper type which is essentially a smart reference-counted pointer. Rust makes these things explicit.

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

#462

Post by eternityforest »

I really do not like the minimal stdlib idea, but as far as the language itself, I don't see the problem.

Have people never experienced "Lots of pain" debugging?

All those hoops modern languages make you do are just the same things you'd have to do yourself.

Instead of having to use some language construct to do whatever it is, you do it the simple and obvious way... but all reasoning to prove safety is on you.

Instead of "Learn these 50 features", which is hard but not impossible, you have to "Lol IDK git gud and don't do bugs", which is not only hard, but it's all on you to even figure out if you did it right.

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

#463

Post by styluss »

native_samples wrote: post #379
roblabla wrote: post #333

Earlier quoted context omitted.

> 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. This is so interesting to me. I'm a Rust programmer by trade (as in - I'm not a hobbyist, I actually write Rust for work). We've found that, while the feature work is a bit slower in Rust than in other languages the company used to use (mostly Python), they tend to requ…

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"

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

#464

Post by ModernMech »

the_duke wrote: post #388
pcthrowaway wrote: post #317

Earlier quoted context omitted.

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

Yeah, there were many times I was programming TS, and was very surprised at what the type system permitted. I started to realize type safety was best effort, or at times even performative, but by no means something TS can guarantee.

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

#465

Post by native_samples »

SquibblesRedux wrote: post #210
the_duke wrote: post #12

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…

I do wish async would go away and never come back -- in every language. Some days I long for the NMI: non-maskable interrupt. I have been coding since the late 70s -- the latter half of the last century. After all I have seen, async feels wrong.

The JVM guys are working on that with Loom, and, because of its multi-language nature, that can be brought across to many other languages too. Including, oddly, Rust, because Rust compiles with LLVM and GraalVM has a Truffle interpreter for Rust. I doubt anyone would actually want to run an app that way today especially as it's kind of cutting edge stuff and the Rust ecosystem is forcing async anyway, but in principle you could run a non-async Rust server on the JVM with millions of lightweight threads. It'd preserve the safety properties of the language and even the memory layouts, because Truffle doesn't force GC or Java-style memory layouts on the languages it runs. You can even AOT compile stuff but that requires the enterprise edition.

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

#466

Post by rowanG077 »

wheelerof4te wrote: post #318
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 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.

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

This sounds as insane to me as a carpenter who works with power tools saying. "Having safety measures which limits you and controls how you you have to do certain things does not sound appealing to those who need a house build, fast."

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

#467

Post by m25n »

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…

I have found that as I gain experience with rust, I spend less and less time “upfront to compile and fix all warnings”. I think rust requires a different design philosophy. It just takes time to adopt it into your mind.

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

#468

Post by School-Cotton »

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…

> Rust advocates are in the losing battle of of forcing mainstream

Dunno what you mean. I like Rust. I think it’s by far the best language in its niche, which contains exactly two languages: Rust and C++.

If what you’re doing doesn’t fit into that niche, that’s fine! Don’t use Rust.

Who is forcing anyone to do anything?

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

#469

Post by School-Cotton »

WastingMyTime89 wrote: post #381
Nokinside wrote: post #356

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…

Rust is supposed to be a better C++, and resoundingly succeeds at that goal.

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

#470

Post by jules »

lelanthran wrote: post #206
jen20 wrote: post #176

Earlier quoted context omitted.

Which parts of Rust would you give up to make this happen? And how would this be implemented?

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

Traits are the one part of Rust that should definitely not be given up. It is way better than the traditional OO model.
Post reply on HN