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

511–520 of 523 posts

Re: The Rust I wanted had no future

#511

Post by laeri »

mjburgess wrote: post #510
laeri wrote: post #507

Earlier quoted context omitted.

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…

The `return?` idea of yours is nice as the `?` operator at the end might be overlooked but is a significant control flow operation.

Some of your potential syntax changes seem less readable but they might look nicer to you such as changing `attrs.clone().into_object()` into `clone attrs as object`. You probably come from a python background I would assume but the rust version is easier to parse and understand but maybe to you not visually appealing.

Having an explicit return argument I could understand. I found this weird in the beginning but this is something I got accustomed.

Not sure why square brackets should be favored instead of angle brackets. The imports in the Rust version are also very explicit and fine I think.

Replacing `()` with `None` seems silly, same with replacing `Ok` with `ok`.

Maybe the `py_to_serde` arguments of the function definition spanning 4 lines could be considered unastethically pleasing. This is something I noticed quite a lot with Rust code. Fmt also seems to break to multiple lines quite fastly when writing function or method definitions.

Re: The Rust I wanted had no future

#512

Post by remram »

dataflow wrote: post #423
remram wrote: post #409

Earlier quoted context omitted.

> Tracking moves is fundamental here. I mean, arguably. If it is fundamental for your hypothetical use case, then sure, but this is not required for a lot of use cases, like smart pointers.

> this is not required for a lot of use cases, like smart pointers. Nobody claimed otherwise. The question was what things Rust can't do, not what it can do.

Yeah, that's fair. You can't do it, not even using horrible hacks.

Re: The Rust I wanted had no future

#513

Post by pjmlp »

Ygg2 wrote: post #484
pjmlp wrote: post #470

Earlier quoted context omitted.

It proves that there is a way to diagnose this type of mistake, that is what matters. Unlike C, which the only way to be safe is not to touch it at all. As for performance, ISO doesn't implement compilers, there are many ways to improve performance while keeping the semantics in line with the standard. If the compiler vendors decide to focus elsewhere is another matter, a bit like there are languages as complex as Ru…

Still, catching errors at runtime is subpar compared to catching them at compile time. Even your dynamic example won't tell me calling pop/push x/y times respectively will fail if x > y. I have to trigger it somehow.

Since when does Rust support dependent typing?

Re: The Rust I wanted had no future

#514

Post by mjburgess »

laeri wrote: post #511
mjburgess wrote: post #510

Earlier quoted context omitted.

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…

The `return?` idea of yours is nice as the `?` operator at the end might be overlooked but is a significant control flow operation. Some of your potential syntax changes seem less readable but they might look nicer to you such as changing `attrs.clone().into_object()` into `clone attrs as object`. You probably come from a python background I would assume but the rust version is easier to parse and understand but mayb…

I find `` are visually distracting and take up far too visual space for their importance. `F[X]` is less arresting than `F`, the thin vertical lines melt-away easier.

I replaced () with `None` (& with ref, ! with run, etc.) because I want code to read like english (ie., literate) all other things being equal. I dont find `()` "pays the cost" of illegibility by syntactical convenience.

Changing "operator-like methods" to operator words would have a radical impact on the parsing precedence and "overall look" of the lang. ... so `clone ...` would be more readable if those changes were made. The advantage of many keyword primitives is that you dont keep reusing the same syntax for everything... syntax is there to support expression. I think more is better.

`Ok()` to `ok()` was more a broad notational philosophy of basic type constructors being unobtrusive.

Scala has gone from C-like (v2) to python-like (v3) syntaxes --- and I think the ML-ish whitespace, python-ish "beat poetry" approach is mostly just better.

I buy some arguments that symbolic redundancy can help (ie., both indent and use symbols)... but Rust's syntax philosophy is clearly to "keep adding symbols", and I dislike it.

C uses symbols, but I do think C is quite beautiful mostly -- because it's so simple. Rust is creaking under the weight of its size and symbolic choices

Re: The Rust I wanted had no future

#515

Post by tech2 »

mhd wrote: post #20

Ah, Sather gets mentioned. That's a name I haven't heard in a long time. I remember looking at it during the latter half of the 90s when I was searching for the perfect OO language... https://www1.icsi.berkeley.edu/~sather/

Sather was something I was first exposed to at university in the mid 90s, and I still have a lot of respect for its looping mechanism. Code inclusion in classes rather than inheritance was also pretty cool. Pre/post conditions, invariants. I miss a lot of it.

I recently revisited it for Advent of Code (where part of the challenge was getting the compiler itself to even build with even semi-modern tooling), and a lot of the above features still have value.

Re: The Rust I wanted had no future

#516

Post by laeri »

mjburgess wrote: post #514
laeri wrote: post #511

Earlier quoted context omitted.

