Live data from Hacker News

An interactive guide to learning Rust

github.com

41–50 of 55 posts

Re: An interactive guide to learning Rust

#41

Earlier quoted context omitted.

rust compiles to web assembly

What kinds of things could you do with web assembly that you can’t do in native JavaScript? I know very little about web development.

I know that the web wallet for NANO uses wasm to generate hashes, and is _much_ more performant than the JS equivalent.

Re: An interactive guide to learning Rust

#42

Earlier quoted context omitted.

I agree with that point, except for two minor things: - mobile development in particular is the worst possible case of this. mobile platform companies are in the best case optimized only for their own case, and in the worst case maliciously trying to create developer walled gardens. However, I would point out that knowing one of these often helps in knowing the other (Android vs iOS) -- there are often 1:1 concepts t…

You're entirely right insofar as (eg) an Android developer will learn iOS far faster than someone without mobile (or any other ui kit) experience. But the specifics are different enough such that it's hard to do both to a high level. Or perhaps I'm just speaking for my own limitations -- I do iOS & Android (native & a bit of react native), but I'm definitely less of an expert with either (or the various server things…

> You're entirely right insofar as (eg) an Android developer will learn iOS far faster than someone without mobile (or any other ui kit) experience. But the specifics are different enough such that it's hard to do both to a high level. Or perhaps I'm just speaking for my own limitations -- I do iOS & Android (native & a bit of react native), but I'm definitely less of an expert with either (or the various server things I also do) than I would be if I specialised.

Yeah, that's definitely true pretty much why projects like react native and flutter exist. I personally have done toy projects on iOS and Android, but do not do it for my day job (and really have no desire to), so I stick to projects like react native and flutter and try to avoid mobile development like the plague.

> I was offering AWS as an example of another platform rather than a language. If you're called on to (for example) implement a bunch of microservice type stuff, there's quite a bit to learn about RDS/dynamo/lambdas/IAM etc, and then all the quite complex deployment stuff to make it truly production ready.

Yeah, absolutely -- funnily enough, I'm relatively sure that AWS wants it this way. AWS can be come so complex so fast, especially when they have many ways to do the same thing (often built upon each other) and it isn't necessarily immediately clear which is the best for your usecase. The additional management they give you for some services is minimal -- I'm thoroaughly convinced that most of the "value" offered by RDS is more-or-less thanks to tools like postgres being well-written/robust software.

I agree on the language being relatively trivial too -- maybe the importance of platforms ties into that -- Once the language difference becomes trivial the next big differentiator must indeed be platforms/the well-used structures that are built on the base language. I'll make sure to express that more clearly in the future

Re: An interactive guide to learning Rust

#43
post #38

Earlier quoted context omitted.

Right now the second link you posted isn't loading, so I'm not sure if that is something that matches the Go Tour interface (maybe it is, and it's not loading because it's failing to init some virtualized environment for test code to run in?). My problem wasn't that good documentation wasn't available, it certainly is. The first and second editions of the rust book rust book ( https://doc.rust-lang.org/book ) are wha…

Not sure why it isn't loading, but to get an idea it's pretty much literally gobyexample.com for Rust.

It's not loading because I set up a redirect to its new home, https://doc.rust-lang.org/rust-by-example/, and it seems to work for some people, but not for others. I'll have it fixed sometime soon.

Re: An interactive guide to learning Rust

#44

Earlier quoted context omitted.

> I see [..] Rust replacing C/C++ (yeah, even C) To me, the possibility of Rust replacing C is the most interesting aspect of the language. (I'm not sure I see it replacing C++, but maybe competing with it; choose between evolution or revolution!) The general hype around Rust is fascinating to me though. I assume it's mostly driven by former C/C++ programmers, but the process has been noisy enough to attract attentio…

I think the hype around rust is actually pretty well warranted though -- people got really excited about Go and Rust because they were new "systems" languages, and the world hasn't really seen one of those in a while. "systems language" is a pretty vague term, but one of the things I think is important is that memory be manually managed -- I think most people would agree with that. I think Rust is interesting to the…

> Almost axiomatically

It's more complex than that. You also have to consider the expert vs the general case. So for example, Rust can automatically apply the equivalent of restrict to many of your pointers. An expert with 100% accuracy could do so in C, but an average C programmer may not. Thanks to the compiler, the average and the expert Rust developer will both do this all the time.

Then, there's the cases when being safer and checked by the compiler means you can be more aggressive. When writing code that needs to be maintained over time, you need to make decisions that will ensure correctness even as you modify the code. And as your staff turns over. Rust lets you do very aggressive things, while making sure that you won't say, introduce thread unsafety accidentally. Not only that, but currently, since LLVM does all optimizations, we have to deal with the ones that are designed for C or C++; Rust is already quite fast without Rust-specific optimizing.

Anyway, in the end, we'll be sometimes slower and sometimes faster than C, just generally. I think it'll be very interesting to watch over time.

Re: An interactive guide to learning Rust

#45

Earlier quoted context omitted.

You're entirely right insofar as (eg) an Android developer will learn iOS far faster than someone without mobile (or any other ui kit) experience. But the specifics are different enough such that it's hard to do both to a high level. Or perhaps I'm just speaking for my own limitations -- I do iOS & Android (native & a bit of react native), but I'm definitely less of an expert with either (or the various server things…

> You're entirely right insofar as (eg) an Android developer will learn iOS far faster than someone without mobile (or any other ui kit) experience. But the specifics are different enough such that it's hard to do both to a high level. Or perhaps I'm just speaking for my own limitations -- I do iOS & Android (native & a bit of react native), but I'm definitely less of an expert with either (or the various server thin…

> I'm relatively sure that AWS wants it this way

Oh yes. Capture is definitely the name of the game. For 'engineers' or 'software developers' to become instead 'iOS/Android/AWS developers' is good business for the corporations concerned (and ultimately, in my opinion, very bad for us).

Re: An interactive guide to learning Rust

#46

Earlier quoted context omitted.

Rust and Go, while really similar, kind of are different in use -- the key differntiator is memory management, and memory safety. For a LOT of applications, this isn't necessary or a big deal (see: just about every program written in a language that isn't c/c++). I see Golang replacing Java longterm and Rust replacing C/C++ (yeah, even C) due to the memory safety and preciseness + speed it offers. It may never be tru…

> I see [..] Rust replacing C/C++ (yeah, even C) To me, the possibility of Rust replacing C is the most interesting aspect of the language. (I'm not sure I see it replacing C++, but maybe competing with it; choose between evolution or revolution!) The general hype around Rust is fascinating to me though. I assume it's mostly driven by former C/C++ programmers, but the process has been noisy enough to attract attentio…

> I assume it's mostly driven by former C/C++ programmer

From what I can tell, Rust seems mainly to have attracted people from dynamic interpreted languages who weren't deeply invested in C or C++. I think it's easier to sell a Ruby programmer on performance than it is to sell a C++ programmer on an unfamiliar safety mechanism.

Re: An interactive guide to learning Rust

#47

Earlier quoted context omitted.

Give me something that can run ReactDOM.renderToString() faster, and I'm all ears. Until that day (and I'm kinda hoping it comes) I'm a bit stuck.

https://github.com/DenisKolodin/yew

This does look interesting. I don't see a difference between this and any other server-side templating language though. I actually need an isomorphic representation on the client and server. (this is what makes renderToString() valuable) I guess I could be extremely careful in writing the server output, and writing the client output to match, but at that point, I'd be writing it twice... and I could use any language... unfortunately, it'd probably end up being Handlebars.

Re: An interactive guide to learning Rust

#48
post #33
post #21

Earlier quoted context omitted.

I'm not very familiar with the React ecosystem but I thought the entire point was letting the client-side handle rendering and passing structured data via API calls? renderToString() sounds like it's doing what every scripting language and templating framework has been doing for the past 20 years?

Look up server-side rendering in React. The major benefits are better/faster first page load experience and better SEO, especially for crawlers that don't have good JavaScript support. This way you can run the same code on the client or server depending on the circumstances.

The fringe benefit being I don't have to represent my app twice (once for server-side markup, the second for client-side JSX). As the size of any give app grows, keeping things in sync would be a nightmare.

Re: An interactive guide to learning Rust

#49

Earlier quoted context omitted.

> I see [..] Rust replacing C/C++ (yeah, even C) To me, the possibility of Rust replacing C is the most interesting aspect of the language. (I'm not sure I see it replacing C++, but maybe competing with it; choose between evolution or revolution!) The general hype around Rust is fascinating to me though. I assume it's mostly driven by former C/C++ programmers, but the process has been noisy enough to attract attentio…

I think the hype around rust is actually pretty well warranted though -- people got really excited about Go and Rust because they were new "systems" languages, and the world hasn't really seen one of those in a while. "systems language" is a pretty vague term, but one of the things I think is important is that memory be manually managed -- I think most people would agree with that. I think Rust is interesting to the…

> "systems language" is a pretty vague term, but one of the things I think is important is that memory be manually managed

Go does not let you manage memory manually.

Re: An interactive guide to learning Rust

#50
post #49

Earlier quoted context omitted.

I think the hype around rust is actually pretty well warranted though -- people got really excited about Go and Rust because they were new "systems" languages, and the world hasn't really seen one of those in a while. "systems language" is a pretty vague term, but one of the things I think is important is that memory be manually managed -- I think most people would agree with that. I think Rust is interesting to the…

> "systems language" is a pretty vague term, but one of the things I think is important is that memory be manually managed Go does not let you manage memory manually.

You're absolutely right -- I didn't think I had to re-state that here since it's like the second sentence of the original comment. That's also why I went into qualifying "systems" language, some might consider golang a systems language, even though it very much does not allow manual memory management, which is why it's vague (and I put it in quotes).
Post reply on HN