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

691–700 of 811 posts

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

#691

Post by Amasuriel »

aphexairlines wrote: post #17
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…

I think that's ocaml. Higher level, with GC, nice type system, no traits but signatures and higher order modules might be enough for you, and a compiler that produces fast native binaries.

Or F# if you want a wider ecosystem, it’s based on Ocaml and has many nice functional features, but you can utilize any .net code you want

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

#692

Post by sundarurfriend »

pjmlp wrote: post #371
jandrewrogers wrote: post #197

Earlier quoted context omitted.

C++ templates are an inscrutable nightmare, the reputation is deserved. Rust is a bit different. Any software engineer that doesn't have a love/hate relationship with C++ templates is lying. On one hand they are extremely opaque and not user friendly, unnecessarily so. On the other hand, mastery of that dark art allows metaprogramming that you could only dream of in other systems languages -- the modern C++ template…

True until C++17. With C++17, if constexpr, static_assert and type traits provide some tools to make life better, C++20 concepts improve on that front. Rust macros curently are harder to debug than what for example Visual C++ offers for template debugging. We are back to primitive expand macro, like in the early Lisp days.

Is there a tutorial-style (or anything beginner-focused) resource for learning modern C++ that you could recommend? A lot of the learning material is about earlier versions (for understandable reasons), or at least don't seem to reflect C++ as it is today, and the best practices of writing code with the tools it provides.

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

#693

Post by rfiat »

throwaway17_17 wrote: post #606
rfiat wrote: post #494

Earlier quoted context omitted.

As the sibling commentor said, syntax highlighting is only one example meant to illustrate Go's sometimes unnecessarily frustrating design. In case it wasn't clear, the example wasn't that Rob Pike doesn't like syntax highlighting. The example was that Go's playground doesn't have syntax highlighting (even as an option) for a reason as arbitrary as "because I said so". That is why I find Rust and Go to be dissimilar.…

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 don't particularly need the borrow checker and I'd be happy with GC. Some examples off the top of my head:

  - Expression-oriented nature makes code easy to write and nice to read
  - Compilation errors are as clear and helpful as possible
  - Comprehensive yet skimmable API documentation
In short, Rust is a nice language outside of the borrow checker.

A lot of the things which strike me as nice about Rust can't be said about Go. For that reason I think Go is a surprising suggestion for someone who likes Rust but doesn't care about ownership and lifetimes.

There are a number of minor but valid frustrations I encounter when writing Go which are completely orthogonal to the brief of "C but with GC and easy concurrency". I'd understand if these problems were a result of the language's goals but often they seem to exist for no particular reason. In that regard I think Go is quite dissimilar to Rust.

I hope that explains my viewpoint more clearly :)

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

#694

Post by bilkow »

markasoftware wrote: post #671
conradludgate wrote: post #290

Earlier quoted context omitted.

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.

Rust's advantages don't stop at concurrency or type safety. In my experience, the type system is actually much more concise and the APIs are a lot more explicit than any other language I've tried. It's clear when the argument you're passing is going to be mutated or not and move semantics help a lot on designing good APIs (not having to remember to close a File or being able to use it after it's closed, for example). Not to mention sum types with pattern matching, being expression based, etc. I also find that Structs and Enums being values instead of references (as opposed to Classes in other languages), reasoning about the code is a lot more straightforward, which goes back to my point about explicit mutability. A huge part of it also goes to great libraries created by the community, that usually cares about API soundness.

It's very common in Rust to do a big refactor or write a program from scratch and have it work on the first or second try, which may release a good amount of dopamine for some.[0]

Not saying the language is perfect, but it can feel pretty good, to the point of being addictive, while also freeing to know you can think less about the variants and let the compiler do it for you, and the reliability of the created program is usually pretty amazing. It can also be annoying, specially when you're learning it and try doing something in a way that's just not viable in an easy way (e.g. manually creating a Linked List).

[0] https://old.reddit.com/r/rust/comments/uixup6/just_wanted_to...

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

#695

Post by dgunay »

ngrilly wrote: post #655
dgunay wrote: post #373

Earlier quoted context omitted.

