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

131–140 of 346 posts

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

#131

Post by brabel »

tannhaeuser wrote: post #115
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.

I believe Java also fits that list. The [Java Language Specification](https://docs.oracle.com/javase/specs/jls/se12/html/index.htm...) via the [Java Virtual Machine Specification](https://docs.oracle.com/javase/specs/jvms/se12/html/index.ht...) is implemented on the open-source OpenJDK project and many other free distributions exist, including from Amazon, Azul, IBM, Alibaba and others [1].

[1] https://en.wikipedia.org/wiki/List_of_Java_virtual_machines#...

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

#132

Post by computerex »

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.

Wrong. http://ttendency.cs.ucl.ac.uk/projects/type_study/documents/...

"our central finding is that both static type systems find an important percentage of public bugs: both Flow 0.30 and TypeScript 2.0 successfully detect 15%!"

In fact there have been more than 1 study with the same conclusion.

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

#133

Post by kod »

Rotareti wrote: post #125
gameswithgo wrote: post #25

Earlier quoted context omitted.

Most of my serious work has been done with statically typed languages, though of course I have worked with dynamically typed ones as well. There are a few things about dynamically typed languages that seem to productivity-negative, but it may just be my lack of understanding of how people expert at a dynamic languages work with them. 1 - When working with a large enough code base that you don't remember exactly what…

Python has type annotations since 3.5 and you can get static type checking via mypy. This is a type system that works quite well IMHO and eleminates most of the issues you mentioned.

The main benefit of Python is the ecosystem of libraries. Those libraries don't have type annotations. Mypy is a far cry from a real statically typed language.

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

#134

Post by kod »

xyproto wrote: post #24

The strengths of Go become apparent when working in teams and when deploying, not when reading blogs about the language before trying to write code in it.

My experience of working with Go in teams is that it encourages copy-paste programming and "works on my machine" deployment problems.

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

#135

Post by makapuf »

sfifs wrote: post #86
typon wrote: post #59

Earlier quoted context omitted.

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

Python is ideally suited for data science and machine learning because 80% of the work tends to be data exploration, transformations and feature engineering and 19% of the work is iterative development of models. In such workflows the lack of type checking & simple REPL is a huge feature. Most of the underlying code for ML is anyway written in Fortran or C and Python becomes a very convenient front end glue For the 1…

Uh why ? Thousands of hits per second will generally be IO or DB bound and will be done using clear code and a minimum of boilerplate.

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

#136

Post by stochastic_monk »

tyingq wrote: post #91
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…

"Programming languages should be choosen based on technical merits, rather than who is behind it." Considering the motivations of the language owner is a valid concern. Many people, for example, jumped on to HHVM as a "faster PHP". Then it started branching away from PHP[1]. Predictable, if you considered Facebook's reasons for having it. [1] https://hhvm.com/blog/2018/09/12/end-of-php-support-future-o...

What were Facebook’s reasons?

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

#137

Post by computerex »

jacquesm wrote: post #8

15Kloc and trouble is indicative of other problems than a problem with the language. I wrote multiple 50Kloc and up pieces of software in GFA Basic, arguably a much more limiting and unsafe environment than Python ever was, and yet, that software worked well and was maintainable to the point that its descendants still run 3 decades later. Python has all the bells and whistles you need to build large code bases, but y…

> Python has all the bells and whistles you need to build large code bases, but you do need to get organized, no language can really do that for you and attempts at forcing you to do it give rise to 'factory factory' nonsense

This is almost satirical.

> Assembler has all the bells and whistles you need to build large code bases, but you do need to get organized, no language can really do that for you and attempts at forcing you to do it give rise to 'factory factory' nonsense.

I can definitely see someone replacing python with any X language.

Just because you can do something, doesn't mean you should. I personally like opinionated languages that have made some decisions for you based on best practices and research.

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

#138

Post by _v7gu »

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.

I think Python is at a weird place regarding data science.

If you need easy-to-use tools, R libraries cover significantly more ground than Python. You don't have to worry about 2/3 compatibility of niche libraries. Plus the functional language forces the libraries to have similar API's. You also get to use tidyverse and ggplot2 in all of their majestic beauty. At most you have to write a "%>% do() %>%" to get around weird library API choices.

However if you are in the frontier, you could avoid so much awkward notation with an array-first language like Matlab or Julia. You have "^" instead of "np.linalg.matrix_power", "/","\" instead of "np.linalg.lstsq", the . operator and so much more life-saving tools.

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

#139

Post by mylons »

computerex wrote: post #127
toyg wrote: post #30

> Note that I've not written any significant code in either language, so I'm just writing based on what I've learnt by reading. So he’s basically comparing 20+ years of Python usage with marketing material from Go and Rust. Right. I wish people could be honest with their motivations, instead of making up excuses to justify this sort of change. Here it’s a classic case of “I got bored and I don’t like the new features…

Wow. It's amazing the lengths people go to to maintain their delusions. Show me one python IDE in action doing effective refactoring across a large, nontrivial python code base. And you didn't even mention concurrency and skipped over it altogether! > use type hints or one of the many libs that enforce types... As if that's pythonic. Heard of duck typing? And those are things you have to do yourself, as additional wo…

i’ve used pycharm to refactor 100k+ LOC bases.

pycharm also uses the type hints that are PART OF THE LANGUAGE (aka pythonic) as of python 3.x and enforces them.

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

#140

Post by UncleEntity »

pushpop wrote: post #123
UncleEntity wrote: post #119

Earlier quoted context omitted.

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…

> 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.

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.

Post reply on HN