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

91–100 of 195 posts

Re: I Hope Rust Does Not Oxidize Everything

#91

Post by fxtentacle »

pjc50 wrote: post #83
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…

This is not meant as a critique of you, but your comment includes a hint of what bothers me with some Rust evangelists. I would call it "slightly entitled over-optimism".

I have a C++ service running in production. It's been in production for 10-ish years with minimal updates. It'll probably keep running just fine for the next 10 years.

With that in mind, "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." just doesn't make much sense to me. If the status quo is fine, there's no "onus", there's no difficult decision to be made, there just isn't any rewrite. The anti-Rust people will probably be fine by doing ... nothing.

Re: I Hope Rust Does Not Oxidize Everything

#92

Post by K0nserv »

fxtentacle wrote: post #84
K0nserv wrote: post #63

Earlier quoted context omitted.

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

> My personal opinion is that Rust is a bit too lengthy to keep everything in your head

I'm curious what you mean by "lengthy" here. The reason I say Rust lets me keep fewer things in my head is because something like this in C:

    struct Bar {};
    
    struct Foo {
        struct Bar *bar;
    };
where it's no clear if Foo owns Bar or merely outlives it, becomes

    struct Bar;
    struct Foo {
        bar: &'b Bar,
    }
in Rust and I no longer have to keep this information in my head.

Re: I Hope Rust Does Not Oxidize Everything

#93

Post by goku12 »

fxtentacle wrote: post #85
goku12 wrote: post #79

Earlier quoted context omitted.

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

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

From this description, I can't figure out if you used FFI or a wrapper library. But it looks like you are complaining about both - which can't happen together. And the problems you mention seems very specific to the choices you made. I have faced similar problems with other code - something often solved by choosing a different library or approach. I don't see that affecting Rust's FFI story.

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

By definition, they didn't invent anything if the crates were wrappers. They were just using that exactly 1 OpenGL API - the thing that you were accusing them of not doing. And as for 100+ Rust crates, I don't think that should be a problem. Wrapper developers often try different API styles. It's just that crates.io makes them all very visible. In practice, just one crate (or a group of related crates) become popular enough to be the defacto standard in a segment.

Re: I Hope Rust Does Not Oxidize Everything

#94

Post by ReleaseCandidat »

K0nserv wrote: post #76
ReleaseCandidat wrote: post #73

Earlier quoted context omitted.

> How would you express the same semantics with a different syntax? This isn't the problem, the problem is "... and keep the syntax C++-like?".

Is it? I don't know if keeping Rust's syntax C++-like is a stated goal of the project, but okay sure we can add that caveat to my question. The big problem I see is that people will say "Lifetime annotations are ugly and noisy" and when pressed on the issue will eventually concede that they just want GC(which is not about syntax, but semantics)

> I don't know if keeping Rust's syntax C++-like is a stated goal of the project

They won't change the syntax, the whole discussion is hypothetically anyway. What I wanted to express is that most people want a C++-style syntax (of generics), even if they complain about Rust's syntax.

Re: I Hope Rust Does Not Oxidize Everything

#95

Post by neonsunset »

pornel wrote: post #78
dtquad wrote: post #48

I have seen a lot of criticism of async Rust. In C# most APIs expose both sync and async versions of the same methods. Why is that not more common in Rust? Sure some 3rd party C# libraries probably do some ugly sync to async conversion internally but most don't and use the .NET standard libraries sync/async versions of the same APIs.

Rust's async is in some places more difficult to use, because Rust is obsessed with avoiding allocations and dynamic dispatch. Languages like C# and JS allocate a new object for every Promise and every listener. Rust bends backwards to avoid that, and make inlined strongly typed state machines instead. It creates limitations where you wouldn't expect, e.g. recursive calls need special handling, and abstract interface…

Not every await and new task produces an allocation in C#: ValueTask only allocates a state machine box if it yields asynchronously, plain task objects are pooled for common values and state machine box itself can also be pooled for frequently called methods (is opt-in), for example socket.SendAsync does not allocate thanks to this.

This will change further as "Runtime Handled Tasks" implementation comes along which will replace Roslyn-generated explicit state-machine code with runtime-provided suspension mechanism which will only yield/suspend the execution at true yield points, with further improvements to how the captured state that needs to persist across them is stored.

Re: I Hope Rust Does Not Oxidize Everything

#96

Post by tormeh »

fxtentacle wrote: post #91
pjc50 wrote: post #83

Earlier quoted context omitted.

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…

This is not meant as a critique of you, but your comment includes a hint of what bothers me with some Rust evangelists. I would call it "slightly entitled over-optimism". I have a C++ service running in production. It's been in production for 10-ish years with minimal updates. It'll probably keep running just fine for the next 10 years. With that in mind, "the onus on anti-Rust people is now to demonstrate a better l…

I don't think anyone believes there will be no C++ codebases in the future - that's crazy talk. What could happen in a decade or two is that there'll be no _new_ C++ codebases. Popular languages are retired to legacy status from time to time, and C++ is completely outclassed by Rust.

Re: I Hope Rust Does Not Oxidize Everything

#97

Post by bayindirh »

tormeh wrote: post #96
fxtentacle wrote: post #91

Earlier quoted context omitted.

This is not meant as a critique of you, but your comment includes a hint of what bothers me with some Rust evangelists. I would call it "slightly entitled over-optimism". I have a C++ service running in production. It's been in production for 10-ish years with minimal updates. It'll probably keep running just fine for the next 10 years. With that in mind, "the onus on anti-Rust people is now to demonstrate a better l…

I don't think anyone believes there will be no C++ codebases in the future - that's crazy talk. What could happen in a decade or two is that there'll be no _new_ C++ codebases. Popular languages are retired to legacy status from time to time, and C++ is completely outclassed by Rust.

People love to think that C++ is only used in systems programming, the thing is C++ is used everywhere.

FORTRAN is being developed and improved, and new code, most notably in scientific domain, is still being written.

What Rust did to C++ is what clang did to GCC. Wake the giant up. Rust will go nowhere, but it's the same for C++.

Thinking that C++ will just fade to black is wishful thinking.

Re: I Hope Rust Does Not Oxidize Everything

#98

Post by dgb23 »

Timshel wrote: post #64
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…

Fast compilation is nice and I believe stuff like incremental compilation are essential. But at the end of the day I'll prefer slower compilation every time if it means advanced checking. And speaking of the zone I prefer writing Scala code for like 1h while fixing compiler errors and then you run and it just works TM vs Java where you'll waste your time tracking NPE ...

> But at the end of the day I'll prefer slower compilation every time if it means advanced checking.

I don't think that's a large issue in Rust. Type checking is quite fast in comparison to code generation.

Generics, traits, macros etc. seem to be the culprit. Turning complex language features into code and not runtime safety lead to these slow compile times.

Re: I Hope Rust Does Not Oxidize Everything

#99

Post by tormeh »

rob74 wrote: post #68
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 think it's not that much the specific parts as it is the combination of (sometimes obscure) symbols forming dense blocks of sigils that you have to carefully pick apart to understand what the code is doing. It's easier to reason about code if it uses words instead of symbols, and Rust seems to desperately want to avoid using actual words (I don't count "fn" as a word, and "pub" is a word, but for me it's somewhere…

I hate the unpronounceable sigils of languages like Haskell, but C-style abbreviations don't really bother me somehow. The abbreviations help you remember what the words are, at least, and for me this seems to be enough.

Re: I Hope Rust Does Not Oxidize Everything

#100

Post by majewsky »

steinuil wrote: post #82
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…

> colon-colons

I prefer "quad-dot". Rolls off the tongue better. :)

Post reply on HN