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

801–810 of 811 posts

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

#801

Post by ssokolow »

int_19h wrote: post #796
roblabla wrote: post #794

Earlier quoted context omitted.

GC and FFI do have a lot to do w/ each-other though, because FFI usually introduces unmanaged objects. When a lot of what you're doing is interacting with low-level platform APIs, you end up having a lot of those unmanaged objects. After a certain point, the upsides of using a GC kind of disappear because you still have a lot of places you have to worry about those objects. Of course, this can be worked around by pro…

Unless your code is strictly glue between those lower-level APIs, GC is still a benefit for the majority of it. And, on the other hand, the lack of it in FFI is, at worst, similar to C... except you still have all the other language features (like, say, null safety or pattern matching) at your disposal. I'm genuinely curious as to what would make FFI in Rust easier than in C#, assuming an apples-to-apples comparison…

Rust seems to excel in having an ecosystem that provides binding helper libraries like PyO3, Neon and napi-rs, Helix, etc. which both ensure "if it compiles, you're doing the C glue properly" and provide a layer for automatic type conversion.

...so requiring `use of "unsafe"` is often akin to forbidding Cargo/pip/NPM/etc. and then calling the language un-productive or faulting a procedural/imperative language for performing badly when you code as if you're writing Haskell.

https://www.hobofan.com/rust-interop/

https://areweextendingyet.github.io/

Using the ecosystem rather than reinventing it is a core tenet of Rust's value proposition.

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

#802

Post by ssokolow »

pjmlp wrote: post #647
wheelerof4te wrote: post #624

Earlier quoted context omitted.

"It is ironic to build super safe software, then deploying them on kubernetes, written in a GC'd language prone to nil dereference errors." This is something that escapes a lot of people nowadays. Everyone uses a browser and they are inherently unsafe.

I feel it is a bit ironic that Apple and Google rather introduce mitigations for C++ in their browser engines than introduce Rust into the codebase. Meaning that Firefox's gains with Rust will eventually be lost given its market adoption is slowing reaching zero.

Google is investigating Rust as part of a multi-pronged strategy and, while it has the "this is not an official Google project" boilerplate, the `autocxx` crate (a header-parser/code-generator addon for the `cxx` interop crate) is by Google employees.

https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76D...

https://www.chromium.org/Home/chromium-security/memory-safet...

https://github.com/google/autocxx

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

#803

Post by ssokolow »

adgjlsfhk1 wrote: post #783
nimrody wrote: post #775

Earlier quoted context omitted.

To get to a low GC overhead in Java (and perhaps other languages too) you have to pay with an increase in memory consumption. Sometimes as much as 100% additional RAM to avoid frequent full GC scans.

That's true, but malloc/free based systems also have a relatively high memory overhead due to fragmentation and programmers being worse at inserting frees than the GC. It's not at all clear that the C/C++ model of memory management has lower than 100% overhead for long running programs.

> but malloc/free based systems also have a relatively high memory overhead due to fragmentation

In case you haven't seen it, there's been some interesting progress on that front:

https://www.youtube.com/watch?v=c1UBJbfR-H0

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

#804

Post by preseinger »

CraigJPerry wrote: post #789
preseinger wrote: post #774

Earlier quoted context omitted.

This Go code is wildly non-idiomatic. Type assertions via `.(type)` are a tool of last resort, not something that an application developer should turn to as a solution to a problem, and certainly not post-1.18, which permits generics. edit: e.g. https://go.dev/play/p/wDO5J8CElSC

Hey thanks for sharing this, I think this has lost track of the problem though, remember we're looking for the alternative to rust's: enum Shape { None, Circle(radius: usize), } In your version we've lost the Shape concept, to make it more explicit, what's the idiomatic go version of: enum Shape { Circle(usize), Rectangle{length: usize, breadth: usize}, } https://play.rust-lang.org/?version=stable&mode=debug&editio..…

There is no way to express an enum whose possible values are of different types.

