Live data from Hacker News

Rust can be difficult to learn and frustrating, but it's also very exciting

influxdata.com

231–240 of 282 posts

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#231

Earlier quoted context omitted.

> Many people believe that Go rose to popularity because of the authors and the company sponsoring it, not on its technical merits I don't believe this to be the popular opinion. Originally Google's involvement dissuaded me, and indeed the very Googly bits have been the worst (context.Context), but the rest of it is markedly un-google-like. It's much more of a Bell Labs feel, with a focus on tool efficiency and stabi…

> There were a lot of good ideas over the years (especially in Plan 9) and Go is really just a modern, polished revision of those ideas glued together. Plan 9 is an operating system. If you're referring to goroutines, CSP is completely unrelated to any of the work done at Bell Labs. That was Hoare. Go also kept a ton of terrible ideas, like nil, void (interface{}), and default mutability. > Go is a _systems_ language…

A lot of your claims about Go are false.

> It's a language that's pretty good for small web services.

I know projects in production running HUGE web services written in Go serving millions of reqs/s. If that's small for you then I don't know what large is. Look at techempower benchmarks[1] and additionally compare the source of actix-raw (Rust) to fasthttp (Go).

OS written in Go: In experiments comparing nearly identical system call, page fault, and context switch code paths written in Go and C, the Go version was 5% to 15% slower.

Read the paper[2]

1. https://www.techempower.com/benchmarks/#section=data-r16&hw=...

2. https://www.usenix.org/system/files/osdi18-cutler.pdf

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#232
post #145
post #141

Earlier quoted context omitted.

> In Rust, if I want to write a similar thing, a HPACK decoder that returns both `io::Error` and `HPACK::DecodeError` for example, I need come up with another `Result` type that wraps both errors. This can sometime be tiring and makes the code inflexible (As one simple change to the `Result` may effect the entire call chain up and down). Well there's stuff like error-chain to take care of the boilerplate... Also, I b…

> you could define the equivalent of Go error in Rust as a trait and box it (ie. a trait object). I know this basically how Go's error handling works (Put error data on heap and pass the reference), but I'm not fan of it (the put data on heap part of it) too :( I will try out the error-chain, thank you for reminding me that.

The “failure” crate is an alternative to error-chain as well.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#233
post #21

I've learned a bit of Rust recently but then started programming in Go. Now that I've learned a decent amount of Go I'm thinking of giving Rust another try, because Go has so many obvious weaknesses. However, I'm still torn between those languages, which I both consider as fancy alternatives to C++ with a growing amount of libraries and community support. I neither like Go nor Rust, but learn them to keep up to date…

Could you elaborate a bit on the obvious weaknesses in Go?

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#234
post #34

I'm optimistic for the future of Rust. I currently program in Go for server side web stuff, but with the proposed changes to the Go language, the decision to choose Go over Rust becomes less compelling; Rust already has generics, a competent module system, better error handling, and ADTs. Go had a very narrow scope and very clear oversights, which are now bigger issues they are trying to shoehorn solutions into with…

What proposed changes to Go are you referring to?

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#235
post #78

Rust is the answer to the question "can we have speed, correctness, and expressiveness in one language?" My company has been running Rust in production for awhile now, and it's exceeded every expectation. It's fast, it's safe, and it's so productive it's hard to find a reason to use anything else. We've also found that the learning curve is, in our opinion, a bit overstated. We've ramped up several new grads on Rust…

I think the learning curve thing is depends on what's the language that you are compare it with. C++ for example, is a hard language, but the learning curve is ... progressive (rise bit by bit). Rust on the other hand, is like climbing a cliff: You're exposed to everything as soon as you start learning. That's all the Rust things (memory safety model and borrow etc) plus the rest of the knowledge that you need to lea…

> C++ for example, is a hard language, but the learning curve is ... progressive (rise bit by bit).

Except that you've always got a footgun in each hand, with no safeties and no trigger guards.

Rust keeps its footguns locked in the gun safe. You get them out with the `unsafe` keyword.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#236
post #21

I've learned a bit of Rust recently but then started programming in Go. Now that I've learned a decent amount of Go I'm thinking of giving Rust another try, because Go has so many obvious weaknesses. However, I'm still torn between those languages, which I both consider as fancy alternatives to C++ with a growing amount of libraries and community support. I neither like Go nor Rust, but learn them to keep up to date…

Could you elaborate a bit on the obvious weaknesses in Go?

Arbitrary examples off the top of my head:

lack of references, no generics, verbose error handling, a few quirks (e.g. need to write (*slice)[i]), inconsistencies like new vs. make, interface{} hacks where there could be a zero-cost abstraction, oddities with untyped literals, no way to declare "not null" pointers and the Million Dollar Mistake, built-in functions for built-in primitives (i.e., append(slice, datum) instead of slice.append(datum))

Stuff like that, which has been discussed over and over. Go is a bit of an odd language if you're used to languages like Ada, CommonLisp, or Racket, but I really like it a lot. I like the sense of pragmatism, that it has been developed to get things done.

I believe that Go2 will be even better and am especially happy that the Go team has decided to adjust and include generics rather than stubbornly insisting that they are not needed.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#237
post #229

Earlier quoted context omitted.

The benchmarks game is just that: a game. Notably, Go programs are prohibited from doing certain optimizations that are permissible for C++ programs. The conventional wisdom is that Go and Java are within the same order of magnitude as C++ though still slower. I’d accept that they are a full order slower, but not multiple orders. > Do you dispute nil and * I dispute that Go’s pointer is a “raw pointer” in any meaning…

> The benchmarks game is just that: a game. The name "benchmarks game" signifies nothing more than the fact that programmers contribute programs that compete (but try to remain comparable) for fun not money. It's what you make of it. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... > Go programs are prohibited from doing certain optimizations that are permissible for C++ programs Which programs? Which…

That benchmarks game quote supports my point (not sure if you quoted it to contradict me or not?). As for prohibited optimizations, arena allocation is the one that comes to mind since it’s the standard way to avoid O(n) allocs.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#238

Earlier quoted context omitted.

Python is pretty to look at, but I hate working in white space sensitive languages. If I have to have another argument about tabs vs. spaces I am going to toss my monitor out the frickin’ window. Also, it makes autoindent in Emacs worse.

There is no such thing as white space insensitive language.

Fortran IV came close. You could put spaces in the middle of identifiers, keywords, and numbers, and the compiler ignored them. The language did not require spaces as separators anywhere. Spaces were only significant in Hollerith constants (what we'd call string literals today) and in columns 1-6. Columns 1-6 were reserved for line numbers, comment signifiers, and continuation marks.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#240
I didn’t really find Rust especially hard to learn. I came from Python with a very beginner level experience in embedded C.

The hardest part is probably to stop yourself from trying to applying solutions you learned in other languages into Rust. I caught myself multiple times trying to put things into python style classes, which failed horrible each time. The moment you grasp how to do things the rust way you will end up with solutions that are most likely more elegant, safe and fast than the thing that you tried to do first.

Over time (a few weeks) I managed to get a good enough intuition on Rusts concepts of ownership to not having to constantly think about it.

Post reply on HN