Live data from Hacker News

Rust Is Hard, Or: The Misery of Mainstream Programming

hirrolot.github.io

401–410 of 811 posts

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

#401
post #266

A language is starting to approach maturity when articles complaining about it or explaining how to work around its fundamental flaws come to exceed articles bragging about having got something, anything, working in it. Rust might yet get there.

As the adage goes: "There are only two kinds of languages: the ones people complain about and the ones nobody uses".

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

#402
post #385
post #334

Earlier quoted context omitted.

Rust is young, very ambitious, of course general purpose enough to do everything in it, but its ecosystem has serious gaps. (And some of those are dependent on planned language level features.) ... I spent a lot of time reading r/rust, various blog posts before going beyond helloworld in it. To me it's in the same category as Scala (ZIO) or TypeScript. Both are very powerful, a joy to work with them, until the low-le…

Totally agree. Scala and TypeScript are both usually wonderful to write. Though I might argue that one of Scala's biggest issues in my eyes, performance, is mostly _not_ a JVM limitation. For example, a Scala for-loop calls functions on each iteration, and immutable containers need to be garbage collected for each modification. Both of these could be compiled away in many common cases (like C++ or Rust do, but Scala'…

I don't have too deep knowledge of Scala compilers, but Scala 3 is a huge revamp so I wouldn't be surprised to see it change. Though both of the mentioned cases seems to be easy to "fix" by the JIT compiler -- the JVM is really good at inlining and short-lived objects are almost free.

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

#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, multiple levels of background processing) and async (multiple over-the-network downloads, multiple database updates, etc.) To make a long story short: even though I've been coding C++ for 20 years, I am still a bit depressed about how badly I got my own @$$ handed to me on my first try. It took a ton of bug hunting and code refactoring to get everything right. Being forced by Rust to throw together a couple of somewhat inelegant reference counted pointers is... trivial compared to the benefits Rust offers (safety).

I was also recently tasked with investigating serverless. To make a long story short: due to the fact that serverless is billed by the amount of memory used and the CPU time required to execute a lambda, so far in my analysis Rust is coming out on top over interpreted and garbage-collected languages to such extent that it actually makes the difference not just between a "good" and "very good" solution, but between an "impossible" and "feasible" one, cost-wise. Being forced by Rust to read a couple of books on how the new concepts of ownership and lifetimes work is... trivial compared to the benefits Rust offers (efficiency).

If you define "feasibility of a commercial success" as "finding a pain point and being the only solution for it on the market", then it becomes more and more likely that, with time, Rust will win over many other PLs.

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

#404
post #329

Earlier quoted context omitted.

Ocaml is just a mess. Has like two standard libs. You'll just fighting everything but your application logic instead.

There is only one OCaml build system (dune) which is used by people that don't write their own build system. But yes, you have the freedom of using alternative to the OCaml standard library if you wish so.

I might terminally dumb

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

#405
post #313

Earlier quoted context omitted.

I agree, I don't understand why so many people lately seem to want to use Rust for web domain stuff. I don't like Go, I hated the year I had to work in it @ Google. But frankly, it's better suited for 'server' type stuff, unless you're talking about a very specific type of server that has super intense latency guarantees. And now that Go has generics, I'd probably hate it less. Go is the new Java. Rust is the new C++…

> Go is the new Java. I hope not, it might have some generics now, but still has a lot to catch up with. I surely don't miss coding in Java 5 (2004). > Rust is the new C++ Rust might become the new C++, and while being safe by default is great, there are plenty of C++ use cases where Rust has zero presence in 2022.

Generics were around for some time now, and people don't seem too keen on using them for anything aside from data structure specialisation, because frankly dynamic dispatch via interfaces hits such a sweet spot where you get a lot done with a very minimal overhead. The added syntactic complexity is very rarely justified, and containers is perhaps one of those cases where it is the case. Otherwise, from what I observed— generics in Go were massively over-hyped, but failed to gain the traction that was initially expected from it. I feel like there's a very good reason for that.

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

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

