Hacker News new | ask | show | jobs
by bjourne 2558 days ago
Rust is criticized on in too, but you can't read the criticism because it's downmodded to the background color. ;)

For me, Rust fundamentally doesn't offer anything that 1) I want and 2) Python doesn't already have. The language I want is a better version of Python, not a better version of C++.

4 comments

Criticisms aren't downsides though, imo. I'd imagine downsides are more objective, less subjective.

Eg, Rust often gets criticized for it's Syntax (rather, lots of it, ::<>, etc.). Yet, this isn't a downside in Rust, it's merely an opinion.

I'd be curious though what you think these downvoted into oblivion criticisms are? The ones here have been well received, and are quite fair. I'd be curious to see a criticism that's not widely agreed upon.

Hi,

Have you tried Nim? https://nim-lang.org/

Very Pythonic if you ask me.

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.
Understood; I put "better Python" in scare quotes because everyone has their own vision of what that "better X" would look like in an ideal world. Julia offers a python-like syntax but doesn't really attempt to duplicate the python developer experience.

Based on your other comments, if you're OK with a more Ruby-flavored syntax, you could look at Elixir. Its designers put a lot of effort into pervasive immutability and a solid developer experience.

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.

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.

What would you like to see in the better version of Python?
More focus on immutable data and "immutability-friendly" syntax.