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

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

influxdata.com

Post reply on HN
Print view View original

221–230 of 282 posts

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

#221

Post by crimsonalucard »

olavk wrote: post #148
bb88 wrote: post #73

Earlier quoted context omitted.

> I'm very bullish on Rust becoming the language of choice in the 2020s for everything from operating systems, web services, desktop applications, and more. It's that good. I don't mean to burst your bubble here. But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way. Looking at this thread there are plenty of examples of "I love…

Comparing Haskell to JavaScript is silly - JavaScript is popular because it is the only option in the browser. It has noting to do with the quality of the language itself. If VBScript had won, everyone would be using that. If Netscape had decided to use Scheme or Haskell as the scripting language, this is what everyone would be using. Rust is competing in the space of C and C++, it is not competing against Java or Py…

Text editors like vscode and atom (electron) go head to head with sublime (c++). The dominant editor now is vscode.

For Rust to win it must be adopted by Gaming or gaming engines.

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

#222

Post by iopq »

olavk wrote: post #200
iopq wrote: post #196

Earlier quoted context omitted.

I'm comparing it to Haskell syntax for the same thing, which is much cleaner

Haskell does not have borrowing and lifetime specifiers though, which is what makes the Rust example more dense.

Haskell has nice syntax for generics, no stupid to forward declare type parameters

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

#223

Post by iopq »

olavk wrote: post #199
iopq wrote: post #173

Earlier quoted context omitted.

