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

221–230 of 312 posts

Re: Two years of Rust

#221

Post by [deleted] »

derefr wrote: post #209
zzalpha wrote: post #204

Earlier quoted context omitted.

or rather, a language runtime that enforced some level of introspect-ability on everything And now we get to the real meat of it. It's not a REPL you want. It's reflection. It just so happens that the latter is frequently paired with the former. And I agree, that feature, which separates C#, Java, Ruby, Perl, Python, etc, from legacy languages like C make them significantly easier to use as a developer as the compile…

Reflection isn't orthogonal to a REPL; it's synergistic with a REPL. When you have a static language, yes, REPLs don't add much; reflection by itself is all you need and an IDE will suit you fine. But when you are working in a language with runtime code generation —one where objects can build themselves new runtime-native function handles in response to messages—then a REPL will be able to do things for you that an I…

[deleted]

Re: Two years of Rust

#222

Post by Ygg2 »

sillysaurus3 wrote: post #78
tatterdemalion wrote: post #63

Earlier quoted context omitted.

> Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else? Let's be clear - the person who said there'd be no reason to write in anything else is an enthusiastic Rust user, but they don't work on Rust & don't represent "the Rust community." Th…

Let's be clear - the person who said there'd be no reason to write in anything else is an enthusiastic Rust user, but they don't work on Rust & don't represent "the Rust community." Respectfully, the community has become increasingly vocal, and it's getting hard to separate the enthusiasm from realism. It's embedded in every HN thread. That's a good problem to have, but it can be a bit repellant to people who aren't…

Except one of tenets of Rust community is don't be a language zealot. Don't advocate for rewriting everything, etc.

Re: Two years of Rust

#223

Post by winteriscoming »

dang wrote: post #214
mmstick wrote: post #45

You might like to know that I've had great success with full stack web development using Rust. My website ( https://mmstick.tk ) is hosted with the Rocket ( https://rocket.rs/overview/ ) web framework and operates as a fully static binary with 100% Rust code. I've even got HTTPS and Brotli compression.

We detached this ludicrous flamewar from https://news.ycombinator.com/item?id=14344760 and marked it off-topic. You repeatedly posted uncivilly in these comments. That's a bannable offense on HN, so please don't do it again, regardless of how wrong you think others are.

What a mess! Came to this thread to read about Rust and its progress and this has devolved into a useless discussion about some person's website, who seems to consider that he/she is doing all the right things and the rest of the technical community is stupid.

Completely lost track of what thread I was reading.

Re: Two years of Rust

#224

Post by thristian »

mmstick wrote: post #87
gue5t wrote: post #77

Earlier quoted context omitted.

GNOME's, Xfce's, suckless', and many other web browsers are based on Webkit (WebKit2GTK+ or other ports) as well, and as far as I know none of them yet support brotli. wget and curl both also fail to decompress your site's contents. Same problem in netsurf, lynx, and links.

This is because I don't have a HTTP website! The website is HTTPS-exclusive. If your tool does not support HTTPS, it will certainly not work on my website. > wget and curl both also fail to decompress your site's contents. I'd consider this a good thing, actually.

All the tools mentioned in the comment you're responding to support HTTPS just fine.

Re: Two years of Rust

#225

Post by DiThi »

mmstick wrote: post #138
nercury wrote: post #118

Earlier quoted context omitted.

Please stop claiming to support HTTPS when your site breaks perfectly https-compliant browsers.

It supports HTTPS perfectly fine. I am even on the HSTS preload list. You can't get on this list unless you have a HTTPS website that meets standard requirements. https://hstspreload.org/?domain=mmstick.tk

That page doesn't list as a requirement serving content that the browser can decode.

Re: Two years of Rust

#226

Post by zzalpha »

dang wrote: post #218
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…

You're demanding the impossible here and elsewhere in the thread. Asking for the impossible is maybe ok, demanding it not so much. No one can demonstrate productivity gains because productivity can't be measured. Lines of code can, and those are often a bad thing. Some of our most productive efforts make programs smaller.

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 be measured at all is something I've never heard anyone seriously claim.

