Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust – A hard decision pays off

pinecone.io

Post reply on HN
Print view View original

341–350 of 386 posts

Re: Rust – A hard decision pays off

#341

Post by rob74 »

throwaway894345 wrote: post #228
rob74 wrote: post #134

Earlier quoted context omitted.

I would say in this case it's more the API designers' fault than Go's fault. Looks like the Python API is operating at a higher abstraction level than the Go API - using the Python API you can just call a "macro" that does everything required, in Go you have to call each operation individually.

It probably is Go's propensity to return error values whereas Python would bubble them up. Every action in Docker involves an I/O error at a minimum (since you're talking to the Docker daemon) so this is basically a worst-case scenario for error handling boilerplate. I don't doubt that Python is better for scripting in this case, but if you want to make an application that interfaces with Docker, Go is probably the b…

Still, creating a method that calls several other methods one after another is programming 101, so I refuse to entertain the though that creating a "containers.run" method similar to the one from the Python API is not possible in Go. The error handling is definitely not the culprit, you can check the error after each "subcommand" and return early with this error. The question is just, why didn't they do it?

Re: Rust – A hard decision pays off

#342

Post by nly »

hu3 wrote: post #324
nly wrote: post #290

Earlier quoted context omitted.

Garbage collector is still a steaming pile though

Source? I thought .NET GC was tuned for high throughput. Their performance is, impressive, to say the least. https://www.techempower.com/benchmarks/#section=data-r21

It has terrible latency characteristics

Re: Rust – A hard decision pays off

#343

Post by manholio »

s17n wrote: post #177
nu11ptr wrote: 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…

The unique safety features of Rus are all about memory safety, which is not something you have to worry about at all in Python. I can only assume that the bug classes you are referring to would have been eliminated by using essentially any language with a type system.

Rust has no exceptions and enforces correct propagation of errors at compile time. There are few if any strong typed languages in current use that offer a similar experience, for this mix of [memory safety + strong types + error correctness + close to machine performance] you would have to go to some very exotic language route.

Unlike those exotic options, Rust also comes out of the box with a very powerful free linter (clippy) which you definitely want to use, and has a wide community, library, cargo ecosystem, is very stable and tested etc.

When you total it up, you get a fast, safe program that exhibits 60-70% less runtime bugs than something written in either Python or C++ for a similar development effort. You still need to test of course, but you can focus on major integration and logic bugs instead.

Re: Rust – A hard decision pays off

#344

Post by manholio »

nu11ptr wrote: post #198
AndyMcConachie wrote: post #183

Earlier quoted context omitted.

I find exception handling in Python to be one of its weakest spots. I really like Python and I use it often. But I'm never quite sure which exceptions a library function might throw. This is rarely documented well and so you end up encountering new exceptions at run time, which is exactly when you do not want to be encountering new thrown exceptions. Usually I end up looking at source of libraries and making a list o…

I think unchecked exceptions in Python probably make sense. I think the real issue is people trying to use Python to write large systems instead of scripts. I love python for 100-500 line scripts, but beyond that the ease of use features get in the way of writing robust code. However, I think unchecked exceptions are a mistake in any language for writing _serious_ code. Interestingly, everyone hated checked exception…

Python definitely considers itself a serious language, not one intended for 500 line scripts. They have libraries supporting server creation, GUI and desktop applications etc.

It's just that in practice, the trade-offs the designers made for easy development made writing large applications next to impossible, unchecked exceptions being one of the major sources of instability. You write very fast buggy code and get excellent productivity initially, but as the program grows you fave a factorial growth of interactions between components, and, because the interface points are not well defined and checked at compile time, what you gained during development is lost under an uncontrolled torrent of subtle runtime bugs.

Re: Rust – A hard decision pays off

#345

Post by manholio »

xhevahir wrote: post #307
tralarpa wrote: post #286

Earlier quoted context omitted.

