4 ms·

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,

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 it's another. There are now nearly as many Rusts as C++s. If I return to any domains where Rust would be relevant, I'd probably now opt for Zig or equivalent.

laeri 3y ago
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"?
- mjburgess 3y ago
  I've just been browsing, eg., https://github.com/robot-rumble/logic/blob/master/lang-runners/python/src/main.rs https://github.com/robot-rumble/logic/blob/master/lang-runne... via https://github.com/RustPython/RustPython/blob/main/jit/src/lib.rs 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.
  - laeri 3y ago
    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.
    - mjburgess 3y ago
      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)
      - laeri 3y ago
        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.
kaba0 3y ago
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.
- mjburgess 3y ago
  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 don't want to feel visually assaulted when writing the type signature of the sort of function common in a dynamic language. Here `mypy` is also treasonously guilty. Consider, eg., zigs "function which returns a type at compile-time" is an example of where blindingly-obvious syntax retains its blindingly-obviousness because of compile-time eval... ie., we dont need a "second syntax" to program the compiler. This "two syntaxes, one for the runtime and one for the compiler" approach -- has swamped Rust as it aims for greater expressiveness. Not least, because it has a third syntax: one for unsafe.
  - kaba0 3y ago
    You quickly gets into the undecidable category once you to down that road, which might be fine if you either don’t care about safety, or have runtime checks for that, but none of those were an option for rust (or at least an option that would have made it remotely interesting).
    - zozbot234 3y ago
      It's undecidable in the general case, but it becomes doable in non-Turing-complete languages that are still expressive enough to be useful for many practical cases. (These languages can express unrestricted recursion as an I/O-like effect that's only available outside the language proper, as part of compiling to a binary.)

laeri 3y ago

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"?

mjburgess 3y ago
I've just been browsing, eg., https://github.com/robot-rumble/logic/blob/master/lang-runners/python/src/main.rs https://github.com/robot-rumble/logic/blob/master/lang-runne... via https://github.com/RustPython/RustPython/blob/main/jit/src/lib.rs 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.
- laeri 3y ago
  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.
  - mjburgess 3y ago
    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)
    - laeri 3y ago
      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.

kaba0 3y ago

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.

mjburgess 3y ago
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 don't want to feel visually assaulted when writing the type signature of the sort of function common in a dynamic language. Here `mypy` is also treasonously guilty. Consider, eg., zigs "function which returns a type at compile-time" is an example of where blindingly-obvious syntax retains its blindingly-obviousness because of compile-time eval... ie., we dont need a "second syntax" to program the compiler. This "two syntaxes, one for the runtime and one for the compiler" approach -- has swamped Rust as it aims for greater expressiveness. Not least, because it has a third syntax: one for unsafe.
- kaba0 3y ago
  You quickly gets into the undecidable category once you to down that road, which might be fine if you either don’t care about safety, or have runtime checks for that, but none of those were an option for rust (or at least an option that would have made it remotely interesting).
  - zozbot234 3y ago
    It's undecidable in the general case, but it becomes doable in non-Turing-complete languages that are still expressive enough to be useful for many practical cases. (These languages can express unrestricted recursion as an I/O-like effect that's only available outside the language proper, as part of compiling to a binary.)