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

Two years of Rust

blog.rust-lang.org

Post reply on HN
Print view View original

151–160 of 312 posts

Re: Two years of Rust

#151

Post by nickpsecurity »

derefr wrote: post #116
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…

Why must productivity be measured in "smallest amount of time to write your feature"? Why not in "smallest Total Cost of Ownership [in man-hours] of the feature over the project lifecycle"? Some projects are written as explorational prototypes or MVPs. I don't think anyone is saying Rust is much good for those. But (numerous) other projects are written as "the first real Quality implementation of [well-known problem]…

"Why must productivity be measured in "smallest amount of time to write your feature"? Why not in "smallest Total Cost of Ownership [in man-hours] of the feature over the project lifecycle"?"

In the case of startups, their goal is to sell out way before the maintenance phase of the lifecycle. So, it doesn't really matter to them so much as quickly getting out working features. In other cases, esp long-lasting endeavors, then this is a good point to consider.

Re: Two years of Rust

#152

Post by Manishearth »

cyphar wrote: post #93
Animats wrote: post #72

The success stories are Mozilla's Servo, Dropbox's client and back end, and parts of Gnome. That's good. It's interesting that all the success stories involve mixing Rust and C/C++ code. Are there any pure Rust successes yet?

I was under the impression that Mozilla Servo is entirely written in Rust (GitHub appears to not be able to run linguist on the repo at the moment, the language detection isn't showing up).

We use some C/++ components (the JS engine is purely C++, and we bind to various C/++ libraries for things like graphics. We don't have the resources to rewrite everything).

All the interesting bits are Rust :)

Re: Two years of Rust

#153

Post by fizixer »

nickpsecurity wrote: post #143
fizixer wrote: post #133

Earlier quoted context omitted.

Looking at Modula-3 wikipedia page, no thanks. (If it's case-sensitive, I don't want to switch to uppercase everytime I use the language keywords. If it's not case-sensitive, don't even get me started.) I had enough of that for a lifetime through FORTRAN, COBOL, SQL, BASIC, ASSEMBLY, etc. PreScheme sounds like an interesting idea.

Do you have anything to say about it's feature set instead of just syntactic preference? As in, it's tradeoff in balancing complexity by what set of features?

Looking at it very briefly, its feature set is probably small enough to keep the language simple yet useful.

To be clear, I'm not a Rust guy, or even C++, Go, D.

On top of that, I'm a 2PL advocate (two programming languages). I think a combination of a readable high-level language like Python or Scheme, and a fast systems language like C, can carry out feats that no single programming language can as far as I know. (I don't consider keeping two or three programming language in your head while doing productive work a big deal, especially when learning multiple language is considered a beneficial thing).

Re: Two years of Rust

#154

Post by fnord123 »

mcorbin wrote: post #100
zzalpha wrote: post #64

Earlier quoted context omitted.

Yup, that's fair. BTW, I actually stand by your interpretation. I challenge anyone to demonstrate significant productivity gains (as measured by number of lines of tested, production code written) that can be attributed to the availability of a REPL (which was the claim of the poster I was replying to). I honestly don't buy it. I believe it's a very nice tool for learning a new language, and maybe for exploring an ex…

Try Clojure.

That's hardly fair. Clojure is unusable without having a REPL already loaded.

    $ time lein run 
    Hello, World!

    real	0m5.683s
    user	0m5.981s
    sys	0m0.557s

Re: Two years of Rust

#155

Post by Manishearth »

Animats wrote: post #72

The success stories are Mozilla's Servo, Dropbox's client and back end, and parts of Gnome. That's good. It's interesting that all the success stories involve mixing Rust and C/C++ code. Are there any pure Rust successes yet?

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

Re: Two years of Rust

#156

Post by nickpsecurity »

goatlover wrote: post #95
zzalpha wrote: post #64

Earlier quoted context omitted.

Yup, that's fair. BTW, I actually stand by your interpretation. I challenge anyone to demonstrate significant productivity gains (as measured by number of lines of tested, production code written) that can be attributed to the availability of a REPL (which was the claim of the poster I was replying to). I honestly don't buy it. I believe it's a very nice tool for learning a new language, and maybe for exploring an ex…