I hate that some universities teach dynamically typed languages as first language in their curriculum. I think for CS students the first language should be as "strict" (not in the mathematical sense) as possible, so the student is forced to think very carefully what is going where. This is of course a controversial opinion, especially among proponents of SICP (which is, in my opinion, not a good book for beginners. Y…

What language do you recommend for beginners?

I would go on a limb and say Rust (or more specifically, a limited dialect of it) could become a good language for beginners if:

- the compiler had better life time inference, so that you wouldn't need to annotate simple functions and introduce beginners to complex issues related to lifetimes, i.e it should "seem" to work like python, initially.

- better learning resources for absolute beginners are developed, step by step tutorial, an easy to install full IDE with friendly error messages etc.

Re: Rust – A hard decision pays off

#346

Post by formerly_proven »

elcritch wrote: post #335
blueslurpee wrote: post #178

Earlier quoted context omitted.

We have similar experiences. I absolutely love Typescript. But I don’t like Node very much. So I keep TS in the browser. I’ve been looking at Nim or Scala for the backend. It’s either that, or just dive into Rust. It really seems if you don’t want to use Node, Java, or Go the available choices for a statically typed backend get quite slim.

If you like doing compile time things with types like typescript enables then Nim is fantastic. I've been learning Rust recently and I'm continually disappointed with how little compile time or type based stuff you can do.

With prior C++ experience it's easy to equate C++ templates and Rust generics (similar syntax - usually does similar things - quack like ducks etc.); I know I did. And through this lens generics will soon seem very limited compared to templates. But the underlying reason for this is because C++ templates aren't generics - they're much closer semantically to hygienic, declarative macros. C++ templates are based around rules like SFINAE and allowing multiple alternatives and the compiler will work out which is the most-specific match that works. C++ templates (even with concepts) are unconstricted - when you give a template a type, there aren't any checks enforced by the language about the types; many templates have a list of requirements and you, the programmer, have to check them, unless the template itself has guards and checks the types.

Through this lens, the semantic equivalent of C++ templates in Rust isn't generics, but macro_rules! - but for most uses of C++ templates you would rather use generics and traits.

Re: Rust – A hard decision pays off

#347

Post by rowanG077 »

rjh29 wrote: post #270
throwaway894345 wrote: post #41

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

Having recently used it, my impression is Python's type system is pretty damn powerful. It might not be as crazy as TypeScript, but it can handle recursive types, dictionaries with a fixed set of keys, functions, union types and generics. Types can be re-used or exported. There are generic types for things like 'Iterable'. If a package does not supply its own types (increasingly rare now), you can generate stubs and…

Does it support annotating numpy arrays with their dimensions yet? Last time I checked I was incredibly surprised the status quo was basically all numpy arrays are np.ndarray.

Re: Rust – A hard decision pays off

#348

Post by rowanG077 »

s17n wrote: post #177
nu11ptr wrote: 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…

The unique safety features of Rus are all about memory safety, which is not something you have to worry about at all in Python. I can only assume that the bug classes you are referring to would have been eliminated by using essentially any language with a type system.

While the big one for rust borrowing system is memory bugs it als make it extremely specific what can be mutated. And there can only be a single mutator at any time. Unless you explicitly write something to work for multiple mutators. This makes many logic bugs much more obvious even though you could still make them.

And of course you don't have nullability which is another big one.

Re: Rust – A hard decision pays off

#349

Post by rowanG077 »

p1necone wrote: post #330
masklinn wrote: post #193

Earlier quoted context omitted.

> I can only assume that the bug classes you are referring to would have been eliminated by using essentially any language with a type system. Rust has a very expressive type system[0], which you won't otherwise find before hitting the more functional and research-y side of things. Modelling data in terms of enums (sum types), move types (affine types), etc... makes it a lot more reliable and a lot less faillible as…

Other than Rust the only other "pragmatic" language I can think of that has as much of a robust type system is Typescript. As you say anything else you'd have a hard time convincing the rest of your team to use.

Typescripts type system is anything but robust. It's escape hatch build upon escape hatch. Don't get me wrong, it has to be like that due to it allowing gradual typing and essentially beeing a superset of js.

Re: Rust – A hard decision pays off

#350

Post by krab »

rowanG077 wrote: post #348
s17n wrote: post #177

Earlier quoted context omitted.

The unique safety features of Rus are all about memory safety, which is not something you have to worry about at all in Python. I can only assume that the bug classes you are referring to would have been eliminated by using essentially any language with a type system.

While the big one for rust borrowing system is memory bugs it als make it extremely specific what can be mutated. And there can only be a single mutator at any time. Unless you explicitly write something to work for multiple mutators. This makes many logic bugs much more obvious even though you could still make them. And of course you don't have nullability which is another big one.

Due to the pain that concurrency is in Python, the codebases I've seen mostly shared data only via external processes (queues, databases).

I was very surprised to read the article. I think in the code I have in mind the borrow checker would only add overhead.

The most frequent errors I see in the Python webapp code are: 1. logic errors, especially around concurrent DB transactions, 2. type errors (missing values, improperly modeled data), 3. performance problems.

Post reply on HN