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

81–90 of 312 posts

Re: Two years of Rust

#81

Post by zambal »

zzalpha wrote: post #43
sillysaurus3 wrote: post #40

Earlier quoted context omitted.

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. If you understood the wins of untyped languages, you'd be aware that this is often the most optimal path for a startup to take. Get features done now + fix them later is, in hundreds of cases, the way that startups win. It's also a win for people w…

If your language doesn't have a REPL, your language is less productive. Deal with it. Oh hardly. As someone who's developed software in Perl, Python, C, Java, C#, Haskell, and a few others besides, a REPL is the one thing I use the least . I've honestly never understood the obsession with it. Is a rapid compile-run-debug cycle important? Absolutely. If I want to test something in isolation, being able to rapidly turn…

The usefulness of a REPL depends a lot on the language/interpreter/vm. In Erlang and Elixir the REPL is imo more than a nice to have. Being able to connect to a production node and peeking around what is happening can be very valuable.

I guess it's one of those things that's imho hard to appreciate if you never experienced it.

Re: Two years of Rust

#82

Post by brandur »

arianvanp wrote: post #59
coldtea wrote: post #56

Earlier quoted context omitted.

> about how futures-based concurrency spreads into your code through huge amounts of necessary boilerplate (`.and_then(...).and_then(...).and_then(...)`) How is that more boilerplate than any other way to have concurrency?

Do notation makes this stuff a whole lot more readable (See Haskell). Or Async-await (See C#)

+1. Also, Go's goroutines and channels.

Re: Two years of Rust

#83

Post by jleahy »

omaranto wrote: post #16
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…

Compiled languages can have REPLs too. Common Lisp and Haskell come to mind.

Or ROOT for C++ (used by CERN)

https://root.cern.ch/

Re: Two years of Rust

#85

Post by zzalpha »

zambal wrote: post #80
zzalpha wrote: post #43

Earlier quoted context omitted.

If your language doesn't have a REPL, your language is less productive. Deal with it. Oh hardly. As someone who's developed software in Perl, Python, C, Java, C#, Haskell, and a few others besides, a REPL is the one thing I use the least . I've honestly never understood the obsession with it. Is a rapid compile-run-debug cycle important? Absolutely. If I want to test something in isolation, being able to rapidly turn…

The usefulness of a REPL depends a lot on the language/interpreter/vm. In Erlang and Elixir the REPL is more than nice to have. Being able to connect to a production node and peeking around what is happening can be very valuable. I guess it's one of those things that's imho hard to appreciate if you never experienced it.

The usefulness of a REPL depends a lot on the language/interpreter/vm. In Erlang and Elixir the REPL is more than nice to have. Being able to connect to a production node and peeking around what is happening can be very valuable.

That's called a remote debugger, and it's hardly unique to languages supporting a REPL.

Re: Two years of Rust

#86

Post by mmstick »

eridius wrote: post #74
mmstick wrote: post #70

Earlier quoted context omitted.

That would require that I cache both a gzip and brotli variant of each page and content that is requested. I see no reason to support gzip just because a single company has refused to implement support for Brotli. Firefox, Chrome and Edge all support Brotli. Safari is the one man out. Apple needs more complaints about the lack of Brotli in Safari. Using Safari? Don't. You have Firefox and Chrome on all of your platfo…

This is an incredibly user-hostile attitude. Also, you don't seem to understand. I'm not telling you to support gzip . If the browser doesn't support Brotli, then just send back uncompressed content. And it's not just Safari. All sorts of tools that support HTTP don't support Brotli. Case in point, I ran `curl` against your page and got garbage back.

It's not user-hostile at all. It is quite simple. I don't want to implement gzip support, and I definitely don't want uncompressed content. You can't demand me to implement what I don't want to implement for my website. You are not my target audience (gzip users, IE users, Safari users).

> And it's not just Safari. All sorts of tools that support HTTP don't support Brotli. Case in point, I ran `curl` against your page and got garbage back.

My website does not support HTTP. HTTP is basically a legacy protocol at this point. My website is HTTPS-exclusive. It does not listen on port 80. That Brotli doesn't work through HTTP is not surprising, given that HTTPS support is a base requirement for Brotli support.

Re: Two years of Rust

#87

Post by mmstick »

gue5t wrote: post #77
mmstick wrote: post #69

Earlier quoted context omitted.

I see it as more of an Apple problem. Everyone else's web browser works fine, but Apple's doesn't. The main reason why companies like Apple still don't support Brotli even though the competition has supported it for more than a year now is because too many sites are focused on carrying legacy support for unsupported platforms like Safari. If more sites dropped support for legacy software, Apple would be forced to imp…

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.

Re: Two years of Rust

#88

Post by mmstick »

eridius wrote: post #79
mmstick wrote: post #69

Earlier quoted context omitted.

I see it as more of an Apple problem. Everyone else's web browser works fine, but Apple's doesn't. The main reason why companies like Apple still don't support Brotli even though the competition has supported it for more than a year now is because too many sites are focused on carrying legacy support for unsupported platforms like Safari. If more sites dropped support for legacy software, Apple would be forced to imp…

Have you filed a bug report asking Apple to support Brotli ( https://bugreport.apple.com )? And it's not just Safari. 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. Safari sends the Accept-Encoding header with a value of "gzip, deflate". If you're unwilling to support either of those, and unwilling to retur…

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 website should be encrypted.

> If you're unwilling to support either of those, and unwilling to return an uncompressed response, then you SHOULD return a 406 (Not Acceptable) instead of just blindly returning Brotli-encoded data to a client that doesn't understand it.

I may do just that then.

Re: Two years of Rust

#89

Post by [deleted] »

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.

[deleted]

Re: Two years of Rust

#90

Post by eridius »

mmstick wrote: post #86
eridius wrote: post #74

Earlier quoted context omitted.

This is an incredibly user-hostile attitude. Also, you don't seem to understand. I'm not telling you to support gzip . If the browser doesn't support Brotli, then just send back uncompressed content. And it's not just Safari. All sorts of tools that support HTTP don't support Brotli. Case in point, I ran `curl` against your page and got garbage back.

It's not user-hostile at all. It is quite simple. I don't want to implement gzip support, and I definitely don't want uncompressed content. You can't demand me to implement what I don't want to implement for my website. You are not my target audience (gzip users, IE users, Safari users). > And it's not just Safari. All sorts of tools that support HTTP don't support Brotli. Case in point, I ran `curl` against your pag…

From your last paragraph I question whether you really understand anything you're being told here.

Yes, I said HTTP instead of HTTPS, but that wasn't meant to signify that I was using unsecured HTTP, since HTTPS is supported virtually everywhere and generally understood to be a part of HTTP. More specifically, if I actually try and access http://mmstick.tk, I just get redirected to https://mmstick.tk anyway, without having a content body, so it's not even possible to get Brotli-encoded data out of your server over HTTP. And if I run `curl https://mmstick.tk` then I get garbage, which was the whole point of that sentence and what you still haven't even addressed.

Also, how can HTTPS possibly be a requirement for Brotli? Brotli is a compression format, it doesn't care what the medium of transmission is, and it works just fine over HTTP. It just won't work with your site over HTTP because your site doesn't serve any content over HTTP.

Post reply on HN