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

661–670 of 811 posts

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

#661

Post by kaba0 »

crabbygrabby wrote: post #607
kaba0 wrote: post #559

Earlier quoted context omitted.

> Did scala 3 finally clean up the syntax Well, they didn’t break the existing language, so not sure. It depends on what do you find readable/difficult. Because contrary to the usual opinion on the language, I believe it is not “difficult” - it has much fewer exceptional rules than Java for example. Sure, some features are more expressive and that comes with big responsibility, but to actually answer your question, s…

Null safety sounds great. My big gripe was all of the symbols and how they had different meanings in different contexts. That said, in most cases it's not a real problem, but with a team you can end up with some messy stuff.

Yeah I agree that operator overloading should be used very sparingly, I often dislike it in Haskell as well. Fortunately it seems to be less and less often used in modern libraries.

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

#662

Post by dang »

crabbygrabby wrote: post #659
eternalban wrote: post #520

Earlier quoted context omitted.

> Rust really is a great programming language that solves a lot of other problems other languages don't. It does so by introducing a pretty clever paradigm. Were you around when Scala was the end all be all of programming shiny things? "Early on, Scala rode a wave of hype that frankly surprised even me: hype around pushing syntactic boundaries, hype around reactive architectures, hype around functional programming, h…

I appreciate your view on scala and rust. I was around when scala became popular and wrote it in industry for a while. It wasn't a great time. I think rust differs from scala in what it is trying to do. I also think rusts' complexity is backed by functionality that defines it's paradigm. Scala on the other hand has a few too many 'i think this would be nice to support' features in it that make it messy to deal with.…

Sorry for the offtopicness, but could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.

You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...

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

#663

Post by crabbygrabby »

logicchains wrote: post #541
whazor wrote: post #386

Earlier quoted context omitted.

Rust makes it easier and faster to create certain classes of applications, specifically applications that originally would be written in C and C++. Things that are hard in Rust, are even harder in C and C++. So Rust is liberating and 'rewriting' complicated applications can be satisfying because you can move faster. For me personally I am playing with Wayland and display streaming and it is very satisfactory so far t…

>Things that are hard in Rust, are even harder in C and C++ This is absolutely not true. Something hard in Rust but almost trivial in C++ (via fold expressions): mapping or folding a function or operator over a tuple of heterogeneous types. E.g. to sum over a tuple of arbitrary numeric types: auto mySum = std::apply([](auto... x){ return (x + ...); }, myTuple);

This is a pretty weird example. Why do you want to sum over a tuple of different data types in the first place? This kind of has a code smell I can't put my finger on...

Fwiw rust doesn't let you dynamically index tuples, because rusts' take on tuples is different.

Should your tuple actually be a struct with a "sum" method on it? Imo probably. Or should you have your numeric types be the same type for better memory layout, maybe...

Just because another language let's you do something doesn't mean you should do it. Kind of like in js, does it make sense to divide a number by a string(not sure if you can do this but guessing it's valid js), probably not, is it a feature or a bug, you decide. Should this be part of say the kotlin standard, probably not.

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

#664

Post by therockhead »

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.

I disagree. If you want common code between all platforms (iOS/Android/Windows/macOS) your choices are pretty limited. Right now I work on a large codebase where C++ is used to solve the code sharing issue, but would much prefer it to be Rust.

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

#665

Post by jjtheblunt »

jjnoakes wrote: post #200
jjtheblunt wrote: post #188

Earlier quoted context omitted.

> There are almost no active / popular libraries related to network IO that haven't switched over. wouldn't Go afficianados say Go is a counterexample right under every Rust programmer's nose?

How is go a counterexample to the rust library situation?

not to the rust library situation, but it made me wonder, since Rust does not even presume a stdlib, if a standard library with green thread aware implementations, as in Go, is possible in Rust.

(i definitely could have worded that better up above, to your point!)

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

#666

Post by crabbygrabby »

blub wrote: post #398
whazor wrote: post #386

Earlier quoted context omitted.

Rust makes it easier and faster to create certain classes of applications, specifically applications that originally would be written in C and C++. Things that are hard in Rust, are even harder in C and C++. So Rust is liberating and 'rewriting' complicated applications can be satisfying because you can move faster. For me personally I am playing with Wayland and display streaming and it is very satisfactory so far t…

Where's the proof that Rust makes it easier and faster to create applications? In my experience it's harder and slower compared to other languages like Go and even C++, but you get memory-safety in return while keeping a very good runtime performance profile.

Rust removes a lot of the debugging and performance tuning, that happens later in production. Is it easier/faster while you are learning. Nope. When you understand it, sure it could be. This depends on the person. Just like how someone might be faster or slower at a specific framework within the same language.

Imo I write programs faster than other languages because the compiler helps me out. Your mileage may vary.

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

#667

Post by bluGill »

Santosh83 wrote: post #589
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…

> but I'll take C over C++ anyday. Did you mean the opposite?

opps, yes I did.

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

#668

Post by bluGill »

jstimpfle wrote: post #632
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…

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.

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

#669

Post by crabbygrabby »

dang wrote: post #662
crabbygrabby wrote: post #659

Earlier quoted context omitted.

I appreciate your view on scala and rust. I was around when scala became popular and wrote it in industry for a while. It wasn't a great time. I think rust differs from scala in what it is trying to do. I also think rusts' complexity is backed by functionality that defines it's paradigm. Scala on the other hand has a few too many 'i think this would be nice to support' features in it that make it messy to deal with.…

Sorry for the offtopicness, but could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html . You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that woul…

I was making new accounts for each different topic I posted on. For example I only used this account for this entire topic. I'll stick with crabby grabby. Sorry didn't know.

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

#670

Post by dang »

crabbygrabby wrote: post #669
dang wrote: post #662

Earlier quoted context omitted.

Sorry for the offtopicness, but could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html . You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that woul…

I was making new accounts for each different topic I posted on. For example I only used this account for this entire topic. I'll stick with crabby grabby. Sorry didn't know.

Appreciated!
Post reply on HN