In Go code will typically "offer" concrete types, and "accept" abstract interfaces. Abstractions over concrete types are expressed by consumers who want to operate on those types, rather than producers who provide implementations of them. So your Shape would probably end up an interface defined by whatever consuming code wanted to treat Circles and Rectangles equivalently.

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

#805

Post by Tozen »

inChargeOfIT wrote: post #49
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…

I really like the idea of something like vlang ( https://vlang.io ), as I've tried multiple times to find the motivation to learn Rust, but always end up going back to golang for the simplicity.

Unless there is some very compelling reason to need Rust, a lot of people would be better off with Golang or Vlang, because it would make their lives easier in terms of more general usage and ease of use.

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

#806

Post by pdimitar »

jokethrowaway wrote: post #721
hirrolot wrote: post #507

Earlier quoted context omitted.

> without touching async The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code. Or he/she writes very-very straightforward, if not primitive async code and doesn't touch HOFs, traits, and similar stuff at all. However, when you write networking code, you typically use async. The worst role i…

There are two things to mention: 1. Async for trivial things is straightforward and easy 2. Rust actively discourages some async patterns to protect you from some memory misuse edge cases It does limit your freedom in writing code that eg. relies a lot on async callbacks, but there's a reason. The first time I did a massive async project (think a rust binary maxing all cores executing the largest possible number of a…

Did you do a write-up on this pattern? I'm finding myself in a similar situation lately and I'd appreciate the help a lot.

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

#807

Post by pdimitar »

fulafel wrote: post #238
jjnoakes wrote: post #216

Earlier quoted context omitted.

I would say most systems are either slower or less correct, yes. The nice thing about being a developer is that these costs are mostly hidden from us. The business pays for more compute if you churn out slow code, and churning out bugs just increases your job security. Imagine if you had to pay for the performance loss or production bugs directly though...

For the rare case where the small speedup is otherwise worth the lower producitivty of Rust, it can still be a worse choice because the you have a disadvantage in iteration speed to rework the code for a faster problem solving strategy / algorithm.

The strong and static type system makes refactoring and iteration pace extremely predictable in Rust. And it's often quick to do as well.

With dynamic languages you can pretend you're done in an hour and then endure a lot of production bugs. That's not being more productive than Rust. That's playing pretend that a complexity doesn't exist.

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

#808

Post by pdimitar »

phendrenad2 wrote: post #253
mikebenfield wrote: post #239

Earlier quoted context omitted.

Pretty damn mainstream nowadays, yes. Quite a few big tech companies are either actively doing much of their new systems programming in Rust, or else dipping their toes in. I honestly don't know of a big tech company that is happy with the idea of just continuing to use C++ indefinitely - they are _all_ looking for alternatives, and Rust is the most obvious option.

> Quite a few big tech companies are either actively doing much of their new systems programming in Rust, or else dipping their toes in I don't think that's true. It seems to me that a lot of people believe this simply because a lot of other people believe it. You see it everywhere. "Oracle rewriting MySQL in Rust". "Microsoft rewrites Skype in Rust". "Linus Torvalds rewriting Linux in Rust". I have yet to see proof…

> I have yet to see proof of any of it.

It looks like you're actively avoiding finding that evidence.

Citing clickbait titles doesn't sound like you have actually looked.

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

#809

Post by pdimitar »

ncmncm wrote: post #283
mikebenfield wrote: post #239

Earlier quoted context omitted.

Pretty damn mainstream nowadays, yes. Quite a few big tech companies are either actively doing much of their new systems programming in Rust, or else dipping their toes in. I honestly don't know of a big tech company that is happy with the idea of just continuing to use C++ indefinitely - they are _all_ looking for alternatives, and Rust is the most obvious option.

More people pick up coding C++ professionally in any given week than the total being paid to code Rust full time. The bigger a company is, the more various languages people there dabble in, and the less it means that somebody there dabbles in your favorite. You would better add up revenue (NB: not market cap) of companies specializing in using your favorite language; but that number would be disappointingly small for…

I wasn't aware that restating an entrenched state of affairs is an argument in a discussion.

Doubly so when that entrenched state of affairs is actively being attacked every day for years now.

But sure, let me not stop you.

Post reply on HN