Re: Two years of Rust

#227

Post by yorwba »

photojosh wrote: post #182
derefr wrote: post #137

Earlier quoted context omitted.

> What's your experience level with other languages? ~15 years experience across C, ARM assembler, Javascript, Lua, Ruby, Python, Erlang, Go, and Rust. Mostly doing Elixir these days. Admittedly, I've never used an IDE; I write all my C in vim. > ...you write compiled unit tests and/or test programs to poke around at the API. That assumes you can get your tests to compile; or that the compilation errors are at-all he…

> then you'll really wish that you had a REPL Yes. I write roughly equal amounts of C (microcontroller firmware) and Python (overall system control, running on embedded Linux). I absolutely wish I had a REPL for C. When implementing with a new library in Python, I'll usually use iPython to explore it, and if I need to run a decent amount of data through, I'll use a Jupyter notebook. I'd put the difficulty of grokking…

I use gdb as a C REPL. You attach it to a binary that has the functions you need, then you can use them with the `p` (or `print`) command. Loops and new function definitions are not possible, but sometimes it's still good enough.

Re: Two years of Rust

#228

Post by perfmode »

3pt14159 wrote: post #136
brandur wrote: post #10

Earlier quoted context omitted.

> Not being hindered by the compiler telling you what you can and can't do; freeing yourself from the write-compile-debug cycle, reducing it to repl-done; etc. Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost. I saw someone use the analogy of a credit card on here before: purchases are very easy t…

I fully agree with you, but I still start projects in Ruby. Why? Because returns from startups are exponential and the interest rate is higher than the interest rate on the technical debt. It's why compiled is a great choice for an established corporation with a well defined need and a large user base, while interpreted is better for most other business contexts, especially with tools like Numpy.

Have you seen helix? Ruby-Rust interop:

https://usehelix.com/

Re: Two years of Rust

#229

Post by rhblake »

mmstick wrote: post #141
eridius wrote: post #113

Earlier quoted context omitted.

Your use of HTTPS is completely irrelevant here, but I've already addressed that in the other thread ( https://news.ycombinator.com/item?id=14345695 ). > You cannot use Brotli compression over HTTP. This is completely incorrect . Not only does Brotli have literally nothing to do with the transmission medium and whether it's encrypted, but just to be sure I just tested it and Chrome was perfectly happy to render a Bro…

> This is completely incorrect. Not only does Brotli have literally nothing to do with the transmission medium and whether it's encrypted, but just to be sure I just tested it and Chrome was perfectly happy to render a Brotli-encoded response over unsecured HTTP. I highly doubt that you actually tried this in practice. You are merely assuming that it works. For Google to overturn their decision would fly against all…

So lemme try to clear this up.

You are right in that brotli decoding is only supposed to work in secure contexts (so technically not just HTTPS, btw -- localhost is also considered a secure context, see https://bugs.chromium.org/p/chromium/issues/detail?id=624426).

Eridius is right in that it currently does work over insecure HTTP in Chrome, as confirmed in this open bug: https://bugs.chromium.org/p/chromium/issues/detail?id=579606 -- in which one Chromium dev comments "Decoding brotli even if it isn't requested is both bug and feature. It allows developers to test brotli without setting up https serving." Seems like they concluded that it is indeed a bug, however.

Reality and specifications often diverge...

(I do think not supporting gzip is absolutely bizarre, but that's another issue.)

Re: Two years of Rust

#230

Post by dwaltrip »

zzalpha wrote: post #64
dwaltrip wrote: post #61

Earlier quoted context omitted.

I didn't say it was a deal breaker? Your post came off as implying REPLs don't have serious benefits for anyone, which felt a bit presumptuous to me.

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…

One example: REPLs can occasionally be a great way to implement​ helper methods or other well isolated functionality. I understand you might argue unit tests are better for this, but I would very strongly disagree they are better in every situation.

Unit tests provide some additional benefits, but are a heavier approach with a slower, clunkier feedback loop. There are times when those additional benefits are not worth the added cost. Unit tests are also additional code that must be maintained.

Post reply on HN