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

751–760 of 811 posts

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

#751

Post by iex_xei »

wvh wrote: post #583
iex_xei wrote: post #498

Earlier quoted context omitted.

That's true for me as well, but I learned these after many failures. Now, I start by writing enums and structs for the problem, then iterate the design with functions and if it's really needed add these functions as impl of a certain struct/enum. This is the inverse of "Object-Oriented" design where one has to start from interfaces and manipulate data to satisfy the interfaces.

Sounds like Go. Just write code, then see if any obvious interfaces pop up and if you need them.

I wrote servers in Go as well, and I like the language. After Rust, I believe at some point, I enjoy to solve the "problems" Rust brings, not that it's rationally better than Go.

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

#752

Post by iex_xei »

michaelcampbell wrote: post #739
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…

> It doesn't allow you to build quick and easy solutions that allows you to lie to yourself (or your boss.) A quick and easy solution is still a solution, which is what most bosses want.

That's true, though in my experience those quick solutions lead to more quick solutions, and in total that leads to a mess in the long run. But if that long run will never come, it may be better not to bother. These are all sensible choices.

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

#753

Post by nbittich »

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…

The problem with rust is its community. A bunch of groupies acting worst than kpop stans on twitter. If you don't make abstraction and write spaghetti code, or if you clone everything, then yeah rust work-ish.

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

#754

Post by iex_xei »

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.

That's cool. I've worked in C++11 most recently (in 2012 with OpenCV) and used Boost's smart pointers to achieve memory security but I was probably overdoing those at that time and don't remember it as a good experience. (I remember I spent nights with valgrind but it may be my confusion at that time and don't remember the details.) I'll take a look at these as well to brush up my knowledge on modern features of "grand old language." Thank you.

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

#755

Post by iex_xei »

raxxorraxor wrote: post #500
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…

To be honest that doesn't seem too convincing for a new language. It actually reminds me of the early dogmatism of Java which today is often seen as too restrictive. Rust makes an argument about safety but only for a select few types of errors and the cost seem rather high.

It brought a discipline to my memory/variable management and functional problem solving, as Haskell brought a discipline in my typeful thinking some time ago. I don't claim it's "the best language for all use cases" but I'm glad I'm learning it.

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

#756

Post by mumblingdrunk »

wheelerof4te wrote: post #727
steveklabnik wrote: post #636

Earlier quoted context omitted.

You’re confusing standard library naming. Rust has a layered standard library, “core” and then “std” on top of it. They’re using the core library, because that’s what you do in an OS context. But as far as I know they don’t restrict any language features. They also didn’t have to write a new allocator; they did extend the interface of the “alloc” library (which sits between core and std) which was then also accepted…

So, what software can you make without relying on "std" library? I think that a lot of complexity in Rust comes from many different ways to handle memory. You have your Arcs, Boxes, Cells, etc. Then you have a core "alloc" library. Maybe if everyone agreed on a single reliable method to handle heap memory (since using stack is easy), Rust wouldn't be so hard to use. The syntax also could be improved. Seeing or whatev…

You don't have access to the C standard library in the Linux kernel either, so what is your point? Ime., the core library of Rust is much nicer to work with than the absolute bare bones landscape that is C when compiled with -nostd.

Boxes, cells, arcs, etc. exist for different purposes and if you'd take two hours to actually read about them and their uses, you'd understand why they exist.

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

#757

Post by mumblingdrunk »

foldr wrote: post #660
crabbygrabby wrote: post #651

Earlier quoted context omitted.

Unsafe in rust means you are skirting guarantees given by the language. It doesn't mean the code will blow up when run. It's just an explicit way to tell the compiler you are operating at your own risk. So when you do get UB from using unsafe you look at those places rather then your entire code base... A lot of people don't seem to realize how easy it is to get UB in other languages. The C spec for example claimed n…

>Unsafe in rust means you are skirting guarantees given by the language. It doesn't mean the code will blow up when run. It's just an explicit way to tell the compiler you are operating at your own risk. I'm fully aware of this. That's why I put 'unsafe' in quotes. However, it's surely fair to point out that you can't implement doubly linked lists or mutable iterators in Rust without giving up Rust's usual guarantee…

It seems you are slightly misunderstanding the point of 'unsafe' as a concept.

And no, memory safety is a huge deal, it is just that the borrow checker cannot verify the soundness of certain code, meaning you have to provide the guarantees normally given to you outside 'unsafe' blocks.

Yes, this means that a few data structures require 'unsafe', but you should be creating safe wrappers around these structures; 'unsafe' won't propagate up your code and poison everything.

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

#758

Post by klysm »

bebop wrote: post #618
klysm wrote: post #599

Earlier quoted context omitted.

There’s plenty of real world data. I forget the name of the website but web server benchmarks are pretty good at showing the differences.

Maybe this: https://www.techempower.com/benchmarks/

Yes those are the ones I was thinking of, thanks!

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

#759

Post by steveklabnik »

wheelerof4te wrote: post #727
steveklabnik wrote: post #636

Earlier quoted context omitted.

You’re confusing standard library naming. Rust has a layered standard library, “core” and then “std” on top of it. They’re using the core library, because that’s what you do in an OS context. But as far as I know they don’t restrict any language features. They also didn’t have to write a new allocator; they did extend the interface of the “alloc” library (which sits between core and std) which was then also accepted…

So, what software can you make without relying on "std" library? I think that a lot of complexity in Rust comes from many different ways to handle memory. You have your Arcs, Boxes, Cells, etc. Then you have a core "alloc" library. Maybe if everyone agreed on a single reliable method to handle heap memory (since using stack is easy), Rust wouldn't be so hard to use. The syntax also could be improved. Seeing or whatev…

You can write lots of stuff. The stuff you lose access too is mostly things that rely on the OS to function, so you lose file system stuff, networking stuff, things like that. Of course, people have written their own implementations of these things when it makes sense to do so.

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

#760

Post by mbrodersen »

crabbygrabby wrote: post #32
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…

Without diving into completely obscure programming languages, you can look at Scala, F#(doesn't scale super great ime), or I guess golang. That said, they all don't give you what rust gives you and have their own troubles. The truth is, either you care about life times and ownership, or you really don't care much about speed and correctness. Not saying that targeted at you as a person, but the royal "you". Even in c/…

What makes you think that F# doesn’t scale? Anything you can do in (say) C# you can do in F#?
Post reply on HN