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

221–230 of 346 posts

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

#221

Post by hsivonen »

killaken2000 wrote: post #141
acqq wrote: post #92

Earlier quoted context omitted.

See the details here about his project that he maintained in Python for years (since 2006) in Python: https://blog.liw.fi/posts/2017/08/13/retiring_obnam/ I can really understand his: "Obnam has not turned out well, from a maintainability point of view. It seems that every time I try to fix something, I break something else. Usually what breaks is speed or memory use: Obnam gets slower or starts using even more memor…

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

Are you making that comment by speculating or by having looked at the Obnam codebase? I'm not a Python developer, but I've looked at the Obnam code enough to have written a replacement crypto plugin for it. AFAICT, if Obnam was holding Python wrong, it's too hard to hold it right.

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

#222

Post by thinkpad20 »

lerax wrote: post #124
melling wrote: post #112

Earlier quoted context omitted.

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.

> I don’t think Haskell or OCaml are more verbose than Python. I love Haskell computing model, but holy hell, why is so difficult using things like State Monad or even a trivial thing like a global counter [1] ? Why something so simple should be so difficult? Don't say it's because functional programming, Scheme/Racket is not that difficult! Haskell and OCaml has their own problems, I agreed with you that both langua…

A global counter is difficult because shared global mutable state should be difficult —- it can wreak havoc on your code. That said, if you’re really set on it it’s not particularly bad

    counter :: IORef Int
    counter = unsafePerformIO (newIORef 0)

    usesGlobalState :: IO ()
    usesGlobalState = do
      count
It’s even easier in ocaml, where you’d use ref and not need to worry about the IO monad.

Anecdotally, I find it incredibly rare that such a thing is desirable, when you could instead create it in an IO monad and pass it through to functions that need it. But, it’s there when necessary. And making this kind of anti pattern hard is a strength of these languages, not a weakness.

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

#223

Post by jimktrains2 »

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…

> Personally I find type systems a lot more annoying because they lead to more verbose code and more cognitive load.

Have you forgotten the cognitive load of "what does this return and what can I call or access on it?"

> There are studies that show bugs being proportional to the number of lines of code, regardless of language

But that value isn't the same across all languages, only the trend.

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

#225

Post by jacquesm »

IshKebab wrote: post #10
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…

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 lines of code is a lot of code to keep entirely in your head all at once

There's your problem then! You don't write a codebase that size in such a way that you need to keep it all in your head at once. The whole point of 'getting organized' is to reduce the amount of code that is in scope for you to have to understand. If it's more than a page or so then you will always end up with hard to debug problems. Reducing the amount of code in scope is one of the most powerful tools you have to deal with large codebases.

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

#226

Post by vram22 »

bayesian_horse wrote: post #79
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…

In all three cases, Python, Go and Rust, the language and ecosystem may be in the hands of an organization, but you can probably produce code productively in it for years even if the organization went under or chose unacceptable paths. Go is quite unique in that it produces very independent binaries. This might make software written in it quite future-proof. Personally I like Python's philosophy and the way the commu…

>Go is quite unique in that it produces very independent binaries. This might make software written in it quite future-proof.

What do you mean by "it produces very independent binaries."? Do you mean that Go implements system calls itself, instead using corresponding wrappers from the OS's underlying C library?

I read something like that recently, but haven't looked into the point yet.

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

#227

Post by pytester »

pushpop wrote: post #176
pytester wrote: post #152

Earlier quoted context omitted.

>I have no problems with exception per se but what you’ve now done is push your error checking into the runtime which means your application could crash at unexpected times. In theory but in theory any application could crash at an unexpected time. In my experience on a half decent code base these sanity checks never trigger during production in normal code; they're designed to get triggered during tests. They're the…

> In theory but in theory any application could crash at an unexpected time That’s a terribly unsatisfactory answer. > In my experience on a half decent code base these sanity checks never trigger during production in normal code; they're designed to get triggered during tests. They're there to make it easy to track down the root cause of bugs. There are a lot of conditionals attached to your statement. ;) > The time…

Your answers are exactly in line with the views usually espoused by a developer who skimps on TDD and automated testing and thus over relies on compiler type checking to catch trivial bugs.

The idea that you've been doing it like this for 30 years is somewhat depressing.

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

#228

Post by snackematician »

acomjean wrote: post #110
Annatar wrote: post #66

Earlier quoted context omitted.

Wrong: the data science world is built on R, which was designed from the ground up to be the freeware alternative to SAS and Mathematica.

Oddly in biology I’m seeing an uptick in R use as it’s easier to install and run tools in R for non programmers. The python 2/3 confusion (why doesn’t this google result work?), and various install packages (conda/pip...) seem to have made R more popular. This is despite biopython which is quite good. The newest single sell rna seq analysis tools are in R. R is a strang thing to me, though it has its moments (graphin…

pandas gives base R a run for its money, but I find the multi-indexing really confusing, and R tidyverse is just way way nicer than pandas.

The sentiment that R is easier than python to install/manage is common among some R users but I disagree. With R I'm constantly facing dependency hell problems -- one package wants an old version of R, while another needs the newest. Conda/venv solves this problem very nicely in python.

Recently lI've been using Julia more and really like it. One nonstandard case where I've found it really shines is parsing large bioinformatics data, such as pileup files. Python is just so slowww here, but neither do I want to write a C program to do the text parsing. Julia is perfect in this case.

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

#229

Post by civility »

steveklabnik wrote: post #219
civility wrote: post #217

Earlier quoted context omitted.

> Yes and no; Steve, this is a cop out. There's nothing in Rust that can't be implemented in C or any other Turing complete language, including stack unwinding, invoke, or anything else. It may be inconvenient for Rust to use or not-use some feature of LLVM, but that's not the same thing.

I think you mean well with this comment, but you're thinking about it incorrectly. Imagine that it's possible to implement these features in the FastISel subset; okay, we do that. Now, we're generating way more code. So we're back to square one. Being able to implement something does not mean that by implementing it a different way, it will certainly be faster. And that's what we're talking about here, compilation sp…

What feature of Rust requires elaborate features or massive amounts of code? C++ has stack unwinding, you can implemented dynamic dispatch in C with function pointers, and Rust's match isn't that much above a switch statement. Both C and C++ on top of LLVM compile much more quickly than Rust.

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

#230

Post by civility »

Tomte wrote: post #218
civility wrote: post #217

Earlier quoted context omitted.

> Yes and no; Steve, this is a cop out. There's nothing in Rust that can't be implemented in C or any other Turing complete language, including stack unwinding, invoke, or anything else. It may be inconvenient for Rust to use or not-use some feature of LLVM, but that's not the same thing.

Turing-completeness is – as always – a red herring. Sure, I can technically use Assembler to write a modern Windows program, but that's no argument against high-level languages.

Yes, forgive me for using logic. I should stick to writing snarky comments like yours...

Rust is a compiler. It needs to make machine language somehow. No one suggested writing assembly or machine language directly, but at least if they did, then they wouldn't be able to play a shell game and point their fingers at everything but the actual problem.

Post reply on HN