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

51–60 of 523 posts

Re: The Rust I wanted had no future

#51

Post by moonchrome »

PhilipRoman wrote: post #41

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

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

As someone who only used Rust casually - understanding object lifetimes and knowing how to encode this in Rust type system is not the same thing. Not to mention that Rust can't statically prove some things that are valid (eg. cyclic references).

Re: The Rust I wanted had no future

#52

Post by pm215 »

sanxiyn wrote: post #44
TowerTall wrote: post #36

Earlier quoted context omitted.

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

I suspect an informal grouping (i.e. more long-standing/senior contributors with default control over some parts of the codebase and operating by informal consensus between themselves) is probably at least as common (maybe more so) than an officially named committee with rules of procedure.

Re: The Rust I wanted had no future

#53

Post by shoulderfake »

jstx1 wrote: post #2

A bunch of things you don't like about Rust? Turns out that the person who originally created the language doesn't like them either. I know that the main point is about governance and how having a BDFL would have led to a completely different language but I really would have preferred the Graydon-BDFL-Rust to what we have today. Very interesting article, worth a read.

[dead]

Re: The Rust I wanted had no future

#54

Post by zozbot234 »

nyanpasu64 wrote: post #47
wuiheerfoj wrote: post #16

Earlier quoted context omitted.

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

You can use universal function call syntax in Rust: as Trait>::trait_fn(self_arg, fn_arg1, fn_arg2);

Re: The Rust I wanted had no future

#55

Post by glandium »

nyanpasu64 wrote: post #47
wuiheerfoj wrote: post #16

Earlier quoted context omitted.

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

There's worse. When your trait adds function foo and your code does obj.foo(), if the underlying type later adds a foo method, compilation breaks. This is very common with traits that usefully add useful methods that are missing in libstd... which break when said method is finally added there.

Re: The Rust I wanted had no future

#56

Post by ZephyrBlu »

This is an interesting read, because I read it as "I would have done all these things which would have kept the language more pure to my vision but less accessible".

I also found this bit interesting: "It's easier to work with than C++, but that's fairly faint praise".

I see this kind of thing in my own personal projects all the time. I'm thinking "oh it would be really cool if I built X" when in reality most of the time users just want really simple stuff.

Being easier to work in than C++ might be faint praise, but it's probably the biggest draw of Rust for me. I don't want to touch C++ with a 10ft pole, but I love using Rust.

Re: The Rust I wanted had no future

#57

Post by mike_hearn »

ohgodplsno wrote: post #48
sph wrote: post #22

Earlier quoted context omitted.

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

Async doesn't solve that problem. What you're asking for is some sort of expression in the type system of expected performance, but there's no tech that can do this. Consider that modern NVMe SSDs can do disk reads faster than many calculations over the content of what was just read. A function that changes its algorithm to have worse time complexity won't be marked as async but could break your app, adding a single disk read would require marking as async but probably won't break your app (especially if it's in a non-hot path), adding 10,000 more reads where previously you had one doesn't require changing your async annotation but might break your app, etc.

So the whole sync/async distinction doesn't really make much sense outside the context of single threaded UI toolkits, where indeed you have to read the docs anyway because doing some very CPU intensive work on the UI thread will block it even if no "blocking" APIs are ever invoked (and what is or is not blocking is somewhat arbitrary anyway in many cases).

Re: The Rust I wanted had no future

#58

Post by flohofwoe »

nsajko wrote: post #5
skellington wrote: post #4

Earlier quoted context omitted.

Committees tend to design less beautiful things. Look at modern c++ too. What a mess. Everyone in the committee has to jam in their favorite feature, much of which is sugar.

Modern C++ is actually going relatively OK? You may be thinking of the old, pre-C++11 C++?

C++11 is exactly where the mess started ;) C++ releases got more frequent since then, but at the same time, more half-baked features slip in that haven't been battle tested in the real world before, or need refinement over the next decade worth of releases (if they can be fixed at all).

Re: The Rust I wanted had no future

#59

Post by nsajko »

Sankozi wrote: post #28
nsajko wrote: post #5

Earlier quoted context omitted.

Modern C++ is actually going relatively OK? You may be thinking of the old, pre-C++11 C++?

If you have a mess and add something to it, you still have a mess, probably a bigger one. To clean the mess you need to remove something (which is really hard in a programming language) not to add something. Selecting and enforcing usage of a subset of C++ is a way to deal with that mess which companies frequently use.

Everything is a mess. The universe is a mess. That doesn't make perfectionism a good thing.

Besides, the C++ committee does, in fact, remove stuff from the language to clean the mess, just not without due care.

Re: The Rust I wanted had no future

#60

Post by truculent »

It sounds like the Rust He Wanted has a lot of thematic similarities to Elm. Interestingly, Elm has a BDFL, and a development process that reflects that. And he’s right - there are a lot of people who really don’t like that!

Overall, a really interesting article. Though I like today’s Rust, I do think I would prefer the trade-offs made by the alt-Rust outlined here.

Perhaps it’s just my own personal preference, but I think there is a strong bias in users towards what they are already familiar with, and it’s hard to break away from those without a BDFl or similar position of authority who can impose their vision.

Post reply on HN