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

161–170 of 195 posts

Re: I Hope Rust Does Not Oxidize Everything

#161

Post by steveklabnik »

yencabulator wrote: post #158
steveklabnik wrote: post #154

Earlier quoted context omitted.

The page linked for :: explains the turbofish. That said, you're right that it could use a row for the lifetime syntax.

If you know where to look, you will find it. If you don't, you don't. For someone new to Rust, I don't see why you'd expect them to expect to see a "path separator" between the function name and it's call in x.collect:: >(). A more likely path to discovery is via the Generics link (discovered from " syntax in context of const values, and that isn't actually very helpful for understanding.

So the thing is, the link provided is not really intended to be "teach me what syntax means." It is meant to provide a reference for various tokens. And it does that, because the turbofish isn't a single thing, it's a combination of two things.

If the goal of this page was "comprehensively explain Rust syntax to someone who doesn't know Rust," I would agree with you. But it's "produce a spec-like document for experts who want fine-grained details about the language."

Re: I Hope Rust Does Not Oxidize Everything

#162

Post by kosolam »

steveklabnik wrote: post #152
kosolam wrote: post #129

Earlier quoted context omitted.

Since C++ still evolves and changes, I guess greenfield C++ projects in the future can limit themselves to a subset of the newer improved language thereby C++ will continue living by that way as well.

The C++ community is talking about evolving in the following ways in this space: 1. contracts 2. profiles 3. successor languages 4. borrow checking The idea of a "subset of the language" is one that's often talked about, but there seems to be an explicit rejection of the idea of a subset, at least by several important committee members. It's not clear to me why this is the case.

I’m not sure why you’re getting downvoted. The committee members have clear interest to keep things as they are. However, from a practical perspective I suspect that “subset lang” will happen. One just needs a linter or compiler flags to do that.

Re: I Hope Rust Does Not Oxidize Everything

#163

Post by ryandrake »

kosolam wrote: post #162
steveklabnik wrote: post #152

Earlier quoted context omitted.

The C++ community is talking about evolving in the following ways in this space: 1. contracts 2. profiles 3. successor languages 4. borrow checking The idea of a "subset of the language" is one that's often talked about, but there seems to be an explicit rejection of the idea of a subset, at least by several important committee members. It's not clear to me why this is the case.

I’m not sure why you’re getting downvoted. The committee members have clear interest to keep things as they are. However, from a practical perspective I suspect that “subset lang” will happen. One just needs a linter or compiler flags to do that.

"Subset language" is already an option. The developer can choose a safe(r) subset of C++ to constrain themselves to. Many (most?) C++ shops already do this, and go to varying lengths to enforce that only their blessed subset is used. We don't really need a committee to create a new "subset language" to accomplish this.

Re: I Hope Rust Does Not Oxidize Everything

#164

Post by steveklabnik »

kosolam wrote: post #162
steveklabnik wrote: post #152

Earlier quoted context omitted.

The C++ community is talking about evolving in the following ways in this space: 1. contracts 2. profiles 3. successor languages 4. borrow checking The idea of a "subset of the language" is one that's often talked about, but there seems to be an explicit rejection of the idea of a subset, at least by several important committee members. It's not clear to me why this is the case.

I’m not sure why you’re getting downvoted. The committee members have clear interest to keep things as they are. However, from a practical perspective I suspect that “subset lang” will happen. One just needs a linter or compiler flags to do that.

It's all good, I have too much karma anyway.

The thing is, there's a difference between a true subset and "some flags that reject certain things." Because that creates a number of different sets that may relate to each other in a variety of ways, some subsets, some overlapping.

But beyond the specific definitions here, "profiles" is that sort of approach, so something like it will happen, probably. It seems to have a lot of support.

Re: I Hope Rust Does Not Oxidize Everything

#165

Post by [deleted] »

fileeditview wrote: post #121
sebstefan wrote: post #108

Earlier quoted context omitted.

"despite the GC" and "despite the unsafety" is really putting a lot of weight on that "despite" These are massive problems

That depends a lot on the domain of the code.. just saying they are massive problems is plain wrong. There is a huge percentage of applications that need not care about GC at all.

[deleted]

Re: I Hope Rust Does Not Oxidize Everything

#166

Post by saati »

amenhotep wrote: post #90

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

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

That's weird, cargo displays the current crates under compilation, not files as that's not the compilation unit in Rust, the author seems to be fibbing.

Re: I Hope Rust Does Not Oxidize Everything

#167

Post by ryandrake »

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…

Ugh, seen this pattern happen many times at smallish companies. The O.G. codebase was written by a single person. It did one or two things very well, with few bugs, had consistent filenames, variable names, APIs, formatting, and so on, it had a single, pure vision throughout the code, and didn't have all those problems that happen when multiple people reason differently about the same code.

Then, eventually, the company gets bigger and the product needs to grow beyond the capability of one person, so a team starts developing on the codebase. That's where the bugs start pouring in, where everything becomes less consistent, where different design patterns are used all over the place, and where the "single clear vision" gets cast aside. A lot of problems that get blamed on "technical debt" and "brittle code" are often just plain coordination and consistency problems that are happening because multiple people can't share a single consciousness.

Re: I Hope Rust Does Not Oxidize Everything

#168

Post by anonymoushn »

sebstefan wrote: post #151
anonymoushn wrote: post #128

Earlier quoted context omitted.

I don't think it's so cut and dry. For lots of usecases, using Rust involves writing everything from scratch, because the only libraries available pull in an opinionated async runtime and feel entitled to call the global allocator and various syscalls at times the user cannot control, and these components cannot be swapped out because of fundamental issues that prevent Rust libraries from being composable (unless the…

You're replying to me as if the comment was in a vacuum It's responding to: > complexity just for the sake of it, > lots of pain for minimal gain > 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 To this I respond, GC is such a massive problem (I guess you can fill in "for some categories of problems" but I t…

I don't think so? My reply is that if you can't afford to stall for a really long time, like dozens of frames at 60hz at least, then your choices are often to deal with unsafety in C++, to deal with the GC in .NET, or to write everything from scratch in Rust (including many things for which you would typically use libraries) because idiomatic Rust and the associated ecosystem won't solve your tail latency issues. The last option is not obviously more attractive than the approach of working really hard to not make garbage that Unity devs are usually forced into after years of development when they start testing on Switch.

Re: I Hope Rust Does Not Oxidize Everything

#169

Post by alexey-salmin »

majewsky wrote: post #100
steinuil wrote: post #82

Earlier quoted context omitted.

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

https://web.archive.org/web/20230713231438/http://bash.org/?...

   oh dear
   in ruby, symbols are represented with a prepended colon
   eg.   :flag
   so some guy tshirt that said ":sex"
   which everyone at railscamp knew meant "Sex symbol"
   he wore it until someone pointed out that to non-rubyists it said "Colon sex"

Re: I Hope Rust Does Not Oxidize Everything

#170

Post by pklausler »

bayindirh wrote: post #97
tormeh wrote: post #96

Earlier quoted context omitted.

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.

What new scientific applications are being written in Fortran?
Post reply on HN