Two years of Rust • Hacker News Board

Re: Two years of Rust

#281

Post by zzalpha » Tue, May 16, 2017, 1:53 PM UTC

dang wrote: post #236

zzalpha wrote: post #226

Earlier quoted context omitted.

No one can demonstrate productivity gains because productivity can't be measured. So then the OP shouldn't have made the claim. It ain't my job to prove it. :) That said, I fundamentally disagree with the idea that one can't measure developer productivity. I agree that there are many potential measures, all of which have the potential to be flawed or distorted. But the idea that the productivity of a developer can't…

The fact that no one has come up with any plausible way of doing this is so commonly observed as to be a cliché. See for example https://martinfowler.com/bliki/CannotMeasureProductivity.htm... . > So then the OP shouldn't have made the claim Come now, it was you who moved those goalposts and you moved them half a field or more. OP claimed REPLs "have benefits". Your response was (paraphrased) "demonstrable measuremen…

Eh, here Fowler just falls into to the trap of the Perfect Solution fallacy.

I repeat: there are no perfect measures of productivity. But there are imperfect measures that have some utility. The idea that we cannot measure at all because we cannot measure perfectly is simply untrue.

In this case we could, for example, take 1000 individuals with similar years of programming experience and given them two languages and a non-trivial problem to solve and see how long they take to come to a working and correct solution.

Is that perfect? No. But it's still something that's measurable. Do that with a reasonably large sample and you can probably start making inferences.

Our industry suffers from a horrible lack of concrete, scientific studies to back common wisdom. We would all benefit from ignoring Fowler, here, and getting down to the nuts and bolts of finding solutions to that problem. Until we do, while we'll have lots of fun having pointless debates on HN that cannot be resolved because we have no real data, the industry simply won't move forward.

Re: Two years of Rust

#282

Post by sqeaky » Tue, May 16, 2017, 3:22 PM UTC

mmstick wrote: post #135

sqeaky wrote: post #124

Earlier quoted context omitted.

What about serving uncompressed content over https? What about serving up an error page when the user's browser odesn't have compressor you support? What about paying attention to web standards? What about people who are stuck with old software for one reason or another?

> What about serving uncompressed content over https? I have limited bandwidth. I don't want to serve uncompressed content over HTTPS. > What about serving up an error page when the user's browser odesn't have compressor you support? I will do that once I figure out how to get the Request header from Rocket's API. > What about paying attention to web standards? I'm already complying with HTTPS web standards. I'm even…

> That's their problem, not mine. You shouldn't be using old web browsers and outdated systems on the web. That makes you vulnerable.

You wouldn't host a page if you didn't want to share its content, doesn't failing to do so make it atleast partially your problem?

You are ignoring the list of encodings the client gives you, you are paying attention to some and not all. If we all did the web wouldn't work.

Maybe they have good reasons, you aren't them and you don't know their situation. But you have chosen to not share with people with tech older than one year...

Step back, and try to take an objective look at this. Do you know what percentage of web browsers actually in use will work? Do you know what percentage of people visiting your page see only gibberish?

Finally, Why are so many of your comments in the gray and everyone else's not in the gray? Why do so many of your technical peers disagree with you?

Re: Two years of Rust

#283

Post by kbenson » Tue, May 16, 2017, 3:24 PM UTC

flukus wrote: post #272

bluejekyll wrote: post #264

Earlier quoted context omitted.

> The problem is multi copies of the same dependencies everywhere most binaries would be statically linked and compiled, so there wouldn't be copies, but you do have a valid point of an issue with needing to upgrade an tool that was build with a static dependency that has an issue. If I understand you, you're saying Rust, a general purpose language, with it's own build tool should do what exactly? I see that you beli…

> but every package manager for every OS out there does things differently, Rust can not fix this. Exactly, it can't fix it but it tries to cover over this fact by bundling dependencies with every app. > I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there Basically, but more to the point, when a bug or security issue is fixed I don't wa…

While I understand your point, there is a difference between something installed through cargo for use in building software (in the manner rust does, where it's generally statically compiled), and something installed through the package manager for use in running the system.

If I'm installed zlib for general system use, I want a package manager. If I'm installing a Rust compression library to be compiled into the program I'm working on, I want that to be managed by my build chain (especially since the version I'm using in my build may not necessarily match what I have installed on my system to run).

As another example, if someone makes a cook general purpose library using Rust, eventually it should be packaged up and shipped in the normal distro package format by the distro if it's useful. I wouldn't expect cargo to be the normal way to distribute software. It's the Rust equivalent of the old tar -zxvf package-1.2.3.tar.gz && cd package-1.2.3 && ./configure && make && make install. You can do it, but if you have a distro package, use that first.

Re: Two years of Rust

#284

Post by Manishearth » Tue, May 16, 2017, 3:33 PM UTC

kibwen wrote: post #199

Manishearth wrote: post #155

Earlier quoted context omitted.

The dropbox stuff isn't a mix of Rust and C/C++, it's a mix of Rust and Go[1]. (Dropbox has a variety of things using Rust, and IIRC some of them are pure Rust. I don't remember the details.) [1]: https://news.ycombinator.com/item?id=11283758

The OP seems to be mostly referring to the integration with Dropbox's Windows client, which AFAIK is actually Rust+Python. Rust+Go is what Dropbox uses for their storage backend. I personally love that Rust is getting used to complement so many other languages (e.g. Rust's first known production use was as part of a Ruby gem). Easy integration is something to be celebrated, because it means you don't need to rewrite…

Yeah, but none of what Dropbox did is Rust+C++ -- they're not a C++ shop, and Rust was their go-to systems lang.

