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

The Rust I wanted had no future

graydon2.dreamwidth.org

Post reply on HN
Print view View original

41–50 of 523 posts

Re: The Rust I wanted had no future

#41

Post by PhilipRoman »

Haven't followed Rust too much, but I'm always surprised when I hear that Rust is too difficult or not ergonomic. As I understand it is meant to be a systems level language; something you'd use to write kernels, TCP stacks, browsers and ssh daemons.

Anyone writing these things today in C or C++ already understands object lifetimes and Rust just adds a static checker for them.

In such projects churning out lines of code is not the bottleneck, ease of development should not be prioritized over long term maintainability.

Why on earth would you try to rewrite python CRUD apps in Rust?

Re: The Rust I wanted had no future

#44

Post by sanxiyn »

TowerTall wrote: post #36
Fiahil wrote: post #25

Earlier quoted context omitted.

Benevolent dictator for life. "Benevolent dictator for life (BDFL) is a title given to a small number of open-source software development leaders, typically project founders who retain the final say in disputes or arguments within the community. The phrase originated in 1995 with reference to Guido van Rossum, creator of the Python programming language."

Interesting. Isn't a BDFL needed in Open Source projects (not talking specific about Rust, but Open Source in general)? I work in a commercial software company. We have a CTO and he retain the final say in disputes or arguments. He also steers the global technical direction we take the software and has the final say, but he can get fired. Is that the main difference between a CTO and a BDFL? What alternatives are the…

The usual alternative is a committee, see for example Apache Software Foundation's Project Management Committee Guide: https://www.apache.org/dev/pmc.html

Re: The Rust I wanted had no future

#45

Post by zozbot234 »

TowerTall wrote: post #36
Fiahil wrote: post #25

Earlier quoted context omitted.

Benevolent dictator for life. "Benevolent dictator for life (BDFL) is a title given to a small number of open-source software development leaders, typically project founders who retain the final say in disputes or arguments within the community. The phrase originated in 1995 with reference to Guido van Rossum, creator of the Python programming language."

Interesting. Isn't a BDFL needed in Open Source projects (not talking specific about Rust, but Open Source in general)? I work in a commercial software company. We have a CTO and he retain the final say in disputes or arguments. He also steers the global technical direction we take the software and has the final say, but he can get fired. Is that the main difference between a CTO and a BDFL? What alternatives are the…

The main difference between a CTO and a BDFL is that if you disagree with a BDFL, you can just fork the project under a new name. This right to fork is key to making FLOSS development work. If you disagree with a CTO, there isn't much that you can do besides buying up the whole company (see Elon Musk and TWTR as an example).

Re: The Rust I wanted had no future

#46

Post by emanuele232 »

TowerTall wrote: post #36
Fiahil wrote: post #25

Earlier quoted context omitted.

Benevolent dictator for life. "Benevolent dictator for life (BDFL) is a title given to a small number of open-source software development leaders, typically project founders who retain the final say in disputes or arguments within the community. The phrase originated in 1995 with reference to Guido van Rossum, creator of the Python programming language."

Interesting. Isn't a BDFL needed in Open Source projects (not talking specific about Rust, but Open Source in general)? I work in a commercial software company. We have a CTO and he retain the final say in disputes or arguments. He also steers the global technical direction we take the software and has the final say, but he can get fired. Is that the main difference between a CTO and a BDFL? What alternatives are the…

The most inefficient decision-making structure known, democracy and voting?

Re: The Rust I wanted had no future

#47

Post by nyanpasu64 »

wuiheerfoj wrote: post #16
elcritch wrote: post #3

Earlier quoted context omitted.

One highlight from the article: > Traits. I generally don't like traits / typeclasses. To my eyes they're too type-directed, too global, too much like programming and debugging a distributed set of invisible inference rules, and produce too much coupling between libraries in terms of what is or isn't allowed to maintain coherence. Very much this! > I wanted (and got part way into building) a first class module system…

May I ask what you don’t like about traits (and perhaps insight on what the author meant)? Being a relative rust noob compared to other languages, I always felt traits were a super power when compared to eg interfaces in Java/C++ and flexible but with useful constraints compared to the structural typing nature of Typescript interfaces

