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

361–370 of 523 posts

Re: The Rust I wanted had no future

#361

Post by kmac_ »

divan wrote: post #261
sph wrote: post #6

Very interesting insight from Graydon, in hindsight I too would have loved something more towards ML than C++. I never liked the kitchen sink approach that I see first C++, now Rust moving towards, but I respect what Rust has managed to solidify into. It's a good language. That said, I still hate async with a passion, it makes the language more complex and not very elegant (i.e. function coloring). And now that I kno…

It's crazy that the programming community even accepted the concept of async/await as a sane one. Being sync or async is essentially a property of the attention of the caller, not of the action itself. Is "eating a donut" a sync or async action? If I'm focusing all my attention on it, essentially putting all tasks aside (after) - then it's a synchronous action. If I'm reading a book/watching a video/walking/etc, whil…

How about waiting until all or part of donut pack is eaten by multiple eaters? Jokes aside, async/await comes from easier handling of a callback code and automatic function splitting. Writing asynchronous donut eating in loops or with yielding of partial results is very easy to swallow with such syntactic sugar. The whole model is very easy to grasp and to work with. I'm not saying that's the best solution but it definitely works well.

Regarding stickiness of function colors - it never happens when async/await is used correctly (in the same principle as IO monad isn't sticky).

Re: The Rust I wanted had no future

#362

Post by avgcorrection »

xiphias2 wrote: post #142

,,I would have traded performance and expressivity away for simplicity'' ,,A lot of people in the Rust community think "zero cost abstraction" is a core promise of the language. I would never have pitched this and still, personally, don't think it's good'' If the language makes compromises in performance, it's not a real C++ competitor anymore. Some things are not about what people ,,like'', but that we need a langua…

I would have had much less interest in Rust as a peanut gallery participant if it didn’t have that goal of competing with C++. Not because I am a C++ or C programmer myself, but because it has been interesting to see if alternatives to such well-established languages can in fact be successful.

Think about it: we have dozens upon dozens of Hoare-esque “sacrifice some performance for ergonomics” languages out there. But what are you gonna do when you need performance that the language is too inflexible for? Hmm... perhaps write some of your app in C...?

If it weren’t for Rust and similar languages, we would never have a hope of moving on to more modern languages for those “can’t do this in my $mainlang due to performance” problems. How would yet another language that (according to Hoare):

> and I would have traded lots and lots of small constant performancee costs for simpler or more robust versions of many abstractions.

have helped with that? It wouldn’t! You would have still been stuck with having to bind to C, C++, assembly, or whatever else sufficiently “zero-cost abstraction” language.

Re: The Rust I wanted had no future

#363

Post by Paradigma11 »

inferiorhuman wrote: post #100
vsnf wrote: post #85

Earlier quoted context omitted.

Although all of those things are true, I think the main point being made is why choose Rust for that, instead of Go, .NET, etc, any of which offer everything you've outlined as being worth having, while having fewer of the downsides of Rust.

any of which offer everything you've outlined They don't, that's the "problem". Off the top of my head dependency management in Go is not best in class to put it charitably. .NET will tie you more closely to Windows. Sure, mono is a thing but you'll have more packages to choose from and fewer compatibility issues running .NET on Windows.

Web development for .NET is multiplatform for quite some years now. https://en.wikipedia.org/wiki/.NET

Mono is mostly only relevant if you need platform specific capabilities that wont be covered in .NET.

Re: The Rust I wanted had no future

#364

Post by jarjoura »

moth-fuzz wrote: post #239
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…

You can't evaluate a future in normal rust as there's no default executor, you need to pull in some library to even make blocking calls to async functions. IMO, this is even worse than function coloring.

It's the same in C++. The compiler and language design came first and then the library (aka executor) part comes next.

Rust has basically 2 executor libraries, tokio and async-std. It seems to me like tokio is solidifying as the executor of choice and it's only a matter of time before that design is baked into the std library.

Re: The Rust I wanted had no future

#365

Post by avgcorrection »

mjburgess wrote: post #230
kaba0 wrote: post #219

Earlier quoted context omitted.

Rust is a low-level programming language meant to control everything about the code’s execution. It will by almost definition, be complex. You seem to want contradictory things — if you don’t need that level of control just use any of the litany of high level languages with nice syntaxes. I don’t think we can eat this cake anytime.

The major innovation in this space is to make the compiler an interpreter which can evaluate the language at compile time (and emits code for runtime where it cannot). This makes brining in the "full power of dynamic languages" almost trivial and extremely performant. Delete half of rust's symbols, get rid of its macro system, rewrite it until lifetimes are inferred /or/ allocators are explicitly chosen, etc. etc. I…

> The major innovation in this space is to make the compiler an interpreter which can evaluate the language at compile time (and emits code for runtime where it cannot).

Show us an extant language that does this, then.

Partial Evaluation (automatic) was a very unsolved problem, last I looked.

Re: The Rust I wanted had no future

#366

Post by mananaysiempre »

sph wrote: post #6

Very interesting insight from Graydon, in hindsight I too would have loved something more towards ML than C++. I never liked the kitchen sink approach that I see first C++, now Rust moving towards, but I respect what Rust has managed to solidify into. It's a good language. That said, I still hate async with a passion, it makes the language more complex and not very elegant (i.e. function coloring). And now that I kno…

> [Async/await] feels so complicated and hacky, a mediocre very high level concept that someone managed to implement as a zero-cost abstraction.

I feel like I need to point out that Donald “Structured programming with GO TO statements” Knuth included an example of coroutines in the first volume of The art of computer programming, the first edition, dated 1968. In assembly language for an accumulator machine. With a box of scraps!^W^W^W^W^WThat is to say, that C and most other languages have made coroutines awkward and thus virtually unused in the past three decades or so does not mean they are particularly novel or high-level.

Granted, Knuth used coroutines in a simulation and not for I/O, so he did not need that much of a scheduler, but still.

Re: The Rust I wanted had no future

#367

Post by intelVISA »

pjmlp wrote: post #217
intelVISA wrote: post #132

Earlier quoted context omitted.

The fatal mistake here is using the STL...

The fatal mistake is not enabling bounds checking, which most STL implementations support.

-Wabsolutely-everything

I haven't written the Language of Kings in a while: does GCC -Wall truly enable all warnings yet?

Re: The Rust I wanted had no future

#369

Post by TremendousJudge »

vanderZwan wrote: post #305
TremendousJudge wrote: post #301

Earlier quoted context omitted.

Write unsafe code wrapped in layers of those advanced features that half the team didn't even know existed, and push it into production.

Am I the only one who works at a place where things don't make it into production unless at least one other person on the team fully understands the code during review?

Plenty of people don't, it's the most common thing. Maybe right now you are lucky enough to work in good contitions (that's great!), but are you sure it couldn't happen to you in 10 years? I think the standard tools we use in our profession should work in less than ideal conditions as well.

Re: The Rust I wanted had no future

#370

Post by divan »

paulddraper wrote: post #324
divan wrote: post #261

Earlier quoted context omitted.

It's crazy that the programming community even accepted the concept of async/await as a sane one. Being sync or async is essentially a property of the attention of the caller, not of the action itself. Is "eating a donut" a sync or async action? If I'm focusing all my attention on it, essentially putting all tasks aside (after) - then it's a synchronous action. If I'm reading a book/watching a video/walking/etc, whil…

IDK about donuts. But consider a network request. The vast majority of the time is not spent in the CPU. Right?

Doesn't matter, donut was just an abstraction.

s/eat a donut/make a network request/

Is "network request" a synchronous or asynchronous activity? It depends whether your code blocks and wait's until response (or timeout) or continues executing and handling it when it comes. It's property of the "attention" of the caller, not of activity itself.

Post reply on HN