Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Hope Rust Does Not Oxidize Everything

gavinhoward.com

Post reply on HN
Print view View original

81–90 of 195 posts

Re: I Hope Rust Does Not Oxidize Everything

#81

Post by [deleted] »

fxtentacle wrote: post #55
K0nserv wrote: post #38

The author makes the best argument for Rust in the linked post[0] Rust is great for teams because it removes many things that make working on team code dangerous. The items mentioned above are some. I work alone, however, because I like to keep my code in my head and working with people means parts of the code are only in their head. This also means that the bigger the language is, the less space I have in my head fo…

"Most code is written in teams and even software with a single author needs a plan for when the maintainer steps down." I strongly disagree! My experience is this: 1. Sole developer builds useful thing 2. Team takes over maintenance 3. Feature bloat, sluggishness, bugs ignored, Agile initiative, "Product owners" 4. Company goes bankrupt or gets acquired I don't think you can have the clarity of vision that a single p…

[deleted]

Re: I Hope Rust Does Not Oxidize Everything

#82

Post by steinuil »

zkldi wrote: post #36

I'll bite: What specific parts of rust syntax do people find so ugly? I keep hearing this from decent chunks of people who don't write rust, but the language doesn't seem that far off C to me. It's certainly no haskell.

I say this as a Rust enjoyer, but I think what most people mean when they say this is that there's a lot going on, especially in the function definition syntax. When you start adding in lifetimes and generics with bounds, async, &muts, where clauses... it really does become unreadable. I don't really see a way to fix this without making the syntax even more verbose, or aggressively simplifying the type system to the point that function argument inference becomes viable, but then you might end up in a situation like Swift's where type checking a simple expression takes an excessively long time.

That and the colon-colons (::), probably. Those can add a lot of noise.

Re: I Hope Rust Does Not Oxidize Everything

#83

Post by pjc50 »

ceronman wrote: post #32

The author seems very anxious because Rust is getting traction and they don't like Rust. They're afraid that one day Rust will become a "monoculture" and everything will be written in it. I like Rust, but I consider this very, very unlikely. Rust has actually brought more choice to the programming language scenario. If we're talking about monoculture, let's talk about C/C++. For decades this was the only viable optio…

Rust is challenging people because it declares several long-inadequate things about C/C++ to be inadequate (security issues, dependency management), and provides alternatives which show that it doesn't have to be like that.

The rewrites will inevitably be long and painful. Rewrites always are. But the onus on anti-Rust people is now to demonstrate a better language to rewrite in first, rather than just sitting in the status quo waiting for the steamroller driven by a crab to very slowly run them over.

D is interesting but seems to be a solo project, I'm not sure why it's not had traction. Maybe it's not different _enough_.

Re: I Hope Rust Does Not Oxidize Everything

#84

Post by fxtentacle »

K0nserv wrote: post #63
fxtentacle wrote: post #55

Earlier quoted context omitted.

"Most code is written in teams and even software with a single author needs a plan for when the maintainer steps down." I strongly disagree! My experience is this: 1. Sole developer builds useful thing 2. Team takes over maintenance 3. Feature bloat, sluggishness, bugs ignored, Agile initiative, "Product owners" 4. Company goes bankrupt or gets acquired I don't think you can have the clarity of vision that a single p…

> That's why so many useful things start with a single person or *a very small team*, You subtly shifted the goal posts here. But even if you start out with a single person you eventually have to have new maintainers, if only because of human mortality. Software is a young field so we haven't had to contend much with this fact yet, but it's inevitable. Personally I think something like Rust is helpful for large solo…

My personal opinion is that Rust is a bit too lengthy to keep everything in your head. For a solo program, I'd probably go with Python first, just because it tends to produce very short and yet readable source code.

And yes, I shifted the goal post a bit by assuming the team to be medium to large in size. If I assume a very small team like the initial Photoshop release with 2 people closely working together every day, then I think their communication will be so good that there aren't "many things that make working on team code dangerous" left. So in that case, I wouldn't expect much benefit from using Rust.

Re: I Hope Rust Does Not Oxidize Everything

#85

Post by fxtentacle »

goku12 wrote: post #79
fxtentacle wrote: post #42

Earlier quoted context omitted.

Sadly, Rust is only a "huge leap forward from C and C++" for some use-cases. Simple things like returning a const reference to a slot in an immutable array are easily 10x the amount of source code in Rust when compared to C. And all the standard libraries for embedded systems are C, so to get into embedded development, you definitely need to be good at reading C code. Rust is an additional skill, but if you only know…

