3 ms·

If you don't consider static type and built in concurrency primitives features then ok, at what point does nice to have features outweigh performance gains and

If you don't consider static type and built in concurrency primitives features then ok, at what point does nice to have features outweigh performance gains and the robustness of static typing that directly impacts the quality of the end user experience and the readability of the code to other developers?

pjmlp 3y ago
Python has built in concurrency support, stuff like Mypy and IDE tooling make up for the dynamic typing. And if that isn't enough, the answer is OCaml, F#, D, C#, Java, Scala, Haskell, Kotlin, C++,... definitely not going from horse to donkey in language features.
orangecat 3y ago
readability of the code to other developers I disagree that Go's insistence on verbosity improves readability. Each individual line may simpler, but the larger purpose of the code is obscured in all the "if err != nil" weeds. My unpopular opinion is that Dart should get a lot more attention. Strong typing with null-safety, compiles to native, batteries included, and nearly as expressive as Python.
- randomdata 3y ago
  > but the larger purpose of the code is obscured in all the "if err != nil" weeds. That's the difference between script and system programming. When writing scripts, one is only concerned about carrying out a certain task and if anything goes wrong the whole thing can bail. Systems are more robust. When things go wrong they cannot just fail. They need to recover gracefully and do something meaningful in the failed state. Handing failure conditions is the primary purpose of system code. Irrespective of Go, there is something to be said about some kind of identifier that says "take note: this is the most important code in the application!" If that comes across as being 'weedy', you know that you really needed a scripting language, not a systems language. Different tools for different jobs.
  - gaganyaan 3y ago
    Go still picked a terrible option. The `?` operator in Rust is way better, proving that systems languages don't have to suffer Go's choice.
    - randomdata 3y ago
      That is quite different. ? in Rust signifies "this code is not important" Which even in systems is unavoidable, to be fair. Sometimes failure just isn't important. The division between systems and scripts is not perfect. But, that will be the uncommon case in systems. It is not certain that really needs a symbol in which to draw attention. (An implementation may need a symbol, but that's beyond this discussion)
      - gaganyaan 3y ago
        I'm not sure why you think it's unimportant. You seem to be confusing its purpose, and making distinction between systems and scripts that doesn't apply here. Rust's whole error handling, including the ? operator work great for embedded systems where Go isn't enough of a systems language to even run. EDIT: I think you're confused. The ? operator says "I'm not handling this specially here". That doesn't mean the error is just propagated to the top like an uncaught exception in a Python script. It allows you any level of granular handling you'd like.
  - deleted 3y ago
    [deleted]
  - sgarland 3y ago
    Python has excellent exception handling, and its corollary to if err != nil would be try/except blocks everywhere. That said, I hate Go for unrelated reasons, and love Python.
    - randomdata 3y ago
      Go's exception handling (panic/recover) is very much like most other languages with exception handling, including Python. It is there to use when you have exceptions. But we're talking about expected failure (network failure, hardware failure, etc.), not exceptional cases (programmer error). You would not want to carry 'expecteds' on exception handlers. Different tools for different jobs. That said, systems transcend Go. The discussion isn't about Go, or Python, specifically.

pjmlp 3y ago

Python has built in concurrency support, stuff like Mypy and IDE tooling make up for the dynamic typing. And if that isn't enough, the answer is OCaml, F#, D, C#, Java, Scala, Haskell, Kotlin, C++,... definitely not going from horse to donkey in language features.

orangecat 3y ago

readability of the code to other developers I disagree that Go's insistence on verbosity improves readability. Each individual line may simpler, but the larger purpose of the code is obscured in all the "if err != nil" weeds. My unpopular opinion is that Dart should get a lot more attention. Strong typing with null-safety, compiles to native, batteries included, and nearly as expressive as Python.

randomdata 3y ago
> but the larger purpose of the code is obscured in all the "if err != nil" weeds. That's the difference between script and system programming. When writing scripts, one is only concerned about carrying out a certain task and if anything goes wrong the whole thing can bail. Systems are more robust. When things go wrong they cannot just fail. They need to recover gracefully and do something meaningful in the failed state. Handing failure conditions is the primary purpose of system code. Irrespective of Go, there is something to be said about some kind of identifier that says "take note: this is the most important code in the application!" If that comes across as being 'weedy', you know that you really needed a scripting language, not a systems language. Different tools for different jobs.
- gaganyaan 3y ago
  Go still picked a terrible option. The `?` operator in Rust is way better, proving that systems languages don't have to suffer Go's choice.
  - randomdata 3y ago
    That is quite different. ? in Rust signifies "this code is not important" Which even in systems is unavoidable, to be fair. Sometimes failure just isn't important. The division between systems and scripts is not perfect. But, that will be the uncommon case in systems. It is not certain that really needs a symbol in which to draw attention. (An implementation may need a symbol, but that's beyond this discussion)
    - gaganyaan 3y ago
      I'm not sure why you think it's unimportant. You seem to be confusing its purpose, and making distinction between systems and scripts that doesn't apply here. Rust's whole error handling, including the ? operator work great for embedded systems where Go isn't enough of a systems language to even run. EDIT: I think you're confused. The ? operator says "I'm not handling this specially here". That doesn't mean the error is just propagated to the top like an uncaught exception in a Python script. It allows you any level of granular handling you'd like.
- deleted 3y ago
  [deleted]
- sgarland 3y ago
  Python has excellent exception handling, and its corollary to if err != nil would be try/except blocks everywhere. That said, I hate Go for unrelated reasons, and love Python.
  - randomdata 3y ago
    Go's exception handling (panic/recover) is very much like most other languages with exception handling, including Python. It is there to use when you have exceptions. But we're talking about expected failure (network failure, hardware failure, etc.), not exceptional cases (programmer error). You would not want to carry 'expecteds' on exception handlers. Different tools for different jobs. That said, systems transcend Go. The discussion isn't about Go, or Python, specifically.