Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Learning Rust and Go: Migrating Away from Python

blog.liw.fi

Post reply on HN
Print view View original

111–120 of 346 posts

Re: On Learning Rust and Go: Migrating Away from Python

#111

Post by pushpop »

UncleEntity wrote: post #107
pushpop wrote: post #26

Earlier quoted context omitted.

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.

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.

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.

Re: On Learning Rust and Go: Migrating Away from Python

#112

Post by melling »

bayesian_horse wrote: post #71
pagefault123 wrote: post #37

Earlier quoted context omitted.

Perhaps there should be apostasy punishments for Python defectors. /s Python's typing story is far from perfect and rather annoying compared to other languages. Python is good for interacting with the operating system, networking and other things. But wanting a proper compiler is an honest motivation.

There are type checkers now. Personally I find type systems a lot more annoying because they lead to more verbose code and more cognitive load. There are studies that show bugs being proportional to the number of lines of code, regardless of language. And that effect seems to be more significant than the difference among dynamic and static type systems. Defensive programming can be achieved through various means. Typ…

I don’t think Haskell or OCaml are more verbose than Python.

Other traditional languages are adopting type inference, etc. We could be near an inflection point where we get statically type languages that are as convenient as Python.

Re: On Learning Rust and Go: Migrating Away from Python

#113

Post by mjw1007 »

newen wrote: post #95
joshvm wrote: post #90

Earlier quoted context omitted.

> assert(isinstance(arg, type)) The most irritating thing I've found is trying to write a function that accepts either a path or the raw contents of a file. Python 3 makes this easy, you can check against string. Python 2 of course treats everything as a byte string. In the end I just check the length of the input if the interpret identifies as python 2. If it's a short byte string, I assume it's a file name. Otherwi…

Why would you ever do that? Why would you even want a function that accepts either a file name or file contents when both are strings? What's so hard about defining a new function?

One common case where this is attractive is where you have a bunch of "public" functions built on top of each other, with the higher ones passing that parameter on and not otherwise caring what it is:

  high_level_function(src, ...)
      ...
      mid_level_function(src, ...)
      ...

  mid_level_function(src, ...)
      low_level_function(src, ...)
      ...

  low_level_function(src, ...)
      ...
If you can make the low-level function generic one way or another, you avoid having to duplicate the higher-level functions.

Another case is where there are two or more parameters that you want to be generic in this sense: if your only option is duplicating the function you can end up having to define inconveniently many variants.

Re: On Learning Rust and Go: Migrating Away from Python

#115

Post by tannhaeuser »

siteshwar wrote: post #54

> Rust is developed by a community, and was started by Mozilla. Go development seems to be de facto controlled by Google, who originated the language. I'd rather bet my non-work future on a language that isn't controlled by a huge corporation, especially one of the main players in today's surveillance economy. Anyone else agree with this view ? Programming languages should be choosen based on technical merits, rather…

There's a simple remedy to the problem of becoming dependent on a single entity wrt the programming language you choose: use only languages with "official" specs (by ISO/IEC or another respected org) and multiple implementations. That's C, C++, ECMAScript, shell, and a couple niche languages such as Ada, Fortran, and Prolog.

Re: On Learning Rust and Go: Migrating Away from Python

#116

Post by guidopallemans »

newen wrote: post #95
joshvm wrote: post #90

Earlier quoted context omitted.

> assert(isinstance(arg, type)) The most irritating thing I've found is trying to write a function that accepts either a path or the raw contents of a file. Python 3 makes this easy, you can check against string. Python 2 of course treats everything as a byte string. In the end I just check the length of the input if the interpret identifies as python 2. If it's a short byte string, I assume it's a file name. Otherwi…

Why would you ever do that? Why would you even want a function that accepts either a file name or file contents when both are strings? What's so hard about defining a new function?

An example: pandas.read_csv

https://pandas.pydata.org/pandas-docs/stable/reference/api/p...

Re: On Learning Rust and Go: Migrating Away from Python

#117

Post by mlthoughts2018 »

spaced-out wrote: post #80
mlthoughts2018 wrote: post #69

Earlier quoted context omitted.

Not just data science: the entire machine learning and scientific computing world, if we’re honest. Need to do huge numerical linear algebra operations very fast with great memory safety and ease of use? Python.

Technically, you'd use a C/C++ library with a Python wrapper.

Yes, that is called Python.

Re: On Learning Rust and Go: Migrating Away from Python

#118

Post by phkahler »

typon wrote: post #59
pagefault123 wrote: post #37

Earlier quoted context omitted.

Perhaps there should be apostasy punishments for Python defectors. /s Python's typing story is far from perfect and rather annoying compared to other languages. Python is good for interacting with the operating system, networking and other things. But wanting a proper compiler is an honest motivation.

Yet the entire data science world is built on Python. I don't understand this blatant disregard of reality.

None of the libraries that do the computations are written in python. None of the GUIs or matplotlib are written in python. If you want to build large projects or need performance, python is not the right language. I do like python a lot - for the things it's good at.

Re: On Learning Rust and Go: Migrating Away from Python

#119

Post by UncleEntity »

pushpop wrote: post #111
UncleEntity wrote: post #107

Earlier quoted context omitted.

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.

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…

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.

Re: On Learning Rust and Go: Migrating Away from Python

#120

Post by empath75 »

bayesian_horse wrote: post #74
empath75 wrote: post #42

Earlier quoted context omitted.

Type checking as an add-on is okay but it is not the same thing as a statically typed language.

There is no proof or study that statically typed languages are safer in any regard than others.

I didn’t say anything about safety. I find that it makes writing code and refactoring and collaborating a lot easier.
Post reply on HN