6 ms·

It’s not just about code organisation though. Both Rust and Go have fantastic compilers which catch a great many dumb but common user errors before you even get

It’s not just about code organisation though. Both Rust and Go have fantastic compilers which catch a great many dumb but common user errors before you even get to the stage of testing. Obviously this doesn’t replace the need for functional tests but writing those tests is as much prone to user error as writing the code itself. So having a compiler check for stupidity up front is always going to be a bonus. Also the static type system helps a lot too. Having dynamic types can be awfully convenient at times and I completely relate to why some people like them but static types means your structures and classes effectively have written specifications defined in the code itself which the compiler verifies the rest of your program against. So if you’re accidentally trying to write text to a numeric type, your compiler will catch that. In my experience the extra up front overhead (in terms of development time) of static typed AOT compiled languages end up saving you development time in the long run when working against larger projects.

nurettin 8y ago
Mypy and type hints does catch that.
- pushpop 8y ago
  Sure. There are additional tooling you can use in Rust and Go to catch a plethora of errors beyond what I described too. However if they require the user run them manually then they’re just as open to user error as the testing I also described. This is why having those checks in the compiler itself can be invaluable.
  - UncleEntity 8y ago
    Running a static analyzer is just another case to add to the test suite. So...you add them to your build system and Bob's your uncle.
    - pushpop 8y ago
      Again, the point is you need your engineers to diligent enough to do so. That isn’t always the case. Which is why I talk about checks being part of the standard language build tools. Humans error. I’ve seen numerous occasions when stuff that should have been added into the tests wasn’t. Even from engineers who are normally thorough. I’ve also seen cases when competent engineers have written test cases that pass when they should have failed. Heck even I’ve done that and I’ve been writing software for 30 years. The more a languages build tools can catch developer errors, the less you need to rely on developers remembering to check for them and thus the more time developers can focus on the project at hand.
      - UncleEntity 8y ago
        This seems a more institutional issue than something python should take care of for you. If your devs are pushing code into production that doesn't pass the tests (or they aren't even running the test suite) then you're asking for trouble no matter what language you use. As much as I love reading 20+ pages of errors c++ likes to spit out when you use a template wrong if I want to do something simple I just reach for python.
        pushpop 8y ago
        > If your devs are pushing code into production that doesn't pass the tests (or they aren't even running the test suite) then you're asking for trouble no matter what language you use. Clearly that’s not even remotely what I said. But I’ve posted the same thing twice already. I see no point posting it a 3rd time.
        UncleEntity 8y ago
        My understanding of your argument is it's too much of a burden for devs to run a static type checker manually so the language should force you to run it as part of the compilation process. Sure, yeah, if you want to ensure type safety then use a type safe language...argument over. ...unless you want to do something like duck punch some function into someone else's library and you really don't want to rearchitech how the whole thing works because of that one special case which just doesn't quite work.
  - nurettin 8y ago
    usually integrated into pycharm or vs code so you get the warnings and errors as you type/save
pytester 8y ago
>Having dynamic types can be awfully convenient at times and I completely relate to why some people like them but static types means your structures and classes effectively have written specifications defined in the code itself which the compiler verifies the rest of your program against. So if you’re accidentally trying to write text to a numeric type, your compiler will catch that. In my experience, if I'm writing relatively decent tests and sprinkling of sanity checks these types of errors get caught quickly and are very obvious. I can sympathize with somebody who has largely worked with untested statically typed projects and has moved to untested dynamically typed projects though - this is where the benefit of compiler type checking might seem to be most valuable. I can also sympathize with somebody working with a dynamically typed language with a bad type system (cough javascript). >In my experience the extra up front overhead (in terms of development time) of static typed AOT compiled languages end up saving you development time in the long run Yeah, mine doesn't.
- pushpop 8y ago
  Like I said, tests are also subject to user error. I’ve seen scenarios where tests passed when they shouldn’t have because the test itself was wrong. Or situations when test coverage was good but a basic type check seemed so obvious it was forgotten to be added. Some of those tests wouldn’t even have been needed in Rust or Go. I do agree that tests are important; hence why I raised that point from the outset. But ultimately in Python you’re still having to add extra tests just to catch up with the default behaviour of Go and Rust. Which is the point I was raising. Go and Rust are better at catching stupid user error. Clearly though you can write large projects in Python if you’re disciplined enough. Same could be said for C, BBC BASIC or even assembly. The question isn’t whether you can, it’s whether other languages makes it easier or not.
  - pytester 8y ago
    >But ultimately in Python you’re still having to add extra tests just to catch up with the default behaviour of Go and Rust. You don't though. The tests you'd write which would catch these "stupid user errors" are basic ones which you'd be remiss not to write in any language. The fact that frequently developers do choose not to write any tests at all on large code bases does mean that they start to rely heavily on compiler catching 'stupid user errors' but it doesn't have to be that way. >Go and Rust are better at catching stupid user error. ...if you don't have a basic level of tests, yes. (although rust does provide certain type level protection against, say, data race bugs which python doesn't).
kumarvvr 8y ago
Statically typed languages are more robust, as far as reducing errors is concerned.However, with modern static type checking tooling in Python, for small to medium sized programs, pythons benefits far outweigh its shortcomings.
- pushpop 8y ago
  I’ve already addressed that point elsewhere in this thread
tlear 8y ago
It all depends on type of project timeline etc. I find the stupid errors in untyped languages trivial to catch. In debugging the hard errors are what takes long time to deal with. Those types of errors are rarely can be caught by compiler. On other hand dynamic languages give you flexibility and speed when developing. In some cases that is worth a lot more then losses you suffer from them. Having said that Rust is just terrible application language. It was built for a purpose use it for that purpose. From typed perspective from what I have used recently Swift is probably my favourite. Here comes the catch, libraries, community support all tramp the hell out of almost any language feature. There is a reason we write metric ton of C++ for everything and basically everything Python has C++ and C under the hood. C++ has stuff to do it all, it has been tested polished, tested some more documented and works. Now even Pytorch has first class C++ API.. It’s about time! Java traumatized me as a young engineer fresh out of school. I can’t bring myself to even look at it these days. I am sure it is much better now. I just can’t do it.

