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.

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 "<robot>"), 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)

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.

I find `<>` are visually distracting and take up far too visual space for their importance. `F[X]` is less arresting than `F<X>`, 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

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.