Live data from Hacker News

Rust – A hard decision pays off

pinecone.io

111–120 of 386 posts

Re: Rust – A hard decision pays off

#111

> Dev velocity, which was supposed to be the claim to fame of Python, improved dramatically with Rust. I don't doubt this in the least. I've been a professional Python developer for 15 years, and I can't believe Python ever had the reputation for "high dev velocity" beyond toy examples. In every real world code base I've worked in, Python has been a strict liability and the promise that you can "just rewrite the slow…

> Use Go if you're looking for an easy GC language with max productivity and a decent performance ceiling. Use Rust if you're writing really high performance or correctness-is-paramount software. I'd add one more addition to use Rust (speaking from an ex-Go dev): Use Rust if you want a robust std lib. Go is good, i used it for ~5 years, but man Rust was a breath of fresh air with the amount of tooling that helped me…

When performance and correctness are paramount, I personally stick to Ada/SPARK. Proven to be perfect for the job, and to be honest, Rust is quite a difficult language and I am not sure it is worth learning it considering that Ada/SPARK ticks all boxes when it comes to both low-level and high-level programming for critical systems.

Re: Rust – A hard decision pays off

#112
post #55

This doesn't surprise me and matches my own experience. Rust literally makes a codebase nearly void of most bug classes with the exception of logic bugs (Unfortunately, in a huge codebase, there can still be tons and tons of logic bugs). Still, when I migrated my Python codebase to Rust I got rid of whole classes of bugs and honestly code faster in Rust on a "per debugged line of code" basis. In Python, every line MU…

That’s why Elixir developers like to make NIF callouts with Rust. It’s dangerous to do anything outside of the BEAM but Rust negates all of those concerns.

Is it possible to use Ada instead of Rust?

Re: Rust – A hard decision pays off

#113

> We decided to move our entire codebase to Rust (and Go for the k8s control plane). > there was still one minor problem - no one on the team knew Rust. Is this real or satire? I can't tell.

How hard can it be for C/C++ devs to learn Rust? Python devs on the other hand..

That's not the point. If no one knows the language, no one knows if it's appropriate. All you know is the language marketing claims

Re: Rust – A hard decision pays off

#114

> Dev velocity, which was supposed to be the claim to fame of Python, improved dramatically with Rust. I don't doubt this in the least. I've been a professional Python developer for 15 years, and I can't believe Python ever had the reputation for "high dev velocity" beyond toy examples. In every real world code base I've worked in, Python has been a strict liability and the promise that you can "just rewrite the slow…

Docker is built with Go. Compare doing things with Docker api between Go and Python. I usually recommend people to "script" things with Go but I start to think that Go has to go... https://docs.docker.com/engine/api/sdk/examples/

Wow. That's quite something. I like Go, but more often than not I keep stumbling upong these kind of situations (N LOC to do something in Y, 10xN to do it in Go).

Re: Rust – A hard decision pays off

#115

> Dev velocity, which was supposed to be the claim to fame of Python, improved dramatically with Rust. I don't doubt this in the least. I've been a professional Python developer for 15 years, and I can't believe Python ever had the reputation for "high dev velocity" beyond toy examples. In every real world code base I've worked in, Python has been a strict liability and the promise that you can "just rewrite the slow…

Agreed. I still give Python credit for allowing us to write software in an extremely efficient way. But after I wrote the initial version of the software with Python, I always procrastinate on testing, fixing existing issues, and as the software grows larger I simply want to give up as the different issues keep piling up. In comparison, Rust code usually just works out of the box due to the error handling and type sy…

Don't you find thinking about the borrow checker unnecessary overhead while prototyping?

Re: Rust – A hard decision pays off

#116
post #72

Earlier quoted context omitted.

I think this is a bit unfair. As always, blanket statements in software engineering aren't really meaningful. As I understand it, the article talks about switching from python to rust in a non-trivial database service that is required to be fast and robust. I can't imagine python to do well in this regard, especially when C/C++ extensions are required to enhance the performance. I also agree that 'Python has been a s…

> As I understand it, the article talks about switching from python to rust in a non-trivial database service that is required to be fast and robust. I can't imagine python to do well in this regard, especially when C/C++ extensions are required to enhance the performance. The article specifically talked about following the conventional Python advice to use C/C++ for the fast parts and Python for the "glue". This is…

> I think it's incredibly reckless to start a new commercial project in Python in almost all cases...

> I don't usually make blanket statements, but Python really is so bad that this is a blanket statement I'm pretty comfortable with.

Speaking as someone who agrees with you that something static is very likely better than python for a large project, how do you square this with the existence of a lot of Python projects, even "very commercial", that seem to go on just fine?

It's a fine theory and something I instinctively support, but I don't see measurable evidence in support of it.

Re: Rust – A hard decision pays off

#117

Earlier quoted context omitted.

Credit where credit is due: Rust has done a far better job than most of free-riding on Haskell’s type class system and clang’s optimizer, but rust-analyzer is a dumpster fire next to clangd, that’s not an example I’d use.

I haven't used clangd since the early days, but rust-analyzer hasn't been anything other than reliable for me (which is pretty impressive considering how often Rust changes as a language and how new rust-analyzer is).

I would respectfully submit that time spent pushing your toolchain from more than one direction confers many benefits, of which a realistic appraisal of the strengths and weaknesses of the various tooling options is but one.

Re: Rust – A hard decision pays off

#118
post #96

Earlier quoted context omitted.

> I've heard generally good things about TypeScript, but I'd be concerned about its performance even if it is better than Python I wouldn't recommend Typescript for CPU-bound tasks, but for I/O-bound tasks with complicated business logic it's type system is on the order of magnitude better than Go, and makes you able to get really close to the "make invalid states of the system a type error" ideal of functional langu…