nurettin 8y ago

Mypy and type hints does catch that.

pushpop 8y ago
Sure. There are additional tooling you can use in Rust and Go to catch a plethora of errors beyond what I described too. However if they require the user run them manually then they’re just as open to user error as the testing I also described. This is why having those checks in the compiler itself can be invaluable.
- UncleEntity 8y ago
  Running a static analyzer is just another case to add to the test suite. So...you add them to your build system and Bob's your uncle.
  - pushpop 8y ago
    Again, the point is you need your engineers to diligent enough to do so. That isn’t always the case. Which is why I talk about checks being part of the standard language build tools. Humans error. I’ve seen numerous occasions when stuff that should have been added into the tests wasn’t. Even from engineers who are normally thorough. I’ve also seen cases when competent engineers have written test cases that pass when they should have failed. Heck even I’ve done that and I’ve been writing software for 30 years. The more a languages build tools can catch developer errors, the less you need to rely on developers remembering to check for them and thus the more time developers can focus on the project at hand.
    - UncleEntity 8y ago
      This seems a more institutional issue than something python should take care of for you. If your devs are pushing code into production that doesn't pass the tests (or they aren't even running the test suite) then you're asking for trouble no matter what language you use. As much as I love reading 20+ pages of errors c++ likes to spit out when you use a template wrong if I want to do something simple I just reach for python.
      - pushpop 8y ago
        > If your devs are pushing code into production that doesn't pass the tests (or they aren't even running the test suite) then you're asking for trouble no matter what language you use. Clearly that’s not even remotely what I said. But I’ve posted the same thing twice already. I see no point posting it a 3rd time.
        UncleEntity 8y ago
        My understanding of your argument is it's too much of a burden for devs to run a static type checker manually so the language should force you to run it as part of the compilation process. Sure, yeah, if you want to ensure type safety then use a type safe language...argument over. ...unless you want to do something like duck punch some function into someone else's library and you really don't want to rearchitech how the whole thing works because of that one special case which just doesn't quite work.
- nurettin 8y ago
  usually integrated into pycharm or vs code so you get the warnings and errors as you type/save

pytester 8y ago

>Having dynamic types can be awfully convenient at times and I completely relate to why some people like them but static types means your structures and classes effectively have written specifications defined in the code itself which the compiler verifies the rest of your program against. So if you’re accidentally trying to write text to a numeric type, your compiler will catch that. In my experience, if I'm writing relatively decent tests and sprinkling of sanity checks these types of errors get caught quickly and are very obvious. I can sympathize with somebody who has largely worked with untested statically typed projects and has moved to untested dynamically typed projects though - this is where the benefit of compiler type checking might seem to be most valuable. I can also sympathize with somebody working with a dynamically typed language with a bad type system (cough javascript). >In my experience the extra up front overhead (in terms of development time) of static typed AOT compiled languages end up saving you development time in the long run Yeah, mine doesn't.

pushpop 8y ago
Like I said, tests are also subject to user error. I’ve seen scenarios where tests passed when they shouldn’t have because the test itself was wrong. Or situations when test coverage was good but a basic type check seemed so obvious it was forgotten to be added. Some of those tests wouldn’t even have been needed in Rust or Go. I do agree that tests are important; hence why I raised that point from the outset. But ultimately in Python you’re still having to add extra tests just to catch up with the default behaviour of Go and Rust. Which is the point I was raising. Go and Rust are better at catching stupid user error. Clearly though you can write large projects in Python if you’re disciplined enough. Same could be said for C, BBC BASIC or even assembly. The question isn’t whether you can, it’s whether other languages makes it easier or not.
- pytester 8y ago
  >But ultimately in Python you’re still having to add extra tests just to catch up with the default behaviour of Go and Rust. You don't though. The tests you'd write which would catch these "stupid user errors" are basic ones which you'd be remiss not to write in any language. The fact that frequently developers do choose not to write any tests at all on large code bases does mean that they start to rely heavily on compiler catching 'stupid user errors' but it doesn't have to be that way. >Go and Rust are better at catching stupid user error. ...if you don't have a basic level of tests, yes. (although rust does provide certain type level protection against, say, data race bugs which python doesn't).

kumarvvr 8y ago

Statically typed languages are more robust, as far as reducing errors is concerned.However, with modern static type checking tooling in Python, for small to medium sized programs, pythons benefits far outweigh its shortcomings.

pushpop 8y ago
I’ve already addressed that point elsewhere in this thread

tlear 8y ago

It all depends on type of project timeline etc. I find the stupid errors in untyped languages trivial to catch. In debugging the hard errors are what takes long time to deal with. Those types of errors are rarely can be caught by compiler. On other hand dynamic languages give you flexibility and speed when developing. In some cases that is worth a lot more then losses you suffer from them. Having said that Rust is just terrible application language. It was built for a purpose use it for that purpose. From typed perspective from what I have used recently Swift is probably my favourite. Here comes the catch, libraries, community support all tramp the hell out of almost any language feature. There is a reason we write metric ton of C++ for everything and basically everything Python has C++ and C under the hood. C++ has stuff to do it all, it has been tested polished, tested some more documented and works. Now even Pytorch has first class C++ API.. It’s about time! Java traumatized me as a young engineer fresh out of school. I can’t bring myself to even look at it these days. I am sure it is much better now. I just can’t do it.