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

591–600 of 811 posts

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

#591

Post by NoGravitas »

orthoxerox wrote: post #456
labrador wrote: post #138

Earlier quoted context omitted.

People don't like to mention C# since like PHP, it has a bad rep from early days, but C# 10 and .NET 6 hit all the sweet spots people are mentioning. C# and .NET now run on Linux and Mac and compile to a single executable like Go with tree shaking so the binary is much reduced. I don't really care, but it's a shame people don't take another look at C#. When I learned Rust I was surprised how similar it felt to C#, bu…

Static interfaces are still in preview, DUs aren't being actively worked on, that's what I miss from Rust when I'm writing C#.

Have you used the OneOf library? It's not DUs, but it's kind of an 80% solution in that space.

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

#592

Post by blub »

garethrowlands wrote: post #514
blub wrote: post #396

Earlier quoted context omitted.

How you feel relates to you and your preferences and doesn't really say anything about Rust versus let's say Go. Is your software more performant and does this translate to additional customers or reduced costs? Is your software more stable and does this result in reduced support costs or happier customers? Testing effort is likewise not a decisive matter. In fact it's quite likely that what one wins time-wise on the…

Rust and Go are surely different classes of programming language. Rust is a systems language and Go is garbage collected. That is, Go is in the camp with Ruby, Python and Javascript, whereas Rust is in the camp with C and C++. Garbage collected languages are easier to use than non-garbage collected languages, so if you can use them, you should.

Why is a systems language used for web applications, servers, command-line utilities and all sorts of libraries?

The article is about a “messenger bot” for example and nobody’s complaining that it’s wrong to write such a thing in Rust.

The reality is that Rust is competing with Java and Go and Python for many things and its poor ergonomics are hobbling it.

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

#593

Post by NoGravitas »

pjmlp wrote: post #305
lelanthran wrote: post #206

Earlier quoted context omitted.

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

Actually something like traits (as concept) is what powers COM, WinRT, the basis of Objective-C protocols that influenced interfaces in more common OOP languages. Also the basis for one programming language that used to be widespread in the enterprise for quick and dirty solutions, VB and its ecosystem of OCX libraries. It is more widespread that people think, because when many argue about OOP, they miss the full spe…

Traits seem, to me, a lot like generic functions and methods in CLOS (Common Lisp). It's just that CLOS doesn't bundle a group of generic functions into a trait, they're a la carte.

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

#594

Post by blub »

gary17the wrote: post #403

While the article is an absolutely excellent analysis of Rust from the low, PL-level ergonomics point of view, it seems to largely miss (or, intentionally, skip) the bird's eye point of view of complexity inherent to software development. I was recently tasked with developing a fragment of a mobile app written in Objective-C++ (an awesome PL powerhorse, BTW) that mixed multi-threaded (multiple dynamic UI layers, mult…

Rust is not an appropriate solution for iOS, I don’t think it’s even possible to use it except through some hacks. So the options aren’t buggy Objective-C++ vs inelegant but safe Rust.

It’s having a product vs. not having one and the latter guarantees a lack of commercial success.

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

#595

Post by Hirrolot »

NoGravitas wrote: post #587
valenterry wrote: post #345

Earlier quoted context omitted.

I think after the (correct) first sentence you are a bit mistaken here. The example you describe can be solved correctly and also with good performance in garbage collected languages such as Haskell or Scala. I would even say that those languages make a correct solution easier than in Rust, but they trade in a bit of performance for it (e.g. by using immutable datastructures instead of an ownership model). But for as…

You can get great performance from garbage collected languages, to be honest. I guess what you can't get is perfectly predictable latency — but that only matters for a pretty narrow class of applications.

How then people write high-performance servers in JVM?

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

#596

Post by skohan »

CraigJPerry wrote: post #585
skohan wrote: post #427

Earlier quoted context omitted.

Not the person you're responding to, but imo 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. That said, I think Go's simplicity has a lot of advantages over Rust for a great many use-cases. Imo Rust almost feels like a prototype for a great language which will finally get ownership-based memory management right. The goals…

>> 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 find this type of programming very expressive and easy to reason about.

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

#597

Post by ncmncm »

mikebenfield wrote: post #551
ncmncm wrote: post #273

Earlier quoted context omitted.

Rule of 5 was a C++11 thing, maybe even mainly a C++03 thing. Your complaints about C++ have aged badly. C++20 is not the same language as C++11, which was not the same language as C++03. Rust's complexity is rapidly approaching C++'s. In 5 years, if Rust hasn't fizzled, it will get there. Only being used to it will make it seem any simpler.

> C++20 is not the same language as C++11, which was not the same language as C++03 This is not a good thing. In fact, it's a shockingly bad thing. C++ is basically 40 years old, and still every few years the C++ community feels like, "OK, now we know how to get C++ right; yeah the old C++ was a mess, but now we just need to add these 12 new features and it'll all be good." Unfortunately many of the problems with C++…

If it is bad that C++ evolves, then it is worse for Rust, which has been evolving much faster, trying to catch up. It is still just barely possible Rust could avoid fizzling. For that to happen, it will need to change enough so that the many, many more people who reject than embrace Rust, as it is today, choose differently tomorrow.

Evolution is necessary to stay relevant; the only alternative is stagnation. If your language or your code of five years ago does not embarrass you today, it only means you haven't learned anything new.

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

#598

Post by Hirrolot »

NoGravitas wrote: post #590
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…

Koka and Vale both seem to be decent (experimental) approaches to languages that learn from Rust, both what it got right, and what it got wrong.

I think Rust will eventually repeat the story of C++. 1) There will emerge more ergonomic languages that solve real-world problems that Rust attempted to solve. 2) Rust's issues with type system and async will be largely resolved, so it could be used in areas where it is absolutely required.

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

#599

Post by klysm »

gwbas1c wrote: post #545
logicchains wrote: post #535

Earlier quoted context omitted.

People talk about C++ suffering from its commitment to zero-cost abstraction, but the same thing applies to Rust async. While async may theoretically be the fastest possible way to write asynchronous code, it feels like an order of magnitude more painful than the CSP/channel-based approached used in languages like Go and Clojure (and the upcoming Java Loom). Personally if I had to write async code that required anyth…

I made the mistake of trying to learn Rust while doing async programming. IMO, when it comes to concurrent, it's a matter of picking your poison: Threaded Rust: No overhead of a GC, but overhead of context switches and multiple stacks. NodeJS: No overhead of context switches and multiple stacks, but the overhead of a highly optimized GC. (And I suspect that the GC can do tricks like run when the process is waiting on…

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.

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

#600

Post by steveklabnik »

blub wrote: post #594
gary17the wrote: post #403

While the article is an absolutely excellent analysis of Rust from the low, PL-level ergonomics point of view, it seems to largely miss (or, intentionally, skip) the bird's eye point of view of complexity inherent to software development. I was recently tasked with developing a fragment of a mobile app written in Objective-C++ (an awesome PL powerhorse, BTW) that mixed multi-threaded (multiple dynamic UI layers, mult…

Rust is not an appropriate solution for iOS, I don’t think it’s even possible to use it except through some hacks. So the options aren’t buggy Objective-C++ vs inelegant but safe Rust. It’s having a product vs. not having one and the latter guarantees a lack of commercial success.

Cloudflare's 1.1.1.1 app is a good example of using Rust code on iOS.
Post reply on HN