I am launching my startup on Typescript (backend and frontend). So far, it's been an amazing experience - I can define the problem in terms of types even before I start writing any executable code, and refactoring is a breeze if you make your types hard enough. There are mature libraries, you can share code between the two sides, infinite options for PaaS providers who can "just deploy" a typescript codebase. As a so…

> I just fucking really hate Go.

As a Go fanboy, this made me chuckle. :)

> I can't explain it, but I find the language infuriating. It somehow manages to be less expressive, more verbose and more straight up boring than all the other options.

I sort of get it. I think people fixate too much on the for loops and the `if err != nil` boilerplate, but there's definitely some validity with respect to "how to properly annotate errors" and emulating enums (in the Rust sense of the word) is pretty error prone and it still doesn't get you exhaustive pattern matching.

The stuff I like about Go:

* Single static, native binaries - being able to just send someone an executable is pretty nice, not needing to make sure people have the right libs and runtime installed is phenomenal.

* Great tooling. I love that the Go tool takes a list of dependencies. Unlike Gradle/CMake/etc I don't have to script my own build tool in a crumby/slow imperative DSL.

* Compilation speed. Go compiles really fast.

* Small language, easy learning curve. Any programmer can read just about any Go project with very little experience. Any Go programmer can jump into any other Go project and be productive immediately (no extensive configuration of IDE or build tools or anything like that). You can also write surprisingly abstract code without reaching for generics, but you will likely have to change your programming habits.

* Value types done right. Most other mainstream languages don't have them, and the ones that do very often implement them poorly (e.g., IIRC in C# you can define a type as a struct or a class and only structs can be value types, and classes are more idiomatic).

* Go eschews inheritance and prefers data-oriented programming over object-oriented programming (although OOP is poorly defined and some people think it means "anything with dot-method syntax").

* I'm just more productive in Go than any other language

Stuff I don't like about Go:

* No enums

* I wish there were fewer tradeoffs between abstraction and performance

* Needs a better system for annotating errors

* Doesn't run on embedded systems (although I've heard good things about TinyGo)

* Doesn't make me feel as clever (this is a nice property for professional software development, but for hobbies not so much)

On balance, I think Go is the better language, but I can also understand why it chafes people. Different strokes. :)

Re: Rust – A hard decision pays off

#119
post #114

Earlier quoted context omitted.

Docker is built with Go. Compare doing things with Docker api between Go and Python. I usually recommend people to "script" things with Go but I start to think that Go has to go... https://docs.docker.com/engine/api/sdk/examples/

Wow. That's quite something. I like Go, but more often than not I keep stumbling upong these kind of situations (N LOC to do something in Y, 10xN to do it in Go).

In addition to a emulating certain teachers dogged insistence of making sure students can't have nice things (an absolute no-brainer feature like generics only showed up recently...!), last time I tried to use Go for a web project a few years ago I was also amused by the lack of templating libraries - the way to make pages was to string together header + main + footer, the old PHP way...! Not a single library supported template composition.

Re: Rust – A hard decision pays off

#120

> Dev velocity, which was supposed to be the claim to fame of Python, improved dramatically with Rust. I don't doubt this in the least. I've been a professional Python developer for 15 years, and I can't believe Python ever had the reputation for "high dev velocity" beyond toy examples. In every real world code base I've worked in, Python has been a strict liability and the promise that you can "just rewrite the slow…

> Use Go if you're looking for an easy GC language with max productivity and a decent performance ceiling. Use Rust if you're writing really high performance or correctness-is-paramount software. I'd add one more addition to use Rust (speaking from an ex-Go dev): Use Rust if you want a robust std lib. Go is good, i used it for ~5 years, but man Rust was a breath of fresh air with the amount of tooling that helped me…

I actually don't care as much for iterators as I thought I would. Beyond some simpler map().reduce() stuff they tend to fall over pretty fast, and I end up spending too much time trying to make iterator chains work before defaulting to for loops. I also dislike how anemic Rust's stdlib is. I'm sure there are good reasons, but I like that I can just reach for Go's stdlib for annotating errors or dealing with JSON. Other than that, I like the API design in Rust's stdlib.

Here's an example where the iterator-chain version is way more complex:

    let posts = read_dir(source_directory)?
        .filter_map(|result| {
            (|| {
                let entry = result?;
                let os_file_name = entry.file_name();
                let file_name = os_file_name.to_string_lossy();
                if Self::is_bundle(&entry)? {
                    self.parse_post_bundle(&file_name, &entry.path())
                        .map(Some)
                } else if file_name.ends_with(MARKDOWN_EXTENSION) {
                    self.parse_post(
                        file_name.trim_end_matches(MARKDOWN_EXTENSION),
                        &mut File::open(&entry.path())?,
                    )
                    .map(Some)
                } else {
                    Ok(None)
                }
            })()
            .transpose()
        })
        .collect::>>()?;
Here's the imperative version:

    let mut posts = Vec::new();
    for result in read_dir(source_directory)? {
        let entry = result?;
        let os_file_name = entry.file_name();
        let file_name = os_file_name.to_string_lossy();
        if Self::is_bundle(&entry)? {
            posts.push(self.parse_post_bundle(&file_name, &entry.path())?);
        } else if file_name.ends_with(MARKDOWN_EXTENSION) {
            posts.push(self.parse_post(
                file_name.trim_end_matches(MARKDOWN_EXTENSION),
                &mut File::open(&entry.path())?,
            )?);
        }
    }
Post reply on HN