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

191–200 of 386 posts

Re: Rust – A hard decision pays off

#191

Post by reitanqild »

coder543 wrote: post #136
reitanqild wrote: post #119

Earlier quoted context omitted.

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

Umm... what are you even talking about? Go has had templating built into the standard library since... forever? And Go templates can use other templates, as long as they're all loaded into the same context, if that's what you were getting at. simple examples of Go's built-in templates: https://gowebexamples.com/templates/ templates using other templates: https://levelup.gitconnected.com/using-go-templates-for-effe...

That doesn't look too bad on a quick glance, but the possibility to say that "this content goes in that template" still seems to be missing.

Look at this page: https://quarkus.io/guides/qute-reference

and read about “Template inheritance” in 3.5.6 to see what I mean.

Re: Rust – A hard decision pays off

#193

Post by masklinn »

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.

> 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 it just removes entire swathes of edge cases. See concepts like "making invalid states unrepresentable".

[0] though it's still lacking in many ways, the more you get the more you want after all

Re: Rust – A hard decision pays off

#194

Post by _benj »

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…

Also, +1 for Go. I think that one of the things that makes Rust and Go such great language is how strict their compilers are. This moves the cognitive load of writing same code from the developer/team, to the compiler.

Go is also simpler because of the GC, given that Rust can get a bit tricky with lifetimes. Go routines and channels are a delight to use together with contexts.

Rust allows for a lot more ways to solve one problem, i.e. you can iterate over an array, of use a loop. Go only provided a for loop and that is pretty much the only way to iterate over something.

Some people might find this limiting but I find it refreshing given that I can focus on what I need to do instead of how I should do it.

Re: Rust – A hard decision pays off

#195

Post by HeyImAlex »

lowbloodsugar wrote: post #158
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…

I would recommend Rust even if writing a simple tool, the kind of thing I might previously have used python for. We had some data munging to do and someone started it in python. On the real dataset it ran for an hour then ran out of memory. I took a crack in rust, as a n00b rust programmer, and the rust version runs successfully in less than a minute. I haven’t tried server side yet, because the learning curve for th…

I had the same experience with go, 100x performance improvements on data crunching scripts with roughly the same code. Worst part of writing it in python was simple misspellings in the last stages of the computation breaking things.

Re: Rust – A hard decision pays off

#196

Post by nu11ptr »

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.

To some extent, possibly, but it is a very rich type system, and does not have null which in and of itself gets rid of a set of errors. I also find Rust culture tends to be more guarded on panicking due to having such a rich error type (Result), so panic is reserved for the worst possible "can't continue" scenarios (unlike languages with unchecked exceptions). Also, enum pattern matching is exhaustive which gets rid of errors where you simply don't account for new variants. The list goes on and on.

Re: Rust – A hard decision pays off

#197

Post by [deleted] »

blueslurpee wrote: post #178
xmonkee wrote: post #96

Earlier quoted context omitted.

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…

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.

[deleted]

Re: Rust – A hard decision pays off

#198

Post by nu11ptr »

AndyMcConachie wrote: post #183
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…

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 exceptions in java so now everyone makes new exceptions unchecked. I would say this is not because people disliked the idea of ensuring errors were handled, but the verbosity required to do so meaningfully was annoying, so people took shortcuts to avoid pain by wrapping in unchecked exceptions and in the process introduced "exceptions gone wild" (and now everyone who runs a known java app is familiar with the exception stack trace in logs and in the console).

Re: Rust – A hard decision pays off

#199

Post by fb03 »

Would you guys start a GraphQL Api today using Rust? I'm very tempted to hint at that but am still insecure about my 'options'. This is coming from a very comfortable python + fastapi + sqlalchemy ecossystem

Re: Rust – A hard decision pays off

#200

Post by adamdusty »

moonchrome wrote: post #28
endisneigh wrote: post #7

Maybe it’s just me but it seems irresponsible to move your entire team to a programming language none of them knows. Rust is great, but modern C++ is great too.

>but modern C++ is great too. No, modern C++ is still cobbled together from tools built in a different era. It doesn't even come with a package manager/build system. Just on the fact that cargo/crates.io exist and it has modules - it would have to be really bad to make me go back to C++ if I ever need to write something at that level.

There are package managers and build systems. MS ships a build system with visual studio and msvc and they have a fairly capable package manager in vcpkg.

I like cargo better than any c++ tooling but those tools don't really make a ton of sense for c++ where every platform has a different compiler.

Ultimately, I agree. I don't think I'll be going back to c++ any time soon, but for me it's more about the tooling fragmentation than the tooling itself. I actually like the language itself.

Post reply on HN