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

671–680 of 811 posts

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

#671

Post by markasoftware »

conradludgate wrote: post #290
HacklesRaised wrote: post #275

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.

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

What does Rust's compiler tell you that C#'s doesn't? You still have guaranteed memory safety in C#, and the type checker will verify against all type errors.

I realize that Rust's compiler might catch more concurrency problems, but your comment is written as if you feel "blind" even writing single threaded code.

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

#672

Post by withoutboats2 »

mwcampbell wrote: post #495
withoutboats2 wrote: post #413

Earlier quoted context omitted.

> Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. As the primary mover of the MVP (who stopped working on Rust shortly after it was launched), I'm really sad to see this. I certainly didn't imagine that 3 years later, none of the next steps past the MVP would have even made it into nightly. I don't want to speculate as to why this is. I a…

> As the primary mover of the MVP (who stopped working on Rust shortly after it was launched) At the risk of rehashing something that has already been discussed to death, did you stop working on Rust because of the difficulty of launching that MVP? I imagine that all of the arguments involved, particularly about things that are prone to bike-shedding like the await syntax, could be exhausting. Any idea where we shoul…

That's not why I stopped working on Rust. Given that Amazon, Google, Microsoft and others all employ people to work on Rust, lack of money is certainly not the problem. There has never been more money in Rust development.

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

#673

Post by drogus »

hirrolot wrote: post #507
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…

> without touching async The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code. Or he/she writes very-very straightforward, if not primitive async code and doesn't touch HOFs, traits, and similar stuff at all. However, when you write networking code, you typically use async. The worst role i…

I disagree. I write Rust, I write mainly async Rust and while my code is maybe not the most sophisticated I use a lot of async traits and generics. I still find it one of the best languages I know, definitely my favourite for all around coding at the moment.

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

#674

Post by foldr »

ngrilly wrote: post #650
foldr wrote: post #621

Earlier quoted context omitted.

I'm 100% sure that I understand what safe means in this context. All modern GCed languages are memory safe and will not access invalid memory regions unless you use specifically unsafe features. > 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 pu…

> I can assure you that you cannot access undefined memory regions by doing this in Go. Current implementation of slices and interfaces in Go is not memory safe in presence of data races: https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...

This is the kind of edge case you can find in lots of languages, including Rust (which has plenty of past and present soundness bugs).

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

#675

Post by efnx »

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…

You should try Haskell. It has everything Rust has (and much more) and it also has a garbage collector. I prefer it to ocaml.

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

#676

Post by efnx »

nicoburns wrote: post #19
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…

Swift is by far the closest from a language point of view, but alas the ecosystem is all-but-nonexistent outside of the Apple systems.

I would argue that swift is pretty distant compared to the ML family of languages - specifically Haskell. Besides garbage collection, the biggest difference between Haskell and Rust is that Haskell already has higher kinded types.

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

#677

Post by tialaramex »

pjmlp wrote: post #641
logicchains wrote: post #567

Earlier quoted context omitted.

Writing this kind of async code in Haskell (and to some extent OCaml) is much nicer, because you can abstract over the asyncness of code. This can't be done in Rust or C# because the type system isn't powerful enough (no higher-kinded types). To be fair, adding HKTs to Rust's existing type system is a challenging theoretical problem in itself.

C++ surely has HKT, that is what templates that take other templates as type parameters are for.

In a sense, but the "ill-formed, no diagnostic required" hack allows for scenarios where what you wrote is nonsense, and a human can explain why, but your C++ compiler doesn't have that insight, so it compiles anyway and does... something. This avoids needing to teach the machine how to determine if what you did was sound.

But this is of course not a very safe way to write software.

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

#678

Post by CraigJPerry »

skohan wrote: post #596
CraigJPerry wrote: post #585

Earlier quoted context omitted.

>> the main thing missing from Go is ADT's. After using these in Rust and Swift, a programming language doesn't really feel complete without them What are the differences between an ADT (plus pattern matching i’d reckon?) in Rust/Swift vs the equiv in Go (tagged interfaces + switch statement)? One has exhaustive matching at compile time, the other has a default clause (non exhaustive matching), although there’s an im…

I'm not a go expert, but imo the main difference is ergonomics and clarity. Rust/Swift style ADT's plus pattern matching gives you a very concise and readable way to declare and use sum-types, and the Go way seems to have more boilerplate. Also with Rust for instance you have more robust pattern matching. So you don't have to match only on type, you can match on complex criteria (i.e. foo is a Circle, with foo.radius…

>> I'm not a go expert

Yeah me neither, i’ve just been dabbling for fun recently. I’ve been dabbling with rust for longer

>> the Go way seems to have more boilerplate

    …
    switch t := s.(type) {
    case Circle:
      if t.radius
https://go.dev/play/p/s4TTZeo7Gse

Definitely less boilerplate in the rust version, but i don’t think i go along with it being incomplete or less clear.

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

#679

Post by pjmlp »

tialaramex wrote: post #677
pjmlp wrote: post #641

Earlier quoted context omitted.

C++ surely has HKT, that is what templates that take other templates as type parameters are for.

In a sense, but the "ill-formed, no diagnostic required" hack allows for scenarios where what you wrote is nonsense, and a human can explain why, but your C++ compiler doesn't have that insight, so it compiles anyway and does... something. This avoids needing to teach the machine how to determine if what you did was sound. But this is of course not a very safe way to write software.

If the author is fool enough to not use the language features that exist since C++17 to validate template code, surely.

I also don't find debugging Rust macros that fun, yet most likely the answer will be that the macro author didn't took enough care, and Rust is great to write gigantic DSL macros.

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

#680

Post by cozzyd »

kobebrookskC3 wrote: post #521
lelanthran wrote: post #244

Earlier quoted context omitted.

> Modern C++ isn't really safe. Can we cut it out with the hyperbole? Using "It Isn't Really Safe Unless It Is Written In My Favourite Niche Language" as an argument is .. well ... ridiculous. You can extend that argument to any practical programming language. So ... Rust ... "Isn't Really Safe" because you can get into a point where memory is corrupted, where your application deadlocks, or threads starve, etc. Haske…

> Rust ... "Isn't Really Safe" because you can get into a point where memory is corrupted i dare you to find memory corruption in safe rust that isn't already on an issue tracker. > Saying that a language is either safe or unsafe implies that the "safe" language is actually safe while the "unsafe" language is completely deadly. tell that to the people who got owned by https://googleprojectzero.blogspot.com/2021/12/a-…

> i dare you to find memory corruption in safe rust that isn't already on an issue tracker.

can't you just mess around with /proc/self/mem :)

Post reply on HN