Okay, tell me if this is readable to you: fn accumulate (tuples: &[(&'a str, &Fn(i32) -> bool)], i: i32) -> T where T: From + From , this is JUST the function signature yes, every single thing in there is necessary, it can be written in a more gruesome way, but the where clause clarifies it a bit But let me cheat a little bit ( $(#[$attr:meta])* enum $enumer:ident { $($i:ident => $e:tt $( ( $($m:ident),* ) )* ; )* }…

It is somewhat unfair to compare this to Python, since a lot of the simplicity in Python comes from the semantics (dynamically typed, garbage collected and so on). Rust need to express all this information (types, lifetimes etc.), so it will necessarily be more dense. The question is if this information could be expressed in a more readable syntax. This might be possible, but I would like to see a suggestion of how.…

Here is a simpler syntax:

   fn accumulate tuples: &[(&'a Str, &Fn(i32) -> Bool)], i: i32 -> t
   where
        t: Monoid + From &'a Str + From String,
this is how Haskell with lifetimes and borrowing would look like (if arguments were not curried)

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

#224

Post by weberc2 »

the_duke wrote: post #197
tech2 wrote: post #143

Earlier quoted context omitted.

I suspect the reason it's not faster is one of the following: 1. backend DB at its query limit 2. this is basically my first rust program and I've done something stupid 3. ab/wrk aren't scaling properly either (I know, not likely, but worth considering) when I'm testing it 4. bandwidth/IO limits on the AWS instance types I'm running this on There are other possibilities too I guess. I was mostly doing this as a means…

What web framework are you using? Are you using a database? If so, which one? Are you using a cache like Redis? I agree that a 2x speedup is a terribly low for a Python to Rust rewrite and shows that Python is unlikely to be the relevant bottleneck here.

> What web framework are you using?

I can't imagine the web framework is the bottleneck...

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

#225

Post by weberc2 »

ilovecaching wrote: post #101
weberc2 wrote: post #97

Earlier quoted context omitted.

I imagine the learning curve is a lot more manageable when you have an office full of full time Rust developers. If you’re on your own you become painfully aware of how often you need to solicit help, and the time it takes to familiarize someone else with your problem over chat or forum post really eats away at one’s motivation.

Well the Rust community is super welcoming, and the meetups have been really positive. They even have the #rust-beginners channel. :) I find Rust to be fairly easy to reason about. The compiler has awesome messages, and even links you to your error type with more information. I also HIGHLY recommend reading the O'Reilly book AND the official Rust book (the free one) if you feel like you're "just not getting it". Rust…

> Well the Rust community is super welcoming, and the meetups have been really positive.

For sure. The Rust community takes the cake when it comes to owning criticism, wanting to make things better (as opposed to excusing issues), and self-organizing to affect change (e.g., the working groups). I like Go and its community is well above average, but it stands to learn from Rust's community IMHO.

> the meetups have been really positive. They even have the #rust-beginners channel. :)

I know, but a slack/irc/email/etc channel is a really poor substitute for having humans in a room who already have context about the problem you're trying to solve.

> I find Rust to be fairly easy to reason about. The compiler has awesome messages, and even links you to your error type with more information. I also HIGHLY recommend reading the O'Reilly book AND the official Rust book (the free one) if you feel like you're "just not getting it".

Hard to make heads or tails of this without knowing what you're comparing it to. I do agree that Rust does a fantastic job (via its error messages, documentation, books, etc) at addressing the hard problem of dealing with a compiler that pedantically enforces not-very-intuitive invariants, and I respect Rust for believing that those invariants are worth the trouble. I think they _are_ for lots of applications, but I think Rust needs to do quite a lot on the learnability/intuitability front before the economics justify using Rust for general purpose application development. For the time being, for most applications, it's just so much _cheaper_ to use something like Go in the general case.

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

#226

Post by how_to_bake »

snrji wrote: post #140

I enjoy coding in Rust, and I think it's a step in the right direction, but I'm still looking for a general purpose programming language which model IO/State effects the same way languages supporting functional programming do with pure functions. Haskell monads are not granular enough. The closer thing I've seen is Purescript, but still is not general purpose enough. Solidity's "pure" annotations are a step in the ri…

Check out Nim. They recently added support for a function declaration in addition to a proc. Function automatically checks that it is a pure function with no side effects.

Considering the flexibility of the language as a whole, this is really cool!

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

#227

Post by the_duke »

weberc2 wrote: post #224
the_duke wrote: post #197

Earlier quoted context omitted.

What web framework are you using? Are you using a database? If so, which one? Are you using a cache like Redis? I agree that a 2x speedup is a terribly low for a Python to Rust rewrite and shows that Python is unlikely to be the relevant bottleneck here.

> What web framework are you using? I can't imagine the web framework is the bottleneck...

It might be because if it's a tokio-core based one OP might be blocking the event loop too much.

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

#228

Post by igouy »

ilovecaching wrote: post #115
weberc2 wrote: post #107

Earlier quoted context omitted.

> Go isn't really in the same league as Rust, C++, or C. It's syntax is deceptively C like, and it has an equally poor type system, but it's performance is closer to Java, which is a few orders of magnitude slower than C++. Despite pushing outdated concepts like null and raw pointers on to the programmer, it has a runtime with a stop the world GC with no guarantees about object placement on the stack or heap Man, sta…

> it's performance is closer to Java Go vs Java https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Go vs C++ https://benchmarksgame-team.pages.debian.net/benchmarksgame/... > pushing outdated concepts like null and raw pointers on to the programmer I mean this is just a fact. Are you disputing nil and *? > it has a runtime with a stop the world GC https://blog.golang.org/ismmkeynote "On the Y axis we hav…

> … it's performance is closer to Java …

You seem to be quoting yourself out-of-context ;-)

In full, you wrote — "… but it's performance is closer to Java, which is a few orders of magnitude slower than C++" — and that is not shown by those measurements.

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

#229

Post by igouy »

weberc2 wrote: post #216
ilovecaching wrote: post #115

Earlier quoted context omitted.

> it's performance is closer to Java Go vs Java https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Go vs C++ https://benchmarksgame-team.pages.debian.net/benchmarksgame/... > pushing outdated concepts like null and raw pointers on to the programmer I mean this is just a fact. Are you disputing nil and *? > it has a runtime with a stop the world GC https://blog.golang.org/ismmkeynote "On the Y axis we hav…

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 "certain optimizations"?

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

#230

Post by dev_dull »

ammaskartik wrote: post #170
dev_dull wrote: post #57

Earlier quoted context omitted.

How does your team (E.g., the people on the hook for reviewing/supporting/contributing to your project) feel about the change? This is a big difference when moving from Go. A language that nobody calls beautiful, but is very easy for a team to contribute to and support (relative to other languages).

One more point here, I wouldnt have done it if I did not get full support & enthusiasm from my team. But I guess sometimes it helps when you dont have HUGE existing code bases to have to justify to port. =)

All good points thanks for the response.
Post reply on HN