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

701–710 of 811 posts

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

#701

Post by kazinator »

Shikadi wrote: post #613
foldr wrote: post #601

Earlier quoted context omitted.

There seems to be a myth that Rust is unusual in being memory safe. All modern GCed languages are memory safe (assuming you don't do anything obviously unsafe like manipulate raw pointers, which some languages might let you do if you really want to). >It is ironic to build super safe software, then deploying them on kubernetes, written in a GC'd language prone to nil dereference errors. Nil dereference errors don't d…

I'm not sure if you understand what safe means in this context. One common example is modifying a vector element by reference. If you grab a reference to an item, push something else to the vector, then try to access through that reference, the vector may have re allocated during the push and you're either no longer looking at valid memory because it's been freed, or you're looking at a stale copy of the element. I d…

The reference to the slot in a vector has to be a kind of object which tracks the vector itself, and an offset into the vector. It can't just be a wrapper for a naked address.

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

#702

Post by ncmncm »

bpye wrote: post #611
ncmncm wrote: post #304

Earlier quoted context omitted.

This is very commonly done in C++. My programs do a flurry of mmap s in the first second, then run for, sometimes, years without allocating again.

I was thinking about C and C++ and whilst they allow you to be very careful about allocations, they also give you every opportunity to get it wrong.

We need not act on the opportunity.

All that is actually needed is for it to be more work to get it wrong than to get it right.

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

#703

Post by Wodann »

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…

Have you heard of https://mun-lang.org/ ?

It's an embeddable scripting language with the goal of being a Rust-like language that supports hot reloading of functions AND data. To achieve the latter, it uses GC'ed memory such that memory can easily be mapped when the memory's type changes.

It's still in early development but maybe one day will serve your needs :)

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

#704

Post by ncmncm »

lelanthran wrote: post #586
bluGill wrote: post #536

Earlier quoted context omitted.

All above languages are turning complete, so if you can express it in one you can express it in another. The question isn't can you write it, the question is how hard is it to do, and how performant the code will be. The heart of C++ is destructors: a bit of code that you can write and the compiler will ensure runs when code goes out of scope/is deleted. You can do this in C by remembering to manually call the right…

Thanks, that is a very detailed answer[1]. I'm somewhat confused about why it was downvoted - there is nothing there controversial at all. [1] In my own toy language, I'm kinda leaning towards objects with destructors. Definitely without the footguns in C++, but destructors nonetheless.

Possibly because it does not mention almost all of the C++ features that Rust still lacks.

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

#705

Post by throwaway17_17 »

rfiat wrote: post #693
throwaway17_17 wrote: post #606

Earlier quoted context omitted.

I don't agree with your framing. You are stating a 'moral' proposition, i.e. Rust == Good Ideas AND Go == Bad Ideas, and then applying the 'moral' position to the language as a whole. So you end up saying, in brief (and acknowledging that I do not think you are actually making a moral claim about the qualities of these languages) you are saying Rust is Good, Go is Bad and therefore they are dissimilar. I don't think…

I appreciate your comment. My intention wasn't "Go is dissimilar because it's bad and Rust is good" but I can see why you'd think that. I'll attempt to clarify. The reason I like and recommend Rust is the number of decisions it gets right which are completely orthogonal to the borrow checker. It's clear that a lot of thought was put into the unexciting parts of the language. That's why I like using it even though I d…

You’re comment make your point very well. Honestly, so did the first comment. Sometimes I find myself so tired of just lurking and reading HN that I just text dump some comment onto a totally valid parent comment.

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

#706

Post by bergenty »

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…

>unlearning scope

As a programmer that hasn’t worked with Rust, what does that mean.

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

#707

Post by jstimpfle »

ncmncm wrote: post #686
jstimpfle wrote: post #632

Earlier quoted context omitted.

You can also see it this way: The philosophy behind C++ is that the existance of a pointer implies ownership. In C, the existance of a pointer only implies liveness (normally; but really the code can decide on its own whether its safe to dereference the pointer). With the C++ approach I've found myself overthinking the problem many times. But with the insight that pointers are just data, and memory management can be…

You are confused. There is no sense, in C++, in which a naked pointer implies or suggests ownership. It is the opposite: the continued validity of a pointer value depends on ownership maintained elsewhere . Nowadays libraries keep track of ownership. Most commonly the library delegates that responsibility to Standard std::unique_ptr, for familiarity. Not doing that indicates something different in play. (It is, in fa…

> You are confused.

I give you one advice: Think twice before writing this way again. You are not putting enough effort into understanding what I'm trying to say, and coming across as an arrogant prick.

https://news.ycombinator.com/item?id=31494099

Admittedly, I didn't make my point sufficiently clear, but this isn't even about being right or wrong. (And, once more, I understand what you say. Stop belittling me.)

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

#708

Post by jstimpfle »

bluGill wrote: post #668
jstimpfle wrote: post #632

Earlier quoted context omitted.

You can also see it this way: The philosophy behind C++ is that the existance of a pointer implies ownership. In C, the existance of a pointer only implies liveness (normally; but really the code can decide on its own whether its safe to dereference the pointer). With the C++ approach I've found myself overthinking the problem many times. But with the insight that pointers are just data, and memory management can be…

You must be stuck in C++98 land. In C++11 a pointer always means live (though you may not have rights to store that pointer for later). We use smart pointers to force ownership.

I know. I'm not stuck in C++98 land. I'm talking about how problems are approached in C++ and more generally, OOP land. In large parts of the community, there seems to be this idea that (almost) each little pointer (naked or not isn't my point here) should also be a handle to control the lifetime of the object that it points at.

I'm not saying that it has to be this way, but there is a reason why something like unique_ptr (that can be quite tedious to use in my experience) has become so popular in many projects - IMO it is overused, often leading to more typing work instead of less.

If one is sufficiently used to this way of modelling, it can come as a surprise that memory management needn't be so hard, and doesn't require smart pointers or anything, if the program design (global flow of data etc.) is sufficiently clear.

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

#709

Post by llllllllllll9 »

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 not missing anything.
Post reply on HN