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

501–510 of 523 posts

Re: The Rust I wanted had no future

#501

Post by svieira »

astrange wrote: post #462
svieira wrote: post #429

Earlier quoted context omitted.

See also: https://www.tedinski.com/2018/11/06/concurrency-models.html which is the first article I've ever seen that says that `m:n`-style-green-threads are bad and good at the same time. TL;DR - he says that "doParallel" and "doConcurrently" are separate operations with distinct semantics that designers of programs must care about and that conflating the two (especially the common "doConcurrently-and-often-but-not-a…

A common thing about writing like this article is that it confidently declares futures/promises are good for parallelism, but this is wrong - they are flawed because they introduce priority inversions. To schedule tasks properly, you need to know who is waiting on them as early as possible. With a promise, you only know when you get to the "wait()" call, which is too late. The correct solution is called structured co…

Depends on if you're using Monix/Haskell style tasks (lazy, run when depended on) or JS-style promises (E Promise / C# Task / Java Future - run when instantiated, waiting is post-submission). Agreed completely though, structured concurrency is fantastic.

Re: The Rust I wanted had no future

#502

Post by pjmlp »

Ygg2 wrote: post #482
pjmlp wrote: post #471

Earlier quoted context omitted.

Likewise with C++ if the safety belt is buckled.