It is mostly an example of the mindset that I think GP is trying to illustrate. Go has nil where Rust has Option. Go has weird not-quite-tuple returns & if err != nil where Rust has Result. Go has no real enum concept, where rust has its powerful enums and matching constructs. Go has generics, but only after a decade of pressure from users (and even then, they are much much less useful than Rust's type system). I lik…

3 issues you listed with Go are actually about the same thing (the lack of sum types): - Go has nil where Rust has Option. - Go has weird not-quite-tuple returns & if err != nil where Rust has Result. - Go has no real enum concept, where rust has its powerful enums and matching constructs. And the point on generics coming late is unfair. All programming languages got major features introduced late (for example async/…

Yeah I don't mean to criticize Go's generics for being less featureful given how late they were introduced, but they do currently prevent me from building any kind of mapping/filtering/pipeline style code because of their limitations (no generic type parameters on methods). A Go implementation of Result or Option could paper over the lack of sum types if we only had that.

The more I think about it, what I really want is something with the ML feeling of Rust, but in the space that Go occupies (good performance GC languages). Go frustrates me because it nails the runtime and tooling side of things but falls far short of it in the other ways I mentioned.

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

#696

Post by dgunay »

christophilus wrote: post #457
dgunay wrote: post #373

Earlier quoted context omitted.

It is mostly an example of the mindset that I think GP is trying to illustrate. Go has nil where Rust has Option. Go has weird not-quite-tuple returns & if err != nil where Rust has Result. Go has no real enum concept, where rust has its powerful enums and matching constructs. Go has generics, but only after a decade of pressure from users (and even then, they are much much less useful than Rust's type system). I lik…

I would love a language that combined the best aspects of Go and F#: expressive, great type system, fast compilation, native binaries, opinionated formatter, excellent concurrency, comprehensive standard library, consistent documentation, etc. Throw in great compile to JS capabilities with small bundle sizes and the ability to map Typescript typings into the language so you can seamlessly consume well typed libraries…

Me too! Go's tooling and runtime are great, I just want a more useful type system.

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

#697

Post by dgunay »

justinsaccount wrote: post #640
dgunay wrote: post #373

Earlier quoted context omitted.

It is mostly an example of the mindset that I think GP is trying to illustrate. Go has nil where Rust has Option. Go has weird not-quite-tuple returns & if err != nil where Rust has Result. Go has no real enum concept, where rust has its powerful enums and matching constructs. Go has generics, but only after a decade of pressure from users (and even then, they are much much less useful than Rust's type system). I lik…

As someone that writes a bunch of go but has never really gotten off the ground with rust: * Option? I don't mind if err != nil, but sure, it would simplify some things. * Result and real tuples? awesome. * real enums? sign me up. If that was all added to go I wouldn't mind at all. But what does any of that have to do with impl Execute for Dispatcher where H: Fn(&'a Update) -> Fut + Send + Sync + 'a, Fut: Future + Se…

It doesn't, primarily the way I saw the discussion heading was (warning: strawmen ahead):

> "Go is a good alternative to Rust because it is easy to write performant, concurrent code"

> "Go is not very comparable to Rust. I won't describe why, here's a quote by Rob Pike and I'll strongly imply it's because its creators deliberately avoided complexity, even where useful."

> "You did not explicitly criticize anything about Go, therefore it must not have flaws"

Then I came in and described exactly where I feel Go ignores the state of the art in PLs.

> But what does any of that have to do with (Rust-shaped vomit)

Go doesn't need all those type system gymnastics because it does not have the problem of the borrow checker to deal with and doesn't promise to avoid segfaults for you.

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

#698

Post by dgunay »

curun1r wrote: post #620
dgunay wrote: post #373

Earlier quoted context omitted.

It is mostly an example of the mindset that I think GP is trying to illustrate. Go has nil where Rust has Option. Go has weird not-quite-tuple returns & if err != nil where Rust has Result. Go has no real enum concept, where rust has its powerful enums and matching constructs. Go has generics, but only after a decade of pressure from users (and even then, they are much much less useful than Rust's type system). I lik…

I feel like Go was built with primary design considerations that are often not considered publicly and often at odds with what programmers want out of a language. I saw one of the first public talks from the creators at Google I/O and they stressed two things: compilation speed and new developers coming up to speed quickly. From what they said, Google had a few C++ projects with multi-hour compilation times that, whe…

I agree, I've mostly made peace with what Go is and I still enjoy using it.

It just tantalizes me because of how close it is to my ideal general-purpose programming language. There is a large middle ground between the minutes-long compile times of Rust and the seconds-long compile times of Go.

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

#699

Post by [deleted] »

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

[deleted]

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

#700

Post by tialaramex »

pjmlp wrote: post #679
tialaramex wrote: post #677

Earlier quoted context omitted.

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.

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

To be sure the fact the diagnostics aren't required does not forbid them from being provided, but it does mean you'd need to know whether you've been provided with such diagnostics and how effective they actually are. Unless the answer is "I have diagnostics and they are 100% effective" you're in the same situation.

> I also don't find debugging Rust macros that fun

Which kind? I don't find debugging the declarative macros too hard, they are after all just expanding what you wrote according to some simple rules, and you can ask the compiler to show that expansion to you.

Procedural macros present unlimited potential for exciting debugging because now you're essentially modifying the compiler at runtime. A C++ pre-processor macro can cause some nasty problems but it's not going to run a different compiler... [Technically Mara's nightly-crimes only runs the same compiler with different flags, but it could run a different one if she'd needed to do that]

Post reply on HN