I'm very happy to see mixing like this too!

Re: Two years of Rust

#285

Post by dmix » Tue, May 16, 2017, 3:37 PM UTC

kibwen wrote: post #5

Yet again allow me to shill for this year's Rust Community Survey, which closes June 12 and is open even to people who've never used Rust: https://blog.rust-lang.org/2017/05/03/survey.html (Yes, I know it's linked from the OP, but who reads that anyway?)

I thought that was strange survey at first, as there were very few questions related to programming and coding with Rust but plenty of questions around engaging with the community (inclusiveness/comfort level, conference attendance, etc). But then I realized it was a "Rust Community Survey".

Is there another survey more suited to use Rust as a language ala "State of Clojure"? I don't use Clojure anymore but I still love reading these every year to keep up to date with the progress it's making.

For ex: http://blog.cognitect.com/blog/2017/1/31/state-of-clojure-20...

Edit: Oh nevermind, it seems the questions change if you select 'Yes' or 'No' at the beginning for "still using Rust". I didn't totally stop using Rust I just spent time learning it, experimenting on some projects, but I don't have a day-to-day need for it - not sure if either possible answer applied to me.

Re: Two years of Rust

#286

Post by steveklabnik » Tue, May 16, 2017, 4:30 PM UTC

kbenson wrote: post #283

flukus wrote: post #272

Earlier quoted context omitted.

> but every package manager for every OS out there does things differently, Rust can not fix this. Exactly, it can't fix it but it tries to cover over this fact by bundling dependencies with every app. > I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there Basically, but more to the point, when a bug or security issue is fixed I don't wa…

While I understand your point, there is a difference between something installed through cargo for use in building software (in the manner rust does, where it's generally statically compiled), and something installed through the package manager for use in running the system . If I'm installed zlib for general system use, I want a package manager. If I'm installing a Rust compression library to be compiled into the pr…

> I wouldn't expect cargo to be the normal way to distribute software

To be clear, neither does the Rust team. You're exactly on point here.

Re: Two years of Rust

#287

Post by goatlover » Tue, May 16, 2017, 4:35 PM UTC

kibwen wrote: post #180

goatlover wrote: post #131

Earlier quoted context omitted.

If you mean Java replaced C/C++ as the most widely used language, at least according to one index, then that's one thing. So if someday Rust became as popular, great for Rust. But that's not the same thing as claiming that Rust will be the One True Programming language in use that will cause all the other language communities to die out and convert to Rust. That's what is being claimed above, and what some in the Jav…

> that's not the same thing as claiming that Rust will be the One True Programming language Again, who is claiming this? Can you link me?

Just go up several posts and read the end of the one I initially replied to.

Re: Two years of Rust

#288

Post by kbenson » Tue, May 16, 2017, 5:53 PM UTC

zzalpha wrote: post #58

sillysaurus3 wrote: post #49

Earlier quoted context omitted.

I tend to agree, but being able to have a REPL at all is a symptom that your language is capable of an extremely fast compile-run-debug cycle. In other words, if you can't implement a REPL, that's the definition of "less productive language." It's not about the REPL itself but the capability of implementing one. Think about it like this: On your list of languages, which of them would you say is most productive? It de…

Think about it like this: On your list of languages, which of them would you say is most productive? Define productive. Are you measuring raw lines of code generated? Or are we measuring amount of production-ready code? My bet: with an experienced, diligent developer it's a wash. My gut says what you lose in a slow code-execute cycle of static, compiled languages you gain in lower defect rates from compile-time check…

> with fewer surprising semantics (crossing Perl and Javascript off the list)

Actually, I think Perl has fairly few surprising semantics after you learn the major ones. The real problem is that the major one (or specifically the major one, context) is somewhat hidden in normal C-like usage until it jumps out at you and confuses you. Once you understand what it is, it's not all that surprising (but there are a few annoyances with it that still persist and cause problems). You can write Perl that looks almost exactly like C 95% of the time, but that 5% where it matters makes people that do this very confused. There are, of course, other parts of the language that are poorly chosen, but I maintain there are actually far less of them than many people seem to think.

As for JavaScript, I still can't get over all the different ways to check for equality and null or undefined. I understand a good portion of that is because I never have to use JS enough to become truly proficient, and some if it is just poor design.

Re: Two years of Rust

#289

Post by nickpsecurity » Tue, May 16, 2017, 6:23 PM UTC

pjmlp wrote: post #243

nickpsecurity wrote: post #234

Earlier quoted context omitted.

Maybe I misread as I quickly moved through the thread. It does look ambiguous now. All I'll claim is horrible compile times on C++. I'm not sure where Rust is at now.

On personal projects sadly slower than C++ equivalents. But I do take advantage of all VC++ improvements for fast C++ compilation, even playing around with the ongoing research work for C++ modules.

How does it compare to the free C++ compilers in building large projects like you described in other post on 30 vs 5 min?

Re: Two years of Rust

#290

Post by sqeaky » Tue, May 16, 2017, 6:29 PM UTC

goatlover wrote: post #287

kibwen wrote: post #180

Earlier quoted context omitted.

> that's not the same thing as claiming that Rust will be the One True Programming language Again, who is claiming this? Can you link me?

Just go up several posts and read the end of the one I initially replied to.

I wasn't claiming it and I even qualified my statement. I am not sure what more I could to make it clear that no languages have actually been replaced, while retaining a nuanced message that many people see replacements depending on their perspective. Then I even cited source to back it up with some some numbers.

If you want to argue with some several post up, please go several posts up. If you want to argue against me, than please do so on the merits of what I said.