The `return?` idea of yours is nice as the `?` operator at the end might be overlooked but is a significant control flow operation. Some of your potential syntax changes seem less readable but they might look nicer to you such as changing `attrs.clone().into_object()` into `clone attrs as object`. You probably come from a python background I would assume but the rust version is easier to parse and understand but mayb…

I find ` ` are visually distracting and take up far too visual space for their importance. `F[X]` is less arresting than `F `, the thin vertical lines melt-away easier. I replaced () with `None` (& with ref, ! with run, etc.) because I want code to read like english (ie., literate) all other things being equal . I dont find `()` "pays the cost" of illegibility by syntactical convenience. Changing "operator-like metho…

I would prefer not wanting to read code like english. You most certainly don't want o replace common math operators with plus/minus `c = a + b` is preferrable over `c is a plus b`. The second one is harder to parse and understand.

When writing code you are pattern matching and certain special symbols such as `()` over `None` and `attrs.clone().into_object()` over `clone attrs as object` are just faster to detect at an instance.

Using more english prose becomes a word salad that is harder to parse than using special symbols which convey meaning. Certainly more familiarity with a programming language and it's syntax elements will help you your pattern matching mechanism and allows you to understand code faster. In my opinion Smalltalk gets it quite well in this regard.

I also would rather prefer lisp language syntax, or apl.

Re: The Rust I wanted had no future

#518

Post by BatmanAoD »

menaerus wrote: post #479
jarjoura wrote: post #364

Earlier quoted context omitted.

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.

In C++ there is a default executor that is part of the standard library and has been so since C++11, e.g. no external library is needed - std::async. std::async is mostly "good enough" for ordinary cases where you only want to fire-and-forget and have no control over the underlying dispatching and scheduling algorithms. If you want something tweaked towards your use-case, and hence actual high-performance executor li…

That's...not precisely true. The C++ standard doesn't specify how std::async works, and for a while GCC just ran the operation sequentially, and later both GCC and Clang launched new OS threads by default. https://stackoverflow.com/q/10059239/1858225

Re: The Rust I wanted had no future

#519

Post by johnnyanmac »

sph wrote: post #38
creatonez wrote: post #35

Earlier quoted context omitted.

Thing is, it's a function coloring that mostly doesn't impede you by making certain operations impossible without massive refactoring. Regardless of an extra method call needed, it gets rid of the "you can only call a red function from within another red function" barrier by allowing you to do it, as long as you specify how (execute inside this thread, or delegate to a worker thread). This makes most of the issues as…

Fair enough. It's not a deal-breaker kind of coloring, my issue is mostly conceptual. It's simply not elegant as a construct, but perhaps it doesn't have to be.

My experience with asynchronous programming is brief, but it taught me that you will never have elegant parallelism. It's a completely different problemset, you need a completely different solution to handle it. But the ideal API wants to treat the problems as one in the same.

So the two camps I've seen on solving it is either

a) blackbox it and set some rules for implementers, inevitably leaving to some hidden and very nasty bugs on the user end or bottlnecks for advanced users, or

b) give implementers the full tools to setup, launch, and synchronize themselves, which may end up being slower than a single threaded solution if the user isn't adept already with parallel programming.

You inevitably always have bits of a) creep in, even for the most explicit solutions

Re: The Rust I wanted had no future

#520

Post by johnnyanmac »

divan wrote: post #405
pmoleri wrote: post #377

Earlier quoted context omitted.

> How does "func EatADonut() async {}" aka "eating a donut is an inherently async action" even make sense to people? Of course it does, read it as "beware, something blocking down the road". If you can EatADonout without blocking, please do, but want it or not that's a different implementation, one that doesn't block and the signature it's telling you so. We're so used to sync and having hidden blocking operations. I…

> want it or not that's a different implementation, Implementation is the same. In both cases it's the same set of CPU instructions, but async/await languages create artifical division, forcing developer to think othervise. So, let me explian my reasoning. Code starts with a developer's mental model of a problem and behavior of the system and then translating it into the code. The more straightforward this translatio…

>In both cases it's the same set of CPU instructions

It's actually a very different set of CPU instructions. the function EatADonut is the same set, but "async" means the kernel needs to take time out of its execution to do some action as small as accessing an open thread, or as large as "gain access into a completely different piece of hardware" before putting that set of instructions onto that different thread. Not the program, the actual scheduling process between your program and the OS you are executing on. Then it needs a way to to get that result and sync it back onto whatever thread spawned it and access the result.

It is in fact a huge action, so marking it with Async is basically a very explicit warning.

>Which is cognitively expensive for no added benefit.

On the contrary, I can't even begin to imagine the amount of compiler optimizations it saves on as well to have that be explicit in code. I'm sure Go has to do all that on the fly while a colored language gets to allocate all those potential processes before the program runs. It's only no added benefit if you dont care about performance. But to be frank, you probably don't need more than a single thread if your problem isn't bounded by perormance. Parallel programming is all about getting something done faster after all.

Post reply on HN