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

311–320 of 346 posts

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

#311

Post by 0xdeadb00f »

Annatar wrote: post #307
tannhaeuser wrote: post #97

Earlier quoted context omitted.

You probably mean the POSIX shell [1] ;) I never understood why folks venture into bashisms for no or little gain (bash isn't even the default shell on Debian/Devuan), or would invent/use entire new languages with singleton implementations such as Perl in the 1990s or Python in the 2000s (other than for fun, of course). Note that Python is actually a descendant of the ABC programming language developed to be human-fr…

No, I don't "probably" mean POSIX, if I write Bourne and Korn shell, then that is what I mean! I grew up on real UNIX operating systems, not the GNU/Linux cheap knockoff! Boy do statements like these make me furious!

What do you have against POSIX sh? Unless I'm mistaken, it's compatible with both the GNU/Linux knockoff and Unix (*BSD, etc).

I prefer it to Korn and Bourne because it's compatibility is so widespread.

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

#312

Post by Annatar »

0xdeadb00f wrote: post #311
Annatar wrote: post #307

Earlier quoted context omitted.

No, I don't "probably" mean POSIX, if I write Bourne and Korn shell, then that is what I mean! I grew up on real UNIX operating systems, not the GNU/Linux cheap knockoff! Boy do statements like these make me furious!

What do you have against POSIX sh? Unless I'm mistaken, it's compatible with both the GNU/Linux knockoff and Unix (*BSD, etc). I prefer it to Korn and Bourne because it's compatibility is so widespread.

I have nothing at all against POSIX, but unless one is running HP-UX, Solaris or an illumos-based OS like SmartOS, POSIX compliance is spotty at best in other operating systems.

For this reason, the safest thing to do is write code for either the original Bourne shell, or ksh. Programs written in ksh are the most portable across systems, moreso since other systems have it too. And to top it all off, ksh sets the standard for POSIX, especially ksh93.

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

#313

Post by bayesian_horse »

vram22 wrote: post #226
bayesian_horse wrote: post #79

Earlier quoted context omitted.

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.

"Very independent" doesn't mean totally independent. In particular Go doesn't do shared libraries.

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

#314

Post by bayesian_horse »

jimktrains2 wrote: post #223
bayesian_horse wrote: post #71

Earlier quoted context omitted.

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.

No, that was explicitly true across languages. That the number of bugs increases with code length within a particular language is a trivial fact.

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

#315

Post by pdimitar »

yawaramin wrote: post #253

Folks may also be interested in a thorough analysis of porting a big Python app (0install) to OCaml, after considering various alternatives like Rust and Haskell: http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...

Thank you for that. I'm very interested in people's stories when migrating to OCaml. Do you have more?

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

#316

Post by joshvm »

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?

Lots of public APIs support this behaviour, it's convenient for users. For example numpy.fromfile will accept a file object or a string.

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

#317

Post by 3pt14159 »

mlthoughts2018 wrote: post #128
yakshaving_jgt wrote: post #23

I share the author's sentiment, and it's what lead me to Haskell. It's faster and cheaper for me to write prototypes in Haskell than it ever was in Ruby. And at least in startup-world which is the bulk of my career, the speed at which you can build a reasonably robust prototype can be the life or death of a business, and this prototype usually ends up being the production product anyway. Prototypes are seldom rewritt…

I’ve worked professionally in Haskell across three jobs (one huge corp, two start-ups), and seeing how bad Haskell functions in practice, when quickly mutating state to incrementally modify behavior is live-or-die necessary and under constant business pressures from product managers who don’t care about the paradigm of the backend. I’ve found so many unexpected runtime errors in Haskell, behavioral bugs that require…

Hey mlthoughts2018, I've noticed a number of your comments have been exactly on the mark, even if they've been downvoted. I know you don't have your email in your profile, but if you'd like to discuss some ideas I have that aren't fully baked yet I'd appreciate your insight.

I'm zachaysan@gmail.com if so. If you're not (or too busy, etc) that's totally understandable. Don't feel like you need to explicitly decline.

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

#318

Post by yawaramin »

pdimitar wrote: post #315
yawaramin wrote: post #253

Folks may also be interested in a thorough analysis of porting a big Python app (0install) to OCaml, after considering various alternatives like Rust and Haskell: http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...

Thank you for that. I'm very interested in people's stories when migrating to OCaml. Do you have more?

That's the biggest one I have :-) but you may also find this interesting: https://www.reddit.com/r/elm/comments/ac7n3e/philip2_an_elmt...

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

#319

Post by Annatar »

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…

"And that's what we're talking about here, compilation speed, not computational equivalence."

I believe the original poster meant generated code when (s)he wrote about compiler performance; the compile time is rather irrelevant for something that gets done once; what's relevant is the speed of the generated code which then runs the next billion times (or more).

So let's get back to the performance of the code generated by the Rust compiler, shall we?

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

#320

Post by steveklabnik »

Annatar wrote: post #319
steveklabnik wrote: post #219

Earlier quoted context omitted.

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…

"And that's what we're talking about here, compilation speed, not computational equivalence." I believe the original poster meant generated code when (s)he wrote about compiler performance; the compile time is rather irrelevant for something that gets done once; what's relevant is the speed of the generated code which then runs the next billion times (or more). So let's get back to the performance of the code generat…

That performance is mostly really good at the moment. There's some things to do, but we're already roughly at the same place C and C++ are.
Post reply on HN