Importing a trait into scope can silently materialize methods on other types, with no syntax at the method call site pointing to which import statement created the methods, requiring you to ask the compiler/IDE. This can also mean that removing a use statement with no references to the type being used in the entire rest of the source file, can make code suddenly stop compiling. I've worked around this by strictly confining "specialized" traits (like std::io::Write or std::fmt::Write, why are there two Writes?!) to the beginning of a single function, but I'm lazy and put "general" traits like std::borrow::Borrow and std::str::FromStr at the top of my file.

Which types grow new trait methods is dependent on trait implementations, which can be generic and apply to an unbounded number of types, based on complex matching rules, and figuring out requires reading every impl of that trait to see if any match a given type, or asking the compiler/IDE. I want to explore languages which explicitly select a trait implementation at the call site (like a Heap type which uses int_greater::cmp() to implement a min/max heap), or naming the trait (but not picking an impl) at the trait method call site (like Write::write_all(stream, "hello world") or (stream as Write).write_all("hello world")). I think Zig takes a similar direction.

Re: The Rust I wanted had no future

#48

Post by ohgodplsno »

sph wrote: post #22
pornel wrote: post #18

Earlier quoted context omitted.

Function coloring article conflated two things: one was legitimate limitation of JS unable to wait for async result from sync call, and the other was just author's opinion how the syntax should look like. Rust's async doesn't have the limitation author described – you can spawn and block both (Tokio has some limits there, but that's Tokyo's choice, not language limitation), making "color" largely irrelevant. The seco…

I disagree. You can call an async function in Rust from a regular one, that's true, but the returned value still needs to be passed through an executor to be useful. Async without function coloring means being able to call `async fn add(a, b: usize) -> usize` from anywhere and having an usize back, whether you're calling from a regular or async function. If you need slightly different logic because of async, you got…

Not knowing about function coloring is a stupid dream and has terrible implications on the performance of your code, which is infinitely more important than you losing 2 minutes having to figure out that you really want to `runBlocking { callThatBlocksForADamnLongTime() }`.

The insight that function coloring gives you is terribly important. Roman Elizarov (of Jetbrains, author of Kotlin and lead on Kotlin Coroutines) agrees too: https://elizarov.medium.com/how-do-you-color-your-functions-...

async functions without coloring means that the only warning you'll ever get that `calculate2Plus2()` actually ends up running a distributed BigQuery and writing the end result to disk, printing it to stdout() and parsing that result to give it back to you is... hopefully, documentation is up to date and you read it?

Async function coloring is not a problem. Async function coloring is a solution to "software developers are awful and will do awful things without any warning". If `calculate2Plus2` did not exhibit the write to disk behaviour in v1.0.0, but bumping to v1.0.1 does, I'd really want a warning that it does at least, and ideally a compiler error. The proper solution to function coloring is to have a pleasant API to interop between both worlds so that, at worst it's just a dozen characters more to say "yep, I really want to block here".

Re: The Rust I wanted had no future

#49

Post by kaba0 »

sph wrote: post #22
pornel wrote: post #18

Earlier quoted context omitted.

Function coloring article conflated two things: one was legitimate limitation of JS unable to wait for async result from sync call, and the other was just author's opinion how the syntax should look like. Rust's async doesn't have the limitation author described – you can spawn and block both (Tokio has some limits there, but that's Tokyo's choice, not language limitation), making "color" largely irrelevant. The seco…

I disagree. You can call an async function in Rust from a regular one, that's true, but the returned value still needs to be passed through an executor to be useful. Async without function coloring means being able to call `async fn add(a, b: usize) -> usize` from anywhere and having an usize back, whether you're calling from a regular or async function. If you need slightly different logic because of async, you got…

Virtual threads (like java’s loom, erlang’s and goroutines) are arguably that.

In case of java there really is no compiler magic even, “just” runtime magic.

Re: The Rust I wanted had no future

#50

Post by tijsvd »

LeanderK wrote: post #39

Can someone comment on "Library-defined containers, iteration and smart pointers"? I have no rust experience so far. Magic compiler support for such primitives is something I usually very much, really strongly dislike, it was always my experience that it is the wrong point of abstraction because it just reduces the design state so much. But then you need good support for inlining the relevant parts of the language, w…

Everything that's visible to the compiler is subject to automatic inlining. That is all code in the current crate (compilation unit), all concrete instantiations of generics (regardless where defined), and all functions marked inline (regardless which crate).

Stdlib containers are all in the generics category.

Post reply on HN