Heavy disagree. This is less giving a safety belt and more like saying we got airbags (that are deadly without seatbelts) and a DIY seat belt is somewhere in there too (it's in a box under the seat). Coming from Java the C++ stuff is jarringly unsafe.

Agree that Java is much better than using raw C++.

Still, if you want to contribute to OpenJDK internals, they will only be taking pull requests in C++, not Rust.

So better learn how to build those seatbelts and airbags, for all the projects we rely on, including Rust's own reference implementation, that aren't going to rewrite their code from C++ into something else.

Re: The Rust I wanted had no future

#503

Post by kmac_ »

divan wrote: post #481
mplanchard wrote: post #450

Earlier quoted context omitted.

I’m sorry but isn’t this exactly how async/await works from the perspective of the caller? If you want to wait until the donut is eaten you `.await`. If you don’t, you do other stuff and then join the future later. The fact that the executor can get other stuff done while you’re awaiting the donut consumption is largely invisible from the caller’s perspective.

That's only if you marked function with "async". Developer who writes code for "eating a donut" supposedly has better knowledge of how I'm supposed to eat it - synchonously or asynchronously. So if they didn't mark function as "async" I can't decide how I should eat it, it's decided for me.

You can eat it in the same thread. Some frameworks do that implicitly (even without await) . You can also control if it's consumed in particular thread or thread pool and decide which thread should continue. More, you can chain and/or parallelize it with other async and not-async functions without any effort. Additionally, you can handle errors and exceptions same as it's async and not-async function. Every good async/await framework offers that out of the box. More, some frameworks abstract executors and you can run the function remotely or even persist it with context. Of course you can achieve all that without async/await, but it makes that extremely easy.

Re: The Rust I wanted had no future

#504

Post by mjburgess »

laeri wrote: post #199
mjburgess wrote: post #110

Over the evolution of Rust, I've been increasingly despairing about many of the things Graydon here dislikes. I assumed the present "syntactical insanity" was, somehow, intended; it seems, really, it wasn't. I find Rust basically unusable -- at the level of abstraction I want to write code, basic definitions break line limits. Rust seems to be a repetition of C++'s mistake: a language which conspires you to pretend i…

Can you give an example where Rust is unusable? I have been getting into Rust recently and it feels very natural after getting accustomed to dealing with `Result` and `Option`. And what do you mean about "a langauge which conspires you to pretend it's another"?

I've just been browsing, eg., https://github.com/robot-rumble/logic/blob/master/lang-runne...

via https://github.com/RustPython/RustPython/blob/main/jit/src/l...

Have a look at real-world rust repos that are more than simple application code.

Personally, I feel like I'm being visually assaulted.

Re: The Rust I wanted had no future

#505

Post by lmm »

divan wrote: post #493
lmm wrote: post #456

Earlier quoted context omitted.

Does blocking I/O or not is very much a property of the function itself, as is "may finish up running on a different thread from the one it started on" (or, if you prefer, "needs to be run under a runtime that provides that capability"). Sending a letter and getting a reply is an inherently async action; you can stare at the mailbox all day but you probably don't want to. Waiting in line at the bank is inherently syn…

> you can stare at the mailbox all day but you probably don't want to Yet, it's up to me to decide, not to the mailbox.

You can always call blocking await on an async function. It's just usually a bad idea.

Re: The Rust I wanted had no future

#506

Post by alwaysbeconsing »

sph wrote: post #113
davedx wrote: post #61

Earlier quoted context omitted.

That being said... python had a BDFL and look how that turned out. I think designing and evolving any living programming language is just one of the hardest problems out there. Incredible blog post indeed, was awesome to read it.

A dictator might just have terrible ideas. His dislike for functional constructs didn't do Python any favour, but now that he's gone I see Python is adding the kitchen sink as well. I haven't kept up with the language since that pattern matching proposal.

> A dictator might just have terrible ideas.

If they're all terrible, then the language won't appeal to anyone and will die off naturally.

On the other hand if everyone gets to add their favorite terrible idea, there may still be enough non-terrible parts to appeal to enough people to keep momentum.

Re: The Rust I wanted had no future

#507

Post by laeri »

mjburgess wrote: post #504
laeri wrote: post #199

Earlier quoted context omitted.

Can you give an example where Rust is unusable? I have been getting into Rust recently and it feels very natural after getting accustomed to dealing with `Result` and `Option`. And what do you mean about "a langauge which conspires you to pretend it's another"?

I've just been browsing, eg., https://github.com/robot-rumble/logic/blob/master/lang-runne... via https://github.com/RustPython/RustPython/blob/main/jit/src/l... Have a look at real-world rust repos that are more than simple application code. Personally, I feel like I'm being visually assaulted.

What is it that gives you problems? The first example mainly uses a method chaining style of programming which might throw you off? Or maybe the use of lambdas? The first example seems quite readable to me. Also no heavy usage of generics or heavy type sorcery which would be more confusing. The second example also isn't visually assaulting. The struct definitions have macro annotations but doing this in any kind of language would lead to more verbose code. I think the main problem might be if you are familiar with functional languages which lean heavier on data flow and lambdas.

Re: The Rust I wanted had no future

#508

Post by FpUser »

bluGill wrote: post #174
zamalek wrote: post #164

Earlier quoted context omitted.

I don't understand the big issue with build times: I have always found that they are almost instant for incremental builds (assuming you use lld or mold).

In C++ a small change to a header can result in having to rebuild thousands of different files. Even if each file builds fast the total can be long. I have also benchmarked including a specific header (not using it, just including it) costs .5 seconds which adds up quick in those thousand files. Another benchmark found a specific boilerplate code construct added .1 seconds to the time to compile the file each time yo…

I do not think it has anything to do with C++. If you are using language that is strongly typed and compiled upfront and have defined some MYTYPE that is used in thousands of files all those need to be recompiled should you change the definition of MYTYPE.

Re: The Rust I wanted had no future

#509

Post by pushkine »

krupan wrote: post #167

The key challenge of rust for me: "Complex grammar. I've become somewhat infamous about wanting to keep the language LL(1) but the fact is that today one can't parse Rust very easily, much less pretty-print (thus auto-format) it, and this is an actual (and fairly frequent) source of problems. It's easier to work with than C++, but that's fairly faint praise. I lost almost every argument about this, from the angle bra…

Prettier Rust does a good job at improving readability

Re: The Rust I wanted had no future

#510

Post by mjburgess »

laeri wrote: post #507
mjburgess wrote: post #504

Earlier quoted context omitted.

I've just been browsing, eg., https://github.com/robot-rumble/logic/blob/master/lang-runne... via https://github.com/RustPython/RustPython/blob/main/jit/src/l... Have a look at real-world rust repos that are more than simple application code. Personally, I feel like I'm being visually assaulted.

What is it that gives you problems? The first example mainly uses a method chaining style of programming which might throw you off? Or maybe the use of lambdas? The first example seems quite readable to me. Also no heavy usage of generics or heavy type sorcery which would be more confusing. The second example also isn't visually assaulting. The struct definitions have macro annotations but doing this in any kind of l…

I've included just a light rephrasing below, of the first part of the first link -- but with a better design we could radically reduce it much more. Nevertheless, I find the below less of a visual assault,

    use rustpython_vm.. builtins.PyDictRef, py_compile, py_serde, scope.Scope
    use rustpython_vm.. InitParameter, Interpreter, PySettings, VirtualMachine
    use rustpython_vm.pyobject.. ItemProtocol, PyObjectRef, PyResult
    use logic.. ProgramError, ProgramResult

    setup_scope :: (vm: ref VirtualMachine) -> PyDictRef =
        let code = vm.new_code_object(run py_compile(
            file = "stdlib/rumblelib.py",
            module_name = "rumblelib"
        ))

        let attrs = vm.ctx.new_dict()

        let run : () -> PyResult[None] = fn
            return? attrs.set_item("__name__", vm.ctx.new_str(own ""), vm)
            return? vm.run_code_obj(code, Scope.with_builtins(PyNone, clone attrs, vm))

            let sys_modules: PyDictRef = 
                v unwrap vm.get_attribute(vm.sys_module.clone(), "modules")
                .downcast()
                .ok()
                .expect("sys.modules should be dict")

            return? sys_modules.set_item("rumblelib", clone attrs as object, vm)
            return ok(None)
        

        vm.unwrap_pyresult(run)
        return attrs


    py_to_serde(type T) :: 
    (py: ref PyObjectRef, vm: ref VirtualMachine) -> ProgramResult[T]
        let val = return? py_serde.serialize(vm, py, serde_json.value.Serializer)
        let out = return? serde_json.from_value(val)
        return ok(out)
Post reply on HN