How Rust Is Tilde’s Competitive Advantage [pdf] • Hacker News Board

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

#101

Post by bonesss » Wed, Feb 07, 2018, 9:52 AM UTC

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…

> raw package count gets to be an extremely poor indicator of quality after a certain level has been reached.

Broadly speaking I think the best indicators are always going to be domain specific -- which set of packages is most used within the context of what you're doing? A million awesome packages for Excel automation aren't much help, per se, for huge file chunking or BigData work.

From that point of view it's more relevant to look at the size of the successful projects in that market that resemble your technical goals.

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

#102

Post by jahaja » Wed, Feb 07, 2018, 11:13 AM UTC

gridspy wrote: post #78

jahaja wrote: post #68

I've come to realize that the main thing that is making me procrastinate giving Rust a proper go is entirely superficial at this point. Basically it looks like a "clever" programmers dream language - which is usually not my cup of tea. I'm also worried that larger projects ("real-world" projects, so not projects like Servo) will inevitably become an illegible mess when clever programmers makes the most of a clever la…

May you always work with clever programmers who make clever code simple.

What did you find provoking? My intention was just to say that I personally find it harder to work with a language that has a high cognitive load to interpret.

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

#103

Post by Nelkins » Wed, Feb 07, 2018, 11:22 AM UTC

tytytytytytytyt wrote: post #79

naasking wrote: post #61

Earlier quoted context omitted.

"Managed" and "seems painful" don't disagree with each other.

That doesn't make the assertion that you need async notation for any large project to not be painful any less ridiculous.

Of course you don't NEED it. It's just that I've become accustomed to the bells and whistles (and accompanying productivity) of a modern programming language. If I'm considering a new programming language I'd like the feature set to be comparable.

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

#104

Post by mickronome » Wed, Feb 07, 2018, 12:30 PM UTC

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?

If they increased the heap until the JVM was exactly as fast as their compiled Rust code on the same/equivalent hardware, you could get those numbers as some kinds of GC significantly decrease overhead with increased heap size.

With that said, that's an almost entirely useless benchmark, except as a testament to the amazing JIT compilation the JVM does. That the JVM with GC is capable of matching a compiled language specifically made to have efficient memory management at ANY heap size is positively astonishing!

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

#105

Post by rsynnott » Wed, Feb 07, 2018, 12:42 PM UTC

yazaddaruvala wrote: post #87

rsynnott wrote: post #30

Earlier quoted context omitted.

Almost certainly either bad design (their Java app had a way bigger working set than their Rust one), or bad tuning (they set the heap needlessly large). Automatic memory management _does_ require more memory for reasonable performance, but you'd be talking about 2x or 3x the working set. Not 100x. Java objects will likely end up a little larger than Rust ones, but again not enough to make up the 100x difference. Hav…

> or bad tuning (they set the heap needlessly large) The claim "for equivalent Java code", might be slightly exaggerated, but looking at the claim as a whole: "Rust is Tilde's Competitive Advantage", "bad tuning" is part of the point. "bad tuning" usually means "no tuning". Which means they spent the time they could have been tuning and used it to build features instead, or optimize their code instead. From that pers…

Oh, yeah, it's certainly a problem. However, they could almost certainly have done a lot better with Java than they'd been doing, if they wanted to.

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

#106

Post by lossolo » Wed, Feb 07, 2018, 2:16 PM UTC

gridspy wrote: post #78

jahaja wrote: post #68

I've come to realize that the main thing that is making me procrastinate giving Rust a proper go is entirely superficial at this point. Basically it looks like a "clever" programmers dream language - which is usually not my cup of tea. I'm also worried that larger projects ("real-world" projects, so not projects like Servo) will inevitably become an illegible mess when clever programmers makes the most of a clever la…

May you always work with clever programmers who make clever code simple.

Most "clever" programmers makes code a lot more complicated than it should be to show how "clever" they are. The more complicated the language, the more complicated code they will produce. I've seen this a lot of times.

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

#107

Post by kbenson » Wed, Feb 07, 2018, 3:15 PM UTC

lmm wrote: post #99

kbenson wrote: post #94

Earlier quoted context omitted.

> async/await means you mark all your yield points explicitly; rather than having the runtime implicitly preempt you whenever it chooses, you mark the points at which task switching can happen, and at every other point it's impossible (equivalently it's as though any block of code that doesn't contain an "await" were a critical section). That's not how I understood it at all. I always assumed that it just promoted ex…

> That's not how I understood it at all. I always assumed that it just promoted explicitly acknowledging when the effect of an async block would be present, but that the normal yield points (traditionally syscalls and IO requests in OS threads) generally still held for the actual execution of the other code. Put it this way: the language implementation won't preempt you except at your explicit yield points (some stan…

I think I see what's going on here. You're answering "in the context of Go" (which is correct, and what was corrected) and I'm interpreting it as a general statement about what async/await mean as general concepts (i.e. in other languages as well). My mistake, I wasn't paying close enough attention. :)

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

#108

Post by bvinc » Wed, Feb 07, 2018, 3:26 PM UTC

jahaja wrote: post #68

I've come to realize that the main thing that is making me procrastinate giving Rust a proper go is entirely superficial at this point. Basically it looks like a "clever" programmers dream language - which is usually not my cup of tea. I'm also worried that larger projects ("real-world" projects, so not projects like Servo) will inevitably become an illegible mess when clever programmers makes the most of a clever la…

It may not be your cup of tea, but I don't think your concern about large code bases will be a problem. Ensuring invariants across large code bases is what rust excels at. You'll more likely have the opposite problem: getting frustrated at trying to use an API in a way that it was never intended and compiler won't let you.

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

#109

Post by mda » Wed, Feb 07, 2018, 4:50 PM UTC

Anderkent wrote: post #74

mda wrote: post #63

Earlier quoted context omitted.

I call bullshit. Most probably their Java code was FUBAR.

> Most probably their Java code was FUBAR. And so what? If a language's natural form leads to FUBAR code, what else is to blame?

Really? You can write FUBAR code in any language, language has nothing to do with this.

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

#110

Post by tytytytytytytyt » Wed, Feb 07, 2018, 5:41 PM UTC

knowtheory wrote: post #89

tytytytytytytyt wrote: post #88

Earlier quoted context omitted.

Yes, really. It's not the length, it's the density of interesting content.

Yeah man, learning to scan a paper for interesting content is definitely a skill worth developing!

I suggested it because it'd help other people not waste the time scanning the paper for the same minuscule amount of not-that-interesting content. But at least it gave you the opportunity to contribute your interesting comment. Yeah, man!