Live data from Hacker News

Rust Is Hard, Or: The Misery of Mainstream Programming

hirrolot.github.io

481–490 of 811 posts

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

#481

Earlier quoted context omitted.

I for one as someone who programmed professionally in both Ocaml and Ada still don’t see where Rust is supposed to fit. If I was doing something high level, I would probably use Ocaml which has nicer features. If I wanted to write safe code, Ada offers a better experience with the availability of SPARK for parts I would probably end up wanting to prove. If I just want to write concurrent code with the certainty I cou…

Rust is supposed to be a better C++, and resoundingly succeeds at that goal.

It partially succeeds at that, because while it has a much better story in being safe by default, there are plenty of C++ use cases where Rust still hasn't a story to sell.

HPC, HFT, GPGPU, LLVM/GCC infrastructure, GUI, console SDKs, drivers SDKs, security certification ,....

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

#482
post #479
post #475

Earlier quoted context omitted.

This feels a bit like complaining that a tank is badly designed because nobody drives them on the highway... My understanding is that Rust was designed to be a safe(er) language to write low-level system code than C/C++, not to compete with Python/Ruby/Java for web development applications.

True, yet what you see around HN and other places are people trying to use it for web development.

Front end or back end? I see nothing wrong with rust on the back end, not sure how it would even work on the front

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

#483

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.

Read the rust book and practice for two weeks, you'll get the hang of it. It's just not a language you can pick up 80% of it in a day. Like BASIC or Go or something

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

#484
post #481

Earlier quoted context omitted.

Rust is supposed to be a better C++, and resoundingly succeeds at that goal.

It partially succeeds at that, because while it has a much better story in being safe by default, there are plenty of C++ use cases where Rust still hasn't a story to sell. HPC, HFT, GPGPU, LLVM/GCC infrastructure, GUI, console SDKs, drivers SDKs, security certification ,....

Ok, fair, you’re right. Rust is successful in a rather large subset of C++ niche, but not yet the whole thing!

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

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

> Rust-like programming language that was just a little bit higher level

I think the best answer is Scala. It has an awesome community/libraries/ecosystem. See this for example https://news.ycombinator.com/item?id=31601040#31604573

There are other great answers, like F#, Haskell or OCaml, but these are not as mainstream and that comes with its challenges.

With Scala you get and awesome IDE, surprisingly wide variety of libraries and the whole Java world as a backup.

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

#486

Earlier quoted context omitted.

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.

There are plenty of languages to choose from if you allow a GC. I think Rust's niche is systems-level programming where a garbage collector is an impossibility. I wish there was an easier to use language with Rust's features which occupied this niche. I find myself reaching for modern C++ instead of Rust when I want to be productive :(

Same here, I like Rust a lot, however in one side I already have JVM and .NET languages for 99% of the stuff I do, and for the remaining 1%, having C++ burned on my brain since 1994, with the 40 years of tooling, I rather spend the time using it.

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

#487
post #329

Earlier quoted context omitted.

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.

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

Having an npm like ecosystem is hardly better.

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

#488

I've been doing a lot of Rust the last two weeks. Like others have said, if you stay away from async, it's not that bad. But I also have plenty of experience in OCaml and Standard ML and Scala, and also C++. Still, I'm finding my C++ experience is more hindrance than help most times. Async & Tokio is pure hell if you have any kind of shared mutable state. And also it's tough to fight 20-30 years of programming experi…

>Rust can work this way, but mostly doesn't by default. It's like you were programming in C++ but instead of normal copies and references, almost every single variable use was a std::move. Profoundly unintuitive. I just used this variable, why can't I use it again?! This was my experience of rust as well. I've since forgotten exactly what I was trying to do (it was a year ago now), but a seemingly innocuous check of…

Yeah to be clear I'm not opposed to the semantics of how Rust manages lifetimes. I'm ... disturbed.. by the syntax.

It feels "bolted on".

Variable assignments and usages that borrow should be clear with a different syntax.

Lifetimes should not be lumped in the same box with other type parameters but instead broken out visually into some other sort of annotation on the type.

BTW I also think "std::move" in C++ is a hack. They should have introduced a new syntactical element for that as well instead of masquerading it underneath a pseudo-function.

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

#489
post #365

Earlier quoted context omitted.

This selection effect cannot explain Rust's standing relative to other new languages and neither can it explain why Rust's popularity (as measured by "most loved") increases over time as more and more companies are using it. Here's the history of Rust's "most loved" percentage going back to 2015 Year - Most Loved Pct. - Rank 2015 - 73.8% - 3 2016 - 79.1% - 1 2017 - 73.1% - 1 2018 - 78.9% - 1 2019 - 83.5% - 1 2020 - 8…

I'm a bit surprised that Rust is really the top language here. I would have expected the top ranked languages to be nowadays-relatively-unpopular languages with dedicated long-time users, like Lisp, Tcl, Perl, and APL. Is this weighted somehow by overall popularity?

Well the second one is a LISP (Clojure), which isn't really popular (relative to more mainstream languages).

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

#490
post #271

Earlier quoted context omitted.

The problem is there is more than one kind of "fast". There is latency "fast" and throughput "fast". For a lot of web stuff you need throughput more than you need latency "fast". In order to do throughput well you need concurrency.

There’s also how much it takes to hire 5 developers ”fast”. At least for now, Rust is not that performant on that respect.

Pretty sure you could hire 5 rust developers pretty easily. A lot of people in the rust community are dying to find a job that will let them write rust professionally...
Post reply on HN