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

71–80 of 523 posts

Re: The Rust I wanted had no future

#71

Post by Gigachad »

inferiorhuman wrote: post #68
tick_tock_tick wrote: post #31

Earlier quoted context omitted.

> it may become less attractive for other use cases. For instance, I find it highly questionable to develop a web app in Rust... I mean who'd want to and why bother trying to support that use case? Basically none of Rust's value proposition exists for a web app while nearly every single one of the downsides do.

Hard disagree. Rust brings a lot to the table for a web app. Compiled vs interpreted makes it easier to catch (syntax) errors beforehand. You can even go as far as compiled templates. Mapping JSON (or whatever) to strongly typed objects is great . Dependency management is best in class. I rather like diesel.rs (although it is very much an acquired taste) especially if you treat it like a safe query builder rather tha…

Arguably TypeScript is pretty close to as safe while being less work.

Re: The Rust I wanted had no future

#73

Post by Vespasian »

tick_tock_tick wrote: post #31
rob74 wrote: post #15

Earlier quoted context omitted.

I think this quote also applies more generally: > It's easier to work with than C++, but that's fairly faint praise. So, while Rust positions itself as a C++ alternative with all the complexities that C++ developers love, it may become less attractive for other use cases. For instance, I find it highly questionable to develop a web app in Rust...

> it may become less attractive for other use cases. For instance, I find it highly questionable to develop a web app in Rust... I mean who'd want to and why bother trying to support that use case? Basically none of Rust's value proposition exists for a web app while nearly every single one of the downsides do.

I am doing that for a just for fun side project and it was an interesting experience.

The pieces and features i wanted exist but tying them together was not always straight forward.

From the top of my head I used:

- actix-web

- tracing (logging)

- sea-orm

- config from yaml files and a custom implementation to allow profiles.

- utoipa (for openapi and swagger ui)

- thiserror

In a professional context I would not have used Rust for this project, but it was quite fun to explore it's possibilities and rich crate ecosystem.

Re: The Rust I wanted had no future

#74

Post by truculent »

ZephyrBlu wrote: post #56

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…

I'm not sure it would be less accessible. I think the trade-offs would lean towards simplicity, and perhaps less familiarity. But with the right mental models, I think this could enhance accessibility (less "magic", or strange edge-cases). For example, see the discussion on not minding if users have to write something in a more verbose way if it preserves the language's principles. This type of trade-off is something that lowers the barrier to entry for beginners, who don't mind writing things out the long way.

Re: The Rust I wanted had no future

#75

Post by hayley-patton »

mike_hearn wrote: post #57
ohgodplsno wrote: post #48

Earlier quoted context omitted.

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…

There are type systems which can track complexity (e.g. http://gallium.inria.fr/~fpottier/slides/fpottier-2011-01-jf...) but that's still different to performance; async/sync tells us things like "touches disk" or "touches network" but not "O(2^n) might take a really long time".

Alternately, an effect system can communicate "touches disk", can make functions which are polymorphic to effects (e.g. map touches the disk if the mapping function touches the disk), and can distinguish different effects, unlike async/sync being anything-or-nothing. IMO async is more of an implementation detail (as "may suspend/yield" is not a very precise or interesting effect), whereas effects would communicate the properties that ohgodplsno wants to know.

Re: The Rust I wanted had no future

#76

Post by josephg »

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…

Its certainly possible with compiler magic. Zig does exactly that - where functions can be colorless and they work slightly differently in async and syncronous contexts, doing the obvious thing in both cases. I'm not sure how well it works in practice (I haven't spent enough time with zig to know). I'd worry that bugs would creep in to whichever variant of the function you aren't exercising.

Its a lovely design though.

https://kristoff.it/blog/zig-colorblind-async-await/

Re: The Rust I wanted had no future

#77

Post by Aardwolf »

> Tail calls. I actually wanted them! I think they're great. And I got argued into not having them because the project in general got argued into the position of "compete to win with C++ on performance" and so I wound up writing a sad post rejecting them

I don't understand the subtleties here: Is tail calls an optimization the compiler can do irrespective of the language? Or is there something that prevents this and requires the compiler to use stack here? Is there any visible effect to the programmer from supporting tail call or not, other than performance and stack depth?

How does not supporting them compete with C++ performance?

Re: The Rust I wanted had no future

#78

Post by dan-robertson »

elcritch wrote: post #3
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.

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…

I often felt that being canonical was a pretty big advantage of traits. For example if you use first-class modules then every time you want a sort or a binary search tree you need to specify the choice of comparison operator for the elements. And a data structure for a search tree must somehow encode this in the type system so eg you can’t merge two trees with the same key type but different comparison functions. The most obvious way to implement this causes problems for other cases like writing functions generic in the types of keys/values (else you get extremely verbose code).

Canonical instances goes against modularity but something like modular implicits for ML-family languages could improve the terse was a lot to something closer to Haskell levels. You still miss out on the other advantage rust has: the dot operator is great because it allows identifiers to contain less context (they don’t need to have long global names or be hidden away in some tree of modules: you can have .map mean different things for different types) and gives a massive hint to autocomplete for which things to suggest (I don’t know how you even signal to autocomplete in a language like ML that you would like a function to operate on the following value so please suggest things with the right type).

Re: The Rust I wanted had no future

#79

Post by inferiorhuman »

Gigachad wrote: post #71
inferiorhuman wrote: post #68

Earlier quoted context omitted.

Hard disagree. Rust brings a lot to the table for a web app. Compiled vs interpreted makes it easier to catch (syntax) errors beforehand. You can even go as far as compiled templates. Mapping JSON (or whatever) to strongly typed objects is great . Dependency management is best in class. I rather like diesel.rs (although it is very much an acquired taste) especially if you treat it like a safe query builder rather tha…

Arguably TypeScript is pretty close to as safe while being less work.

Perhaps. But TS is still Javascript under the hood which means implementation details leak and they smell awful. If they didn't it'd come down to a preference for compiled vs interpreted.

The number one syntactical beef I've is operators. e.g. == vs ===, ""+number.

Post reply on HN