Live data from Hacker News

Ask HN: What Are Downsides of Rust Language?

news.ycombinator.com

21–22 of 22 posts

Re: Ask HN: What Are Downsides of Rust Language?

#21
post #19
post #17

Earlier quoted context omitted.

There are a few new languages competing for the title of “better Python,” i.e., a language with Python-inspired syntax, optional typing, and native compilation. Julia is trying to be a “better Python” for mathematical and scientific computing, and Nim is aiming to be a better general purpose Python. Nim predates Julia by a few years, but there’s a lot of excitement around Julia these days.

I've tried both and I don't think they are better than Python. For one, they don't do integer arithmetic correctly by default: julia> 2^64 -9223372036854775808 To me, that is simply not ok. The point of HLLs is that details like sizes of hardware registers shouldn't matter.

Python uses arbitrary-precision integers by default, unless you use Numpy, in which case you end up with the same issue. It also uses machine floats by default, which can give similar errors (so one could say "Python doesn't do real arithmetic correctly by default", though of course neither does anyone else).

So it's not that your point isn't valid, but it can't be extrapolated to general safety or high-level-ness; this is a really specific feature to rest your decision on. Arguably Julia has an advantage here because you can easily check correctness of an algorithm using arbitrary precision types and then use machine types in production, which is pretty handy.

Re: Ask HN: What Are Downsides of Rust Language?

#22
post #19

Earlier quoted context omitted.

I've tried both and I don't think they are better than Python. For one, they don't do integer arithmetic correctly by default: julia> 2^64 -9223372036854775808 To me, that is simply not ok. The point of HLLs is that details like sizes of hardware registers shouldn't matter.

Python uses arbitrary-precision integers by default, unless you use Numpy, in which case you end up with the same issue. It also uses machine floats by default, which can give similar errors (so one could say "Python doesn't do real arithmetic correctly by default", though of course neither does anyone else). So it's not that your point isn't valid, but it can't be extrapolated to general safety or high-level-ness; t…

Integer overflow is one type of bugs that can lead to catastrophic failures. Think billing systems that suddenly starts paying customers rather than charging them or rockets firing in the opposite direction. Therefore I think you can say that Python is safer because it prevents one class of bugs that these languages doesn't.

Another reason for saying so is because it's an example of performance meeting safety. Julia, Nim and Rust choose performance, ostensibly to score well on benchmarks which I think is irresponsible. Python choose safety which I prefer. In the future, these languages will again choose performance ("zero-cost abstractions") to preserve their benchmark rankings over essential safety and programmer ergonomics. Another area in which these languages make compromises for performance is in the legibility of stack traces.

It is true that Python doesn't do fractional arithmetic correctly which I think is a flaw. Newer languages should use rational arithmetic by default. 6/5 - 1 should evaluate to 1/5 not 0.19999999999999996.

Post reply on HN