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.
Rust Is Hard, Or: The Misery of Mainstream Programming
401–410 of 811 posts
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#402Earlier 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'…
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#403I 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
#404Earlier 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.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#405Earlier 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.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#406I 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…
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
#407Is 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.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#408I 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
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#409Earlier 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…
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
#410Earlier 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…
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...