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

321–330 of 346 posts

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

#321

Post by Annatar »

steveklabnik wrote: post #320
Annatar wrote: post #319

Earlier quoted context omitted.

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

...Which means you have lots of ground to cover before you reach parity with Fortran (phase 1), and then reach parity with CUDA Fortran (phase 2).

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

#322

Post by pdimitar »

yawaramin wrote: post #318
pdimitar wrote: post #315

Earlier quoted context omitted.

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

That's actually super interesting. Had no idea there was a way to migrate from Elm to OCaml JS dialects so easily! Thanks.

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

#323

Post by vram22 »

bayesian_horse wrote: post #313
vram22 wrote: post #226

Earlier quoted context omitted.

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

Cool, thanks.

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

#324

Post by rujuladanh »

apta wrote: post #291
rujuladanh wrote: post #247

Earlier quoted context omitted.

Neither Rust nor C++ eliminate logic bugs (and no language can do that). If you are writing code that must work, you should be either formally prove the system (if feasible) or have a huge test suite covering everything.

> Neither Rust nor C++ eliminate logic bugs (and no language can do that). While true, it's a big benefit to eliminate classes of known bugs (e.g. memory safe languages eliminate undefined behaviors, and Rust eliminates data races). That allows the programmer to pay attention to other aspects of the code, since there's only so much energy one person can spend.

No. If a system MUST work, then there have to be no bugs at all. Removing a class is useless. You have to remove all bugs.

You are talking about systems that SHOULD work, but aren’t required to always work. Typically, safety-critical software is the latter, the rest of software is the former. But the latter are entirely different beasts, and is what we were discussing.

By the way, Rust does not eliminate all race conditions; and memory safe languages may still have undefined behavior unrelated to memory (e.g. Rust)

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

#325

Post by civility »

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…

If Rust didn't have good runtime performance, it wouldn't be worth looking at over SML, Ocaml, or Haskell.

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

"Shall we" just stick our heads in the sand too? No, you don't fix problems by ignoring them or pretending they aren't a problem. Slow compilation speed is a problem if you care about developer productivity and quality of life.

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

#326

Post by civility »

Annatar wrote: post #321
steveklabnik wrote: post #320

Earlier quoted context omitted.

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.

...Which means you have lots of ground to cover before you reach parity with Fortran (phase 1), and then reach parity with CUDA Fortran (phase 2).

You're working from old information. Show me a benchmark where Fortran wins over C or C++ any more. Those days are gone. Here's my line in the sand:

    https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/fortran.html
As for GPUs, no contest.

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

#327

Post by Annatar »

civility wrote: post #325
Annatar wrote: post #319

Earlier quoted context omitted.

"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…

If Rust didn't have good runtime performance, it wouldn't be worth looking at over SML, Ocaml, or Haskell. > So let's get back to the performance of the code generated by the Rust compiler, shall we? "Shall we" just stick our heads in the sand too? No, you don't fix problems by ignoring them or pretending they aren't a problem. Slow compilation speed is a problem if you care about developer productivity and quality o…

Slow compilation speed is never a problem, I doubt anyone besides you cares about it. What is important is whether it generates fast code. Taking a long time to compile is fine if I get very fast code. I'm not going to be compiling code anywhere near as many times as I'm going to be running it.

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

#328

Post by Annatar »

civility wrote: post #326
Annatar wrote: post #321

Earlier quoted context omitted.

...Which means you have lots of ground to cover before you reach parity with Fortran (phase 1), and then reach parity with CUDA Fortran (phase 2).

You're working from old information. Show me a benchmark where Fortran wins over C or C++ any more. Those days are gone. Here's my line in the sand: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/fortran.html As for GPUs, no contest.

Benchmarks are meaningless. I know from experience at looking at the generated assembler code and intel Fortran's SIMD code that it's faster. Take a look at the generated code and then we can discuss it, but not before.

I'm not going to beat myself in C when I calculate a 100 million by 100 million matrix in Fortran. ifort will generate SIMD code with CPU autodetection and use machine code seqencing best for that processor, plus in Fortran a matrix is a normal variable type like any other. I'm not beating that with C (and I really know C).

And just so you know, my information isn't old, I come from supercomputing.

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

#329

Post by civility »

Annatar wrote: post #328
civility wrote: post #326

Earlier quoted context omitted.

You're working from old information. Show me a benchmark where Fortran wins over C or C++ any more. Those days are gone. Here's my line in the sand: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/fortran.html As for GPUs, no contest.

Benchmarks are meaningless. I know from experience at looking at the generated assembler code and intel Fortran's SIMD code that it's faster. Take a look at the generated code and then we can discuss it, but not before. I'm not going to beat myself in C when I calculate a 100 million by 100 million matrix in Fortran. ifort will generate SIMD code with CPU autodetection and use machine code seqencing best for that pro…

> Benchmarks are meaningless.

Random anecdotes are meaningless. I've looked at plenty of generated code, and I've written plenty of SIMD assembly too. If you can't measure it, you can't compare it or improve it. There's nothing to discuss.

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

#330

Post by civility »

Annatar wrote: post #327
civility wrote: post #325

Earlier quoted context omitted.

If Rust didn't have good runtime performance, it wouldn't be worth looking at over SML, Ocaml, or Haskell. > So let's get back to the performance of the code generated by the Rust compiler, shall we? "Shall we" just stick our heads in the sand too? No, you don't fix problems by ignoring them or pretending they aren't a problem. Slow compilation speed is a problem if you care about developer productivity and quality o…

Slow compilation speed is never a problem, I doubt anyone besides you cares about it. What is important is whether it generates fast code. Taking a long time to compile is fine if I get very fast code. I'm not going to be compiling code anywhere near as many times as I'm going to be running it.

You really think it's just me? Take care.
Post reply on HN