6 ms·

Maybe we've reached the limits of the complexity we can handle in a simple text-based language and should develop future languages with IDEs in mind. IDEs can h

by cies 4y ago

Maybe we've reached the limits of the complexity we can handle in a simple text-based language and should develop future languages with IDEs in mind. IDEs can hide some of the complexity for us, and give access to it only when you are digging into the details.

pjmlp 4y ago
Like Common Lisp, Smalltalk, SELF, Delphi, C++ Builder, Java, C#, Visual Basic,.... The problem is that most on FOSS community tend to design languages for VI/Emacs workflows.
flohofwoe 4y ago
This just plasters over the underlying problem, which in case of Rust is IMO that features that should go into the language as syntax sugar instead are implemented as generic types in the standard library (exact same problem of why modern C++ source code looks so messy). This is of course my subjective opinion, but I find Zig's syntax sugar for optional values and error handling a lot nicer than Rust's implementation of the same concepts. The difference is (mostly): language feature versus stdlib feature.
- vlovich123 4y ago
  I’m not familiar with zig. Can you give some examples to illustrate your point?
  - flohofwoe 4y ago
    An optional is just a '?' before the type: For instance a function which returns an optional pointer to a 'Bla': fn make_bla() ?*Bla { // this would either return a valid *Bla, or null } A null pointer can't be used accidentally, it must be unwrapped first, and in Zig this is implemented as language syntax, for instance you can unwrap with an if: if (make_bla()) |bla| { // bla is now the unwrapped valid pointer } else { // make_bla() returned null } ...or with an orelse: const bla = make_bla() orelse { return error.InvalidBla }; ...or if you know for sure that bla should be valid, and otherwise want a panic: const bla = make_bla().?; ...error handling with error unions has similar syntax sugar. It's probably not perfect, but I feel that for real-world code, working with optionals and errors in Zig leads to more readable code on average than Rust, while providing the same set of features.
    - wtetzner 4y ago
      How does Zig represent Option<Option<i32>>? Would it be something like this? ??i32
      - flohofwoe 4y ago
        I had to try it out first, but yep, that's how it works: const assert = @import("std").debug.assert; fn get12() i32 { const opt_opt_val: ??i32 = 12; const val = opt_opt_val.?.?; comptime assert(val == 12); return val; } [https://www.godbolt.org/z/oncd5shvP https://www.godbolt.org/z/oncd5shvP]
    - veber-alex 4y ago
      I don't see how that is all that different from Rust. The main difference I see is that in Rust it will also work with your own custom types, not just optional. fn make_bla() -> Option<Bla> { // this either returns a valid Bla, or None } if let Some(bla) = make_bla() { // bla is now the unwrapped valid type } else { // make_bla() returned None } ..or with the '?' operator (early return) let bla = make_bla().ok_or(InvalidBla)?; ..or with let_else (nightly only but should be stable Soon(tm)) let Some(bla) = make_bla() else { return Err(InvalidBla) } ..or panic on None let bla = make_bla().unwrap();
- marcosdumay 4y ago
  Rust developers are doing an awesome job of identifying those things and changing the language to meet it. Today's Rust is much cleaner than it was 5 years ago (or 8 if you count nightly). But yes, there is still a lot of it. Anyway, most of the noise comes from the fact that Rust is a low level language that cares about things like memory management. It's amazing how one is constantly reminded of this by the compiler, what is annoying, but the reason it doesn't happen on the alternatives is because they never let you forget about that fact.
robonerd 4y ago
The problem with this premise is that by raising the bar for any IDE that wants to support that language, you risk the creation of an IDE monoculture.
- pjmlp 4y ago
  JetBrains is doing quite well with InteliJ monoculture.
- xxpor 4y ago
  Is that as true any more with the language server model? I'm not familiar enough with it to know how much is truely in the protocol vs what the editor still has to do themselves.
  - robonerd 4y ago
    LSPs are great, I think they've proven fairly easy to integrate into many text editors. But consider something like the Scratch programming language. How many editors support Scratch? Once you stray from code-as-text, adding support to old editors often becomes infeasible and the effort needed to create new editors is a significant barrier to entry.

by cies 4y ago

pjmlp 4y ago

Like Common Lisp, Smalltalk, SELF, Delphi, C++ Builder, Java, C#, Visual Basic,.... The problem is that most on FOSS community tend to design languages for VI/Emacs workflows.

flohofwoe 4y ago

This just plasters over the underlying problem, which in case of Rust is IMO that features that should go into the language as syntax sugar instead are implemented as generic types in the standard library (exact same problem of why modern C++ source code looks so messy). This is of course my subjective opinion, but I find Zig's syntax sugar for optional values and error handling a lot nicer than Rust's implementation of the same concepts. The difference is (mostly): language feature versus stdlib feature.

vlovich123 4y ago
I’m not familiar with zig. Can you give some examples to illustrate your point?
- flohofwoe 4y ago
  An optional is just a '?' before the type: For instance a function which returns an optional pointer to a 'Bla': fn make_bla() ?*Bla { // this would either return a valid *Bla, or null } A null pointer can't be used accidentally, it must be unwrapped first, and in Zig this is implemented as language syntax, for instance you can unwrap with an if: if (make_bla()) |bla| { // bla is now the unwrapped valid pointer } else { // make_bla() returned null } ...or with an orelse: const bla = make_bla() orelse { return error.InvalidBla }; ...or if you know for sure that bla should be valid, and otherwise want a panic: const bla = make_bla().?; ...error handling with error unions has similar syntax sugar. It's probably not perfect, but I feel that for real-world code, working with optionals and errors in Zig leads to more readable code on average than Rust, while providing the same set of features.
  - wtetzner 4y ago
    How does Zig represent Option<Option<i32>>? Would it be something like this? ??i32
    - flohofwoe 4y ago
      I had to try it out first, but yep, that's how it works: const assert = @import("std").debug.assert; fn get12() i32 { const opt_opt_val: ??i32 = 12; const val = opt_opt_val.?.?; comptime assert(val == 12); return val; } [https://www.godbolt.org/z/oncd5shvP https://www.godbolt.org/z/oncd5shvP]
  - veber-alex 4y ago
    I don't see how that is all that different from Rust. The main difference I see is that in Rust it will also work with your own custom types, not just optional. fn make_bla() -> Option<Bla> { // this either returns a valid Bla, or None } if let Some(bla) = make_bla() { // bla is now the unwrapped valid type } else { // make_bla() returned None } ..or with the '?' operator (early return) let bla = make_bla().ok_or(InvalidBla)?; ..or with let_else (nightly only but should be stable Soon(tm)) let Some(bla) = make_bla() else { return Err(InvalidBla) } ..or panic on None let bla = make_bla().unwrap();
marcosdumay 4y ago
Rust developers are doing an awesome job of identifying those things and changing the language to meet it. Today's Rust is much cleaner than it was 5 years ago (or 8 if you count nightly). But yes, there is still a lot of it. Anyway, most of the noise comes from the fact that Rust is a low level language that cares about things like memory management. It's amazing how one is constantly reminded of this by the compiler, what is annoying, but the reason it doesn't happen on the alternatives is because they never let you forget about that fact.

robonerd 4y ago

The problem with this premise is that by raising the bar for any IDE that wants to support that language, you risk the creation of an IDE monoculture.

pjmlp 4y ago
JetBrains is doing quite well with InteliJ monoculture.
xxpor 4y ago
Is that as true any more with the language server model? I'm not familiar enough with it to know how much is truely in the protocol vs what the editor still has to do themselves.
- robonerd 4y ago
  LSPs are great, I think they've proven fairly easy to integrate into many text editors. But consider something like the Scratch programming language. How many editors support Scratch? Once you stray from code-as-text, adding support to old editors often becomes infeasible and the effort needed to create new editors is a significant barrier to entry.