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

How Rust Is Tilde’s Competitive Advantage [pdf]

rust-lang.org

Post reply on HN
Print view View original

51–60 of 127 posts

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#51

Post by pjmlp »

steveklabnik wrote: post #32
jokoon wrote: post #29

> Rust is much easier to teach than C or C++, Not sure about that. If you know C, which is easy to learn, you already know a lot about C++, or at least the parts that are used most of the time. Learning about the borrow checker, match enums don't seem very easy at first, although they surely seem elegant and much safer.

Many Rust programmers never learned C, or have only a cursory understanding of it. Most C++ people I talk to would strongly disagree that in C++, you should do things the C way.

The C way in C++ should only be used the same way as unsafe in Rust.

Very well hidden in safe abstractions, and validated by a profiler that they are actually better than the safer C++ alternatives.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#52

Post by switchbak »

paulddraper wrote: post #3

> while the Java server could use up to 5GB of RAM, the comparable Rust server only used 50MB How...how is that possible? It just glosses over this interesting point. What does "comparable" Java code do to use 100x more memory?

It's hard to say without really diving into that code. The 100x disparity seems pretty surprisingly high.

Often times people will give the JVM a sizeable heap in the interests of reducing garbage collector pressure (sometimes this is counterproductive). Usually it's possible to run with a much smaller heap, but we're still talking 100's of megabytes for most non-trivial apps. Even the VM itself will allocate a decent amount of memory besides that.

There's a number of reasons that typical JVM apps use more memory, but most of it seems to boil down to using the heap much more, lack of real value types (using the stack far less), and size overhead with small objects (see: https://www.javamex.com/tutorials/memory/object_memory_usage...).

It seems like the low cost cloud instances could be a real driver for the adoption of more lean runtimes. My client couldn't even consider those 256m/512m Heroku instances (with a large legacy JVM app).

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#53

Post by sidlls »

jokoon wrote: post #29

> Rust is much easier to teach than C or C++, Not sure about that. If you know C, which is easy to learn, you already know a lot about C++, or at least the parts that are used most of the time. Learning about the borrow checker, match enums don't seem very easy at first, although they surely seem elegant and much safer.

I have lots of experience with C++, and a non-trivial amount with C. I've done everything from game development to writing drivers to scientific computing with these languages. Here's how I describe it: a good portion of the stuff C and C++ programmers learn with experience (e.g. best practices, memory management, etc.) are "front loaded" in Rust by having to learn about Borrowing, lifetimes and the like. One isn't harder than the other, but the path to proficiency is quite different. In my view Rust has a superior path.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#54

Post by mercurial »

kbenson wrote: post #33
mercurial wrote: post #26

Earlier quoted context omitted.

> If you’re expecting the F# (and .NET) ecosystem, you’ll likely be satisfied. In fact, it might be better. Not even close (100k unique packages on nuget, 13k crates on crates.io). On the other hand, you have easy interop with C (which doesn't give you stuff like safety, idiomatic error handling or nice APIs, but it's occasionally better than coding it yourself).

It's not about total packages, but about quality of packages and whether they provide good coverage of most problem spaces. NPM claims to have close to 500k packages. Should we assume it solves 5x the problems that the .NET ecosystem does, that that perhaps by the 50th implementation of leftpad, there's some cruft on there? That's not to say that Rust's package ecosystem is large enough or sufficient in comparison to…

Well, an order of magnitude of difference is a hint that, whatever the quality of the existing crates, there are definitely areas for which you are going to be hard-pressed to find a good solution (say, localization), or a solution at all.

It is not a sign that there is anything wrong with the Rust ecosystem, it has a very active community and things are moving in the right direction, it is not just as full-featured as more mature ecosystems out there.

See for instance https://github.com/ErichDonGubler/not-yet-awesome-rust

There are quite a few use cases not listed here, obviously.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#56

Post by mjal »

steveklabnik wrote: post #8
Q6T46nT668w6i3m wrote: post #7

Earlier quoted context omitted.

Steve, just so you know (for future answers), the IntelliJ plug-in is stupidly good considering its relative newness. You shouldn’t hesitate to recommend to existing IntelliJ users. :D

Understood :) I usually try to be really clear about what my opinion is based on, especially when it's second-hand, like with IntelliJ. Have you tried debugging with CLion? I don't own a license so I haven't tried myself.

CLion debugging works pretty well for most cases, though there are some small issues every so often. I always make sure to report them to the appropriate place if they're not known already, though.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#57

Post by coldtea »

Nelkins wrote: post #2

So, I've been eyeing Rust for a while and have messed around with it a bit in my free time. Here are some things I'd want to know before trying it out on a large project: 1. What development environment are other developers using with very large code bases? Is the tooling responsive? 2. Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators f…

>2. Using a language for a large project without some kind of async/await notation seems painful

And yet most of the software we use, billions of lines of code, from Chrome to Linux, from Photoshop to bind, and from Nginx to Skype, has been created without such notation. Somehow we've managed.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#58

Post by naasking »

pcwalton wrote: post #47
jokoon wrote: post #29

> Rust is much easier to teach than C or C++, Not sure about that. If you know C, which is easy to learn, you already know a lot about C++, or at least the parts that are used most of the time. Learning about the borrow checker, match enums don't seem very easy at first, although they surely seem elegant and much safer.

That doesn't square with my experience. I've taught beginning programmers more or less the "C subset" of C++, and it was a nightmare. The biggest problem is that when they inevitably hit undefined behavior, there is no easy way to learn what is wrong. The program hits a segfault or prints garbage on the screen—where to begin? I instinctively know what is likely to be wrong, but that's only through years of experience…

Learning C via an interpreter that errors out on undefined behaviour seems like a good way to address those issues. Not sure if any of the interpreters I've seen over the years actually does this though, though I imagine altering something like PicoC would be straightforward enough.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#59

Post by naasking »

notriddle wrote: post #16
paulddraper wrote: post #3

> while the Java server could use up to 5GB of RAM, the comparable Rust server only used 50MB How...how is that possible? It just glosses over this interesting point. What does "comparable" Java code do to use 100x more memory?

Three things: * Java tends to allocate things separately and manipulate pointers, while Rust allocates things inline. This introduces allocation overhead and eats up the space needed by the pointers themselves. * Java uses a JIT, which consumes of memory for profiling state and for storing the resulting compiled code. * A tracing garbage collector needs about five times as much memory as explicit freeing to reach the…

5 times the memory is a serious exaggeration. At least twice, but no more than 3x.

Re: How Rust Is Tilde’s Competitive Advantage [pdf]

#60

Post by pcwalton »

naasking wrote: post #58
pcwalton wrote: post #47

Earlier quoted context omitted.

That doesn't square with my experience. I've taught beginning programmers more or less the "C subset" of C++, and it was a nightmare. The biggest problem is that when they inevitably hit undefined behavior, there is no easy way to learn what is wrong. The program hits a segfault or prints garbage on the screen—where to begin? I instinctively know what is likely to be wrong, but that's only through years of experience…

Learning C via an interpreter that errors out on undefined behaviour seems like a good way to address those issues. Not sure if any of the interpreters I've seen over the years actually does this though, though I imagine altering something like PicoC would be straightforward enough.

Judging by the development of UBSan and ASan, I think such a thing would be anything but straightforward, even with a simple C compiler.
Post reply on HN