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

451–460 of 811 posts

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

#451

Post by sph »

karmakurtisaani wrote: post #441
avidphantasm wrote: post #434

Earlier quoted context omitted.

I’m still learning Rust, but the idea of having to use unsafe features to implement something as simple as a linked list seems “wrong” to me. What am I missing?

I kind of hit a wall with Rust after realizing that something like doubly linked lists are difficult because when two nodes are referring to a node between them, you don't have a clear owner. So basically all situations where you have two or more references to an object need to be thought out carefully, and for me it was a bit of a let down (even though I fully understand the reasoning behind it and why it's useful).…

Unpopular opinion but the whole memory safe idea is more niche than HN commenters would have us believe. Most of us are writing web apps and services that do not have strict memory requirements nor catastrophic failure modes.

Dynamic languages and GC'd languages cover most of what our employers are paying us for: web apps, backend services. It is ironic to build super safe software, then deploying them on kubernetes, written in a GC'd language prone to nil dereference errors.

Rust has its place, but it's a very small place. These days computers are so fast there's companies worth billions built on Ruby and Python, if you go native with a GC language you'll cover 98% of your needs.

Rust IMHO has gone too far towards safety at the expense of developer ergonomics and pragmatism. We're so expensive that adopting a subpar language that is easier to grok is often a savvier business decision.

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

#452

Post by EugeneOZ »

kaba0 wrote: post #450
EugeneOZ wrote: post #446

Earlier quoted context omitted.

“Side-effect” of borrow-checking - there is always only one who can write to a variable. It's much more important than GC.

Oh I see. No it does not have it enforced at the language level, but it relies heavily on immutable data structures, and the type system is strong enough to express a complete actor-based concurrency library. But since it is interoperable with Java and that exposes low-level primitives of concurrency, it can’t really be made guaranteed data-race free.

Your responses were quite informative, thank you. Even for me, Scala looks more interesting now. I have some Java adepts, I’ll try to convince them to climb a few steps.

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

#453

Post by nerdponx »

Omin wrote: post #365
jstx1 wrote: post #311

Earlier quoted context omitted.

No, it's a selection effect. The stackoverflow most loved metric is people_who_want_to_keep_using_the_language / people_who_have_used_it_in_the_past_year Since Rust is so early in its adoption and there are few jobs, many of the responders are hobbyists who are into Rust, like it and want to keep using; not necessarily people who use it for work. And since you only take into account the people who have used it in the…

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?

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

#454

Post by javajosh »

kaba0 wrote: post #432
javajosh wrote: post #55

Earlier quoted context omitted.

Interestingly, I've become a big fan of node's single-threaded "one big loop" model, which means multitasking is cooperative instead of preemptive. This strikes me as more honest, somehow. It doesn't distract you with abstractions (like threads) that don't make sense in this context. Most production workloads these days will be a docker process assigned to (at best) a single sticky core/thread on a blade somewhere -…

> Plus there is OpenJDK I'm not sure what you mean here, but if you refer to OracleJDK here then there is basically only OpenJDK for quite some time now -- OracleJDK is just an (optionally) paid support version of the same codebase. Also, most other vendors are pretty much just tiny patched OpenJDKs also, with some niche exceptions.

You must be young. Java was not always distributed like this, and although it was "open source" few people compiled it, and the JRE and JDK was distributed by Sun (then Oracle) primarily through a user interactive web UI. The OpenJDK existed alongside this for some time, but then supplanted the proprietary binaries. That was a relief because it meant Java was actually (not just theoretically) open source now, which meant it was safe from deprecation, disablement, and all the other negative aspects of control that come with de facto proprietary software.

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

#455

Post by rascul »

jedisct1 wrote: post #246
DeathArrow wrote: post #217

Earlier quoted context omitted.

>As I've said before, if you're writing webcrap, use Go. The libraries for web-related stuff are stable and well-exercised, since Google uses them internally. I don't get why are you so dismissive about web programming? The Go libraries are good because it's easy to write good libraries in Go. And it's easy to write good libraries in Go, because of design decisions. Same for C#, F#, Java, Python and more.

Go's ecosystem is amazingly stable. Its rich standard library helps, but in general, there's a lot of attention to backward compatibility. Once an application has been written in Go, updating dependencies or using a more recent compiler version is a breeze. Nothing breaks. Rust code on the other hand comes with a high maintenance cost. The ecosystem is still very unstable. Core dependencies constantly have breaking A…

> The ecosystem is still very unstable. Core dependencies constantly have breaking API changes, or get abandoned/deprecated/superseded. Keeping everything up to date is not trivial and very time consuming.

I'm only a hobby coder but this has hit me a few times. I suspect this will level out in time, though.

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

#456

Post by orthoxerox »

labrador wrote: post #138
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…

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#.

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

#457

Post by christophilus »

dgunay wrote: post #373
adastra22 wrote: post #241

Earlier quoted context omitted.

If your primary criticism of golang is that its creator doesn't like syntax highlighting, then it must be doing pretty good.

It is mostly an example of the mindset that I think GP is trying to illustrate. Go has nil where Rust has Option. Go has weird not-quite-tuple returns & if err != nil where Rust has Result. Go has no real enum concept, where rust has its powerful enums and matching constructs. Go has generics, but only after a decade of pressure from users (and even then, they are much much less useful than Rust's type system). I lik…

I would love a language that combined the best aspects of Go and F#: expressive, great type system, fast compilation, native binaries, opinionated formatter, excellent concurrency, comprehensive standard library, consistent documentation, etc.

Throw in great compile to JS capabilities with small bundle sizes and the ability to map Typescript typings into the language so you can seamlessly consume well typed libraries, and man. Killer language, right there.

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

#458

Post by galangalalgol »

indeyets wrote: post #425
brabel wrote: post #245

Earlier quoted context omitted.

You think Java and Go are slow but like Julia? It takes 2 seconds just to fire up a Julia interpreter. Its runtime is extremely heavy.

well… you start it once and just use forever after that

That is what I usually do. And you can supposedly precompile everything if you just want to deploy a service so restarts are short. I have not done that though.

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

#459

Post by xolve »

I find rust and scala quite similar on learning curves. You have to reach a certain level before you can work with the language and library ecosystem.

The benefits proposed by proponents of both languages are there but after the mean of the bell curve.

Also a beginner is asked to work with external interfaces and libraries because the language and its standard library is defined to be minimal in certain ways. The answers to which are supposed to come later. So a lot to take it on the first step itself.

Both languages are still working on some answers and kept options open. So "why" of that is also complicated.

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

#460

Post by pkolaczk »

baq wrote: post #351
wodenokoto wrote: post #347

I've only written php, Python and R to any large-ish extend and way back in the day i was introduced to programming using Delphi. I have absolutely no idea about what is going on in that article. Is Rust just completely different from everything else, or have I been completely shielded from "actual programming"?

1. garbage collection is amazing for developer productivity if you can afford it. 2. if you don't know if you can afford it, you can.

> 1. garbage collection is amazing for developer productivity if you can afford it.

Probably not for everybody. I haven't noticed any significant productivity boost when coming from C++ to Java years back, and then I also can't see any significant productivity decrease when switching from Java to Rust. I feel the unavailability of GC is widely offset by other features that make Rust more productive than Java. Surely, I got stuck once or twice while learning (Rust is harder than Java) but once it clicked, I know which things to avoid and generally it goes very smoothly. Now there are many things I love about Rust and I constantly miss in Java.

(The number of times I wished I had RAII in Java) > (The number of times I wished I had tracing GC in Rust).

Post reply on HN