Live data from Hacker News

On Learning Rust and Go: Migrating Away from Python

blog.liw.fi

201–210 of 346 posts

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

#201
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…

Wanting new shiny is a helpful healthy way to keep exploring and growing.

I've worked with the opposite who absolutely refuse to ever learn python/go/whatever, producing these awful thousand line bash scripts.

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

#202
post #48

Earlier quoted context omitted.

I've been doing some Java lately, and it seems to me like Java libraries are often doing (and making the programmer do) a lot of work just to get back the dynamism that Python has by default. Many kinds of errors are only detectable at runtime: * dependency injection errors, * template errors, * magic annotation malfunctions, etc. The last one in particular actually seems less safe than Python's decorator mechanism.…

You seem to be describing things that frameworks like Spring add. Java itself (as a language) doesn't "do" anything with annotations, they are literally just some extra strings in the class-file. Spring and its friends use those strings to do their magic. (Personally I find modern Spring applications as inscrutable as RoR applications which does indeed throw many categories of debugging out the window. Can't set a br…

[deleted]

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

#203

Earlier quoted context omitted.

Rust is still in research phase, as many programming patterns have no clear counterpart in Rust. Even though Rust's approach is very interesting, it might very well be that its strict typesystem turns out to be a dead-end for some existing programming patterns. Also, writing self-referential data-structures is very difficult in Rust (but not impossible) due to the type system. I suspect that a lot of developers who j…

> Also, writing self-referential data-structures is very difficult in Rust (but not impossible) due to the type system. Not really true (at least, not nearly to the same extent) since Pin was stabilized. I suppose that only serves to prove your point about Rust still being "in research phase", though!

Then does investment in learning Rust have any merit?

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

#204

Earlier quoted context omitted.

I disagree. 15k lines of code is a lot of code to keep entirely in your head all at once, which is basically what you have to do if you're using a language as dynamic as Python. In static languages like Java you can easily use tools to check types are correct, find usages of variables, jump to definitions and so on. And you get compile time errors if you screw up, rather than runtime errors.

15K doesn’t seem like much. I’ve spent the last 5 years keeping 250-300K straight in my head, and have never struggled with it. 15K would be a delight. I can recognize hitting a personal limit at 300K, though—not that I can’t hold more, just that I lose all interest in doing so. That seems to be the point where I grow tired of a problem space.

“15k would be a delight”, implies that 250-300k is not a delight.

It sounds like your loss of interest may be correlated with your level of discomfort with increased cognitive load.... the alternative explanation would be strange: you can only be interested in simpler problems/implementations. (Which I doubt)

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

#205
post #155

Earlier quoted context omitted.

ok. tell me what i’ve done and haven’t done. you’re the expert.

Not telling you what you have done or not done. But this is the internet, you need to provide proof in order for your statements to be taken seriously. I am not telling you to do anything, by all means don't provide any proof.

> But this is the internet

I find that on the internet, after proofs are given, more disagreement ensues. When one mind's is set, is set in stone. Proof or without proof.

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

#206
post #126

Earlier quoted context omitted.

I don't understand this logic. The users are learning Python , not C++ when they're trying to learn data science or implement a machine learning model. Should I say Tensor flow isn't written in C++ but CUDA or OpenCL? Any self respecting researcher is training their models on GPU or FPGA, not CPU. The point is that Python is the entry point for large majority of data scientists currently and its absolutely disingenuo…

> The users are learning Python, not C++ The key word here is "users". Python is fantastic for users. It allows users to get things done without having to worry about types or memory or the underlying hardware in any way.

I’d say it’s very disingenuous to claim that Python users don’t have to care about types. Many types are directly related to semantics, so of course they have to care about types!

I think Python made some really good choices with their types from UX that lead to you having to care more about your logic than the machine. Only one integer type, for example! For most users it’s perfect UX.

However, I think (possibly due to the early time when a Python was made) some of the decisions made practical but regrettable trade offs. Duck typing is ultimately just type inference with strong performance penalties and really weak static tooling, for example. _Many_ static type systems are still very far from the user’s actual domain, but the core techniques don’t have to be.

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

#207
post #160

Earlier quoted context omitted.

These two stuck out as well. I wonder if the issue is with their coding practices and not necessarily a fault with the language. If the issue is one of fundamentals it will only follow them to the next project or language

Give me two lines of an innocent man's hand... Really, changing a Python project is not pretty, because speed and memory usage guarantees vary wildly between releases. One factor is that CPython is constantly being rewritten. And that does not even cover projects that depend on 20 PyPI packages, which introduces practically guaranteed breakage.

> One factor is that CPython is constantly being rewritten.

Exactly. I have an impression that the programmers as the whole already spent significant time only to develop and maintain different solutions only to manage different Python versions and dependencies in production environments, which were maybe much less needed exactly with some better "discipline" in the Python development itself.

On another side, Python won many hearts over Perl 5 which is much more stable, but "appears to be" harder. Interestingly, Perl actually forces a programmer to "care more" (i.e. be more precise): the reference to something requires different notation than the direct use of something, the use of the array requires different notation than the use of the scalar etc... it actually has "some kind" of typing enforced by the language and explicit in every line. In my personal experience, I have much more "trust" in a 'biggish' Perl program than in a that big Python program to behave "exactly how I'd expect it" (e.g. in the sense that Perl doesn't produce as easy "exceptions" and whoever wrote it had to think more about the correctness than for Python, especially if "use strict" was used, which has stronger guarantees about the typos in variable names than Python). Going further, however, C-like (actually Algol-like) compiled languages simply allow much more than the scripting languages, regarding the smallness of what is eventually produced. E.g. Busybox ( https://busybox.net/ ) has to be written in C or something very close to C. Free Pascal http://wiki.freepascal.org/Platform_list is actually also very practical language for many use-cases.

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

#209
post #131

Earlier quoted context omitted.

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

Java is a bit special in this regard because of the Java TCK which has caused issues for e.g. Apache Harmony.
Post reply on HN