Scala might just be that. It has a very strong type system which is quite similar to Rust's, lifetimes are managed by the JVM's state-of-the art GC, and all in all it is a very expressive language. Think of python-level expressivity, but all statically typed with type inference. It also has a similar stance on the functional-imperative question as Rust has - it prefers functional concepts but lets you write imperative code when you want to hand-optimize something.

Oh and I almost forget to point out that it can just use basically one of the largest ecosystems, and can also compile to js or native (for the latter there is scala native as well as graal)

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

#407

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.

I am interested in Rust because of its safeguards around multithreaded programming. This is is my main motivation to learn it. What I've found good about rust is its modern toolchain and documentation.

The documentation to get started is outstanding with Rust

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

#408
post #23
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…

Go and Hare are rust-adjacent with just a touch of crayon involved. I highly recommend both especially Go since you mention rust with GC

Go's lack of expressivity and weak as hell type system is hardly close to Rust, like I can barely see a similarity other than both being a PL. Hell, probably Java is closer to Rust than Go, at least it is also nominally typed.

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

#409
post #276
post #18

Earlier quoted context omitted.

Writing widely useful, performant, reusable, correct and stable libraries is very hard. Rust is the easiest language to do that in. If someone says programming in another language is easier, it's because they are not attempting (or are failing) to do one or more of those things. Those things are not always important so that's fine, but a lot of programmers (myself included) have this dream of being able to solve a pr…

> Writing widely useful, performant, reusable, correct and stable libraries is very hard. Correct. > Rust is the easiest language to do that in. Wrong. Rust provides very substantially less support to library designers than C++ does. Anyone creating ambitious libraries finds Rust a big step down. Rust might get more of what C++ offers library designers as it matures, but only at the cost of whatever simplicity it can…

> Rust provides very substantially less support to library designers than C++ does. Anyone creating ambitious libraries finds Rust a big step down.

Before I used Rust my main language was C++ where I specialized in writing libraries, and this is a ridiculous statement.

It's only recently that the C++ standard library has gained enough functionality to do even some basic things in a portable way, so you're relying on other libraries to provide that, yet there is no standardized way to declare dependencies on those other libraries. There is no module system to ease structuring library code. There is no hygiene - a ton of stuff you include will just pollute the global namespace. There is no standard way to version your code. There is no standard way to update a library. Everyone uses incompatible string types - seriously, if you think Rust has too many string types, wait until you find out that every freaking C++ library represents strings differently, sometimes using the same types though! There is no standard place to publish libraries. Even basic language types like `int` differ massively from platform to platform, or even between different compilers on the same platform. Each compiler's preprocessor behaves slightly differently. The programmer must manually forward declare their functions, types, etc, and the rules are different for inline/templated code. All code is unsafe, and yet the rules for what constitutes UB are informal at best. (Whereas in Rust, the rules for UB are also not fully defined yet, but this is only relevant for the minority of your code which is not safe). All experienced C++ programmers think in terms of lifetimes, and yet cannot express this through the type system, so this must be documented informally. There is no standardized coding style or format.

I'm going to stop now just because I'm bored but this list could go on for a very long time...

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

#410

Earlier quoted context omitted.

I personally don't like Rust (I like to have a garbage collector for what I do), but I don't think it's a hard to read language. Readability is an incredibly subjective thing. For example, APL might look like an absolute mess to most people but to the people who know it, it's incredibly easy to read. All "readability" means in this context is that it's familiar to you. In my opinion, the only truly hard to read langu…

> For example, APL might look like an absolute mess to most people but to the people who know it, it's incredibly easy to read. But if we use that as a bar ("you have to know it"), then all languages are equally readable. Pretty much all the popular languages converge on similar syntax an/or grammar. You can say that it is because that particular set of syntax is the first, or you can say that languages that didn't h…

GP brought up a thing that’s certainly not equally represented in all languages. There are physical limitations for reading, and the amount of novel context you can juggle.

There is a balance between verbosity and conciseness that makes code more or less readable to different people.

If you have few experts who are maintaining a codebase over a longer time, then verbosity gets in the way. If you have a wider skill distribution and fast turnover, then you want verbosity.

Additionally I think there are more objective features. Like ambiguity, simplicity, formatting, naming, visual hierarchy...

Post reply on HN