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

311–320 of 386 posts

Re: Rust – A hard decision pays off

#311

Post by linsomniac »

tlrobinson wrote: post #234
peterkelly wrote: post #223

Earlier quoted context omitted.

A lot of people seem to believe that dynamically typed languages make development easier, because you don't have to worry about writing type annotations or going through the extra steps to fix compile-time errors. This is arguably true for small scripts, but for anything non-trivial I find that static typing means I can be more productive, because type errors are caught straight away (rather than potentially in produ…

> I find that static typing means I can be more productive, because type errors are caught straight away I agree completely. I feel like there’s a pretty common arc among programmers: 1. learn to program using verbose statically typed languages 2. discover fun dynamically typed languages, eschew statically typed languages 3. discover dynamically typed languages are a shitshow for large real-world projects 4. re-disco…

The thing I like about Python is that I can decide, even on a line-by-line basis, but more likely on a program by program basis, if it makes sense to be type oblivious, or type checked.

Re: Rust – A hard decision pays off

#312

Post by [deleted] »

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…

[deleted]

Re: Rust – A hard decision pays off

#314

Post by throwaway894345 »

MauranKilom wrote: post #303
nomel wrote: post #298

Earlier quoted context omitted.

I clearly said the opposite, in response to, what appeared to be, your suggestion that indexing isn't so bad: "I think people make too big a deal about iterators. The simple for loops that they’re fit to replace aren’t that hard to read or write, so they aren’t causing real problem"

It seems like you imply that iterators = range-for and "simple loops" = indexing, which is clearly not what the previous poster has in mind (which was "range-for = imperative loops, iterators = functional style, simple loops = trivial loop body").

Yes, I was responding to:

> I disagree. If I can avoid an index variable, I’m going to have less bugs since I won’t have to index

Which (given thread context) sounds pretty clearly like he's advocating against `for item in iterator {...}` and in favor of iterator chains. If there's another way of reading that comment, I'm not seeing it. :)

Re: Rust – A hard decision pays off

#315

Post by agumonkey »

Gigachad wrote: post #271
agumonkey wrote: post #152

Earlier quoted context omitted.

Started a small project with rust and serde(toml config). Having static checking of config an its parsing felt really good.

We started just writing configs in typescript which has the benefit of static checking in your editor with suggestions/underlines. Could likely do the same in rust.

I'm afraid by typescript "typesystem" even more so than rust borrows/lifetime. It's so versatile and stringy .. that said it's still good to have some.

Re: Rust – A hard decision pays off

#316

Post by agumonkey »

cmrdporcupine wrote: post #65
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…

Yes re: Python. Story -- I was a very early adopter of Python, back in the mid-90s. When other people wrote their CGI scripts in Perl, I always reached for Python. The first paid gig I ever had was a CGI script ("resume builder") I wrote in Python in 1996. But almost nobody was using it back then, and I'd get quizzical stares from people in job interviews etc. when it came up. So for many years back then I really rea…

I read "CGI" as computer generated imagery, python was a strong glue language in this field in the 90s.

Also I think people misread 'python speed', few c++ masters said it was more about prototyping to converge on good overall design rather than suffering the efforts of early iterations in c++ (90s c++).

Re: Rust – A hard decision pays off

#317

Post by Gigachad »

agumonkey wrote: post #315
Gigachad wrote: post #271

Earlier quoted context omitted.

We started just writing configs in typescript which has the benefit of static checking in your editor with suggestions/underlines. Could likely do the same in rust.

I'm afraid by typescript "typesystem" even more so than rust borrows/lifetime. It's so versatile and stringy .. that said it's still good to have some.

What I'm proposing is rather than have Rust validate yaml/toml files, just write the actual config itself in Rust so that your editor can verify/show issues before running. Unless you require ability to edit configs without recompile.

Re: Rust – A hard decision pays off

#318

Post by faitswulff »

nazka wrote: post #253
jhgg wrote: post #159

Writing Rust at scale, I concur with some of these findings. Nowadays, my team exclusively writes Rust. Our rationale is two-fold. 1) We want to write software that is fast and inexpensive to run. Our rust services are quickly growing, but cumulatively, they remain in the sub-1000 core count, while processing many millions of requests per second across our service with excellent latency. 2) We want to write software…

I am curious which web framework do you use? Also do you use an ORM like diesel?

You could probably get a pretty good idea from reading the Discord engineering blog.

Re: Rust – A hard decision pays off

#319

Post by throwaway234566 »

Thaxll wrote: post #203
lijogdfljk wrote: post #77

Earlier quoted context omitted.

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

Rust std lib is subpar compared to the Go one, yes you have iterators but that's it, basic things like async are not even provided just the interface so everyone has to use tokyo. Then for real use cases you're missing http/json/compression/crypto etc ... https://pkg.go.dev/std Overall tooling and std lib are better on Go, actually there are not many languages that are on part with Go to that regard. When you see wha…

Agreed 100%.

Go doesn't have a standard library problem, it has a userland language problem.

* No sum types / algebraic data types in 2022.

* No exhaustive pattern matching in 2022

* No move semantics / Uses GC

* No borrow checker

* Still suffers from nil problem / No type-safe nil / No type-safe Optionals in 2022 -- (I can show you all the nil panics in kubernetes logs if you like)

Current go users are already sold so they don't expect more, and that's fine, but further evangelism will require a better host language.

Re: Rust – A hard decision pays off

#320

Post by kelnos »

wooque wrote: post #206
wazzaps wrote: post #147

Earlier quoted context omitted.

If your main concern is security bugs, then according to Microsoft[0] about 70% of their bugs were memory-safety related. [0]: https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...

Most people don't write operating systems or write software in C/C++, so memory safety bugs are not big concern.

> ... or write software in C/C++

The article we've all supposedly read (but clearly some have not) is specifically talking about software written in a mix of C/C++ and Python.

Post reply on HN