> Rust also suffers from a serious "not invented here" problem, in my opinion. It's super easy to re-use C code in C++ or Java. It's significantly more difficult to re-use C in Rust ... It feels like a mischaracterization of Rust and I strongly disagree. Both the language and tooling are designed from the beginning for interop with C code. It isn't very hard to do if you have tried it. > ... unless you go unsafe and…

"It isn't very hard to do if you have tried it."

My attempt at OpenGL rendering with Rust turned out to be a lengthy journey of suffering through way too many layers of rust wrappers around unsafe C shared libraries. I especially hated that I constantly had to use casting helper functions to go from pre-defined OpenGL constants back to their associated integer values.

And I do think it's valid to accuse NIH syndrome if there is exactly 1 OpenGL API in C but there are 100+ Rust crates for various OpenGL wrappers.

Re: I Hope Rust Does Not Oxidize Everything

#86

Post by cangeroo »

simon_void wrote: post #59
oDot wrote: post #7

This is my current mental model for picking a language, considering just the language itself: - Backends: Gleam or other BEAM - Web frontend: Gleam - Mobile apps: Dart + Flutter - Specialized mobile apps: Swift and Kotlin - Blazing fast: Zig - Blazing fast and safest: Rust - Fast performance and iteration: Go Would love to hear additions and corrections. My only problem with this is I'm not a fan of Go's syntax and I…

- Backends: Kotlin (on JVM) - Web frontend: TypeScript (maybe Gleam in the future!?) - Fast performance and iteration if I want a binary: Kotlin (native compiled) - Blazingly fast and good for WASM: Rust - languages that I keep an eye on: Gleam, Zig, Odin - languages that I will never touch: C, C++ - languages that I think are quaint: OCamel, Lisp, Haskel - languages that I have used in the past and that are fine: Da…

I love Kotlin, but don't want to use IntelliJ, and they obviously have strong financial incentives against supporting other IDEs. Has anything changed in this regard?

I appreciate their work on native/wasm, and I think it's great if they could be financially rewarded/sponsored for that work. It's just unfortunate that it has to be in the shape of an IDE dependency.

Re: I Hope Rust Does Not Oxidize Everything

#87

Post by dgb23 »

Ragnarork wrote: post #71
dgb23 wrote: post #28

The post is a bit of a rant and all over the place. Async infecting everything, ugly syntax (who cares?), slow compile times etc. What stood out to me: > In other words, if compilation is fast, the tooling is easy. Andrew Kelley said something similar in a recent talk. Compiler performance seems to be the number one priority at the moment for Zig. The rationale seems to be: fast compilation leads to more productivity…

> ugly syntax (who cares?) Code is meant to be read, so a lot of people care actually. Sure it's not the only thing that contributes to the usefulness and appeal of a language, but reading code is still one of the two main things we do with it so it's quite important to nail the syntax right.

Yes, but readable and beautiful are two very different qualities.

Rust is a wolf in sheep’s clothing. It looks like C syntax but largely expression based like functional languages. It also has a lot of syntax.

It is readable with little effort for most because of it. But the trade off is ugliness.

Re: I Hope Rust Does Not Oxidize Everything

#89

Post by Const-me »

davidhyde wrote: post #24

My personal take on this subject is that Rust turns experts back into beginners and some devs react with hatred because of the fear this induces. For me it was the opposite. I was getting bored with my industry and thinking of a move to something else like management. Rust came along 6 yeas ago (for me) and threw me a lifeline. I love getting good at something that is hard, it’s just very satisfying. I do get why som…

You could have spend that time learning something which is actually useful and helps finding interesting jobs. For example, GPU programming or SIMD intrinsics.

What annoys me about rust is the complexity just for the sake of it, lots of pain for minimal gain compared to alternatives. If you need async/await you'll do better in modern .NET despite the GC, if you need the highest CPU performance you'll do better in C++ despite the unsafety.

Re: I Hope Rust Does Not Oxidize Everything

#90

Post by amenhotep »

I just cloned the Starship repo and cargo --release built it and it took six minutes and 30 seconds (which did feel interminable). The author says it takes him 15 minutes "for building just the main.rs", 10 minutes for "lib.rs" and an unspecified time for "everything else".

My CPU is from 2012. What on earth is he doing this on, a TI-83? Or am I missing some intricacy of whatever Gentoo is doing that would inherently inflate build times by an order of magnitude?

Post reply on HN