Lispers might be able to meet that challenge.

I could probably have countered it, too, in the same language during the challenge back when I used it. I found the incremental, per-function compilation feature reduced compilation time of most changes to a fraction of a second. Most of time in programming is spent thinking, tweaking, debugging, dealing with 3rd-party libs, etc. I don't think a difference in the source-to-execution part of under 1 second is going to make a big deal.

It's high-speed iteration of code one is exploring that makes both REPL's and incremental compilation superior for productivity to full compilation.

Re: Two years of Rust

#157

Post by steveklabnik »

breerly wrote: post #147

Curious, since I haven't been following closely - is Tokio fit for both IO and CPU-bound work, or do you need to break into threads? I use Golang daily, and have been spoiled by the opinionated approach taken to solving both CPU and IO-bound workloads.

In one sense, IO, and in another sense, both; that is, what you do there is use futures-cpupool, which is a threadpool with a futures interface. So it still all composes just fine.

Re: Two years of Rust

#158

Post by derefr »

Manishearth wrote: post #148
derefr wrote: post #99

Earlier quoted context omitted.

> I've honestly never understood the obsession with it. The true key to understanding REPLs is their role in consuming third-party libraries. While languages both with and without REPLs will have well-used packages in their package ecosystems that are well-documented ; languages with REPLs will also manage to have well-used, poorly-documented packages: packages whose "documentation" consists only of the de-facto abil…

Note that with strong typing this is less of an issue -- with Rust you can just go to " rel="nofollow">http://docs.rs/ and navigate the structured docs. They may lack explanatory text, but you can click around them and search and it's overall much nicer than fiddling around in a REPL. (Still, doesn't fit all use cases of a REPL for this. REPLs are especially nice for when you want to fit together highly generic APIs)

True; but also, "strong typing" on its own isn't a panacea for guidance; unless you're writing Coq or Agda, the API functions you're calling are still going to have preconditions that are not encoded in the type signature, so you're still (partially) reliant on having either good docs or a REPL [or clumsy REPL-equivalent, like exploratory unit tests] to inform you of those preconditions.

And if you are writing Coq or Agda—well, you certainly don't need a REPL at that point. The code writes itself. ;)

Re: Two years of Rust

#159

Post by wtetzner »

mcorbin wrote: post #100
zzalpha wrote: post #64

Earlier quoted context omitted.

Yup, that's fair. BTW, I actually stand by your interpretation. I challenge anyone to demonstrate significant productivity gains (as measured by number of lines of tested, production code written) that can be attributed to the availability of a REPL (which was the claim of the poster I was replying to). I honestly don't buy it. I believe it's a very nice tool for learning a new language, and maybe for exploring an ex…

Try Clojure.

At one point I wrote Clojure for my day job. I think having a REPL is actually more useful for untyped languages, especially Clojure, where most data "types" are maps/lists. By exploring in the REPL, you can get a good feel for what kinds of data a function works with.

In a statically typed language, a REPL can still be useful, but the gains from it are less than you'd get with an untyped language. It's easy to see what kinds of data a function works with by just looking at the types. There are exceptions of course, like when the type is very complicated, it can be helpful to see some examples of actual values of the type. And I suppose that's why languages like Haskell and OCaml have REPLs.

Re: Two years of Rust

#160

Post by mmstick »

jacquesm wrote: post #144
mmstick wrote: post #88

Earlier quoted context omitted.

I don't use Apple products, nor am I user of Safari. It's not in my interest to request for Brotli support in products that I do not use. > I think it's safe to say the overwhelming majority of software that issues HTTP requests does not support Brotli. And you're also not following the HTTP spec. Again, I do not support HTTP! The website is HTTPS-exclusive. HTTP is basically a legacy protocol at this point. Every we…

I'll bet if your food depended on that 40% you'd fix it in a heartbeat.

I highly doubt that anyone depends upon a personal blog for food.
Post reply on HN