Live data from Hacker News

Rust Is Surprisingly Good as a Server Language

stu2b50.dev

241–250 of 352 posts

Re: Rust Is Surprisingly Good as a Server Language

#241
post #30

I tried Rust about a month ago. The language itself is amazing, the pattern matching is super expressive, the borrow checker is incredible in the kinds of errors it can pick up on, and rust-analyzer is leagues beyond where RLS was. But... the compile times are an absolute non-starter for me. I'm the kind of guy that likes to re-run his code continually to see if it validates to what I expect it to be doing. In Rust,…

"there must be two groups of engineers" -- possibly, but I'm both groups - with Go i'm in the obsessive build group, to the point that people hate pair programming with me, and with Rust I compile less, review more. I'm certainly not driven away.

Re: Rust Is Surprisingly Good as a Server Language

#242

Earlier quoted context omitted.

Or a language like Go, C or Nim that can compile tens of thousands of lines of code in a few seconds.

My day job is in C and compile time is 30 minutes. It really depends what you're working on.

Does it take that long for an incremental build?

Re: Rust Is Surprisingly Good as a Server Language

#243

Earlier quoted context omitted.

Yes, but you still can't write garbage collected code, which is tremendously useful in many circumstances. E.g. when using closures you really don't want to be thinking about memory allocation, and closures have proven a very useful concept. There are countless of reasons why the availability of a GC is a productivity booster. So I wouldn't describe Rust as a language that fits all domains and/or programmers well.

Isn't Rc essentially garbage collection though?

Reference counting is a form of garbage collection, but with closures you often end up with circular dependencies, which is what RC can't handle.

Re: Rust Is Surprisingly Good as a Server Language

#244
post #88
post #57

Earlier quoted context omitted.

I can feel the pain on all 5 points. One thing I did notice though is that NodeJS has such a huge breadth of packages that its _very_ hard to actually pick something good. But there is almost always an alternative that's maybe not as popular, but is a lot more "solid" alternative. For example we used SOHU-Co/kafka-node for a while as a kafka client, until we hit some bugs that made us dig through its internals and we…

I will have to take a look Slonik. I feel like I have been to hell and back with ORMs, between Sequelize, Entity Framework, Hibernate, SQLAlchemy, etc.. and frankly, I think they just cause more headaches than solve problems. I would love to have strongly typed SQL queries, but I have found that Dapper [1] fills a special place in my heart. [1] https://github.com/StackExchange/Dapper

I've been following https://github.com/adelsz/pgtyped for awhile. It should give you TS types from sql files (and even sql template literals) directly. Though I haven't used it in prod. Might be worth a look.

Re: Rust Is Surprisingly Good as a Server Language

#245

Earlier quoted context omitted.

Maybe. At the rate I hit :w, probably not :)

How do you have Vim (or neovim) set up to do that and report errors inline?

I use ALE, which I believe includes Rust by default.

https://github.com/dense-analysis/ale

Re: Rust Is Surprisingly Good as a Server Language

#246

Earlier quoted context omitted.

The thing with ownership reasoning in Rust is that you can opt out of it whenever it makes sense to do so. If you really have "objects which live for indeterminate amounts of time and can be shared across views", that's not an increase in complexity; you just acknowledge that reasoning about ownership and sharing at compile time is not going to be feasible, write Rc > (with a documentation comment to that effect) and…

Yes, but you still can't write garbage collected code, which is tremendously useful in many circumstances. E.g. when using closures you really don't want to be thinking about memory allocation, and closures have proven a very useful concept. There are countless of reasons why the availability of a GC is a productivity booster. So I wouldn't describe Rust as a language that fits all domains and/or programmers well.

> when using closures you really don't want to be thinking about memory allocation

You don't have to think about this with Rust - and you don't need a GC either. The borrow checker will make sure that your closure doesn't outlive the variables it captures, which is what you need for correctness in this case.

Re: Rust Is Surprisingly Good as a Server Language

#247
post #30

I tried Rust about a month ago. The language itself is amazing, the pattern matching is super expressive, the borrow checker is incredible in the kinds of errors it can pick up on, and rust-analyzer is leagues beyond where RLS was. But... the compile times are an absolute non-starter for me. I'm the kind of guy that likes to re-run his code continually to see if it validates to what I expect it to be doing. In Rust,…

`lld` is incredibly fast and allows medium crates to compile in under a few seconds for me. For people who don't know, if you're on linux put this in the `~/.cargo/config` file, and install the LLVM linker on your system.

```

[target.x86_64-unknown-linux-gnu]

rustflags = [ "-C", "link-arg=-fuse-ld=lld" ]

```

`-Clinker=clang` also works. I think you need a recent `gcc` (8 or newer) for `-fuse-ld=lld`. For `linker=clang` you probably need `clang` installed.

Permalink: https://reddit.com/r/rust/comments/dsfi5m/rust_2020_are_we_c...

Re: Rust Is Surprisingly Good as a Server Language

#248
post #158

Earlier quoted context omitted.

Apparently you didn't bother to read the 3 answers that come up. Only one of them says anything and it an empty statement like > F#'s compile times also seem to err on the long side but not very much so, my impression goes. However it is quite easy to validate write the same algorithm in F# and Rust and then compare. Ah but Rust is AOT compiled, easy, use NGEN, .NET Native, or Mono AOT for the F# compile time measure…

Apparently you assume that everyone’s google results are identical.

I've had a reviewer in a (scientific) journal tell me some paper is relevant, and thus I need to cite it, because it "appears on their top google results".

People should be educated on the huge bias introduced by personalized services like google.

Re: Rust Is Surprisingly Good as a Server Language

#249

Earlier quoted context omitted.

Ocaml is a somewhat fair comparison, but I have to say that Go is really in no way comparable to Rust. Rust is massively more complex.

I'd say Go is a fair comparison here. Type checking and Parsing isn't bottleneck in Rust compilation. Code generation is. LLVM is particularly heavy and while it generates optimized code, it is quite slow. Go Authors didn't pick LLVM because of compile speed reasons (as well as complexity), and that turned out to be worthwhile tradeoff.

Well, worthwhile in terms of compile times, which makes sense knowing google’s codebase. Most people aren’t compiling massive dependency trees that can’t fit on any single computer when they push a commit.

Anyway in C++ land massive compile times are just as much of a problem. Fast code is expensive. Go’s a lot of things, but being good at generating fast code ain’t one of them (looking holistically anyway).

Re: Rust Is Surprisingly Good as a Server Language

#250

Earlier quoted context omitted.

Ocaml is a somewhat fair comparison, but I have to say that Go is really in no way comparable to Rust. Rust is massively more complex.

I'd say Go is a fair comparison here. Type checking and Parsing isn't bottleneck in Rust compilation. Code generation is. LLVM is particularly heavy and while it generates optimized code, it is quite slow. Go Authors didn't pick LLVM because of compile speed reasons (as well as complexity), and that turned out to be worthwhile tradeoff.

The reason it's not a fair comparison is because go is a barely typed language that requires casting to interface non stop
Post reply on HN