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

51–60 of 312 posts

Re: Two years of Rust

#51

Post by dwaltrip »

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…

Just because you don't understand the benefits other people get from a REPL doesn't mean they don't exist.

Re: Two years of Rust

#52

Post by comex »

webkike wrote: post #33
comex wrote: post #18

Earlier quoted context omitted.

Go, at least, is far simpler as a language than Rust, and the implementation (compiler) is less complex overall, especially if you count LLVM on Rust's side. I suppose that Go programs exhibit more complex behavior at runtime due to the GC and green threads and stuff, but it's a huge stretch to call Go more complicated overall. On the other hand, I'd argue that Rust makes up for the complexity with performance, power…

Consider how interfaces work and how you would have to implement them. Rust may have a more complicated type system and I suppose enums are more complicated in Rust, but the things I value as simple are more simple in Rust than Go.

What about interfaces? The basic idea of fat pointers with vtables works the same as Rust's trait objects. If you mean the ability to dynamically cast from one interface type to another, which Rust doesn't support - that does require a global list of implemented interfaces per type, but without generics that's not too hard to implement. (In Rust, it would be drastically more complex, verging on impossible to pull off with a good UX, due to various language features including wildcard impls, type-parameterized traits, and a Turing-complete type system.)

Re: Two years of Rust

#53

Post by mmstick »

lilyball wrote: post #48
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.

Your site is returning brotli-encoded data even when the browser doesn't support it. At least, I assume that's what it's doing, because the return value is complete garbage and it contains a "Content-Encoding: br" header.

Naturally. Since moving to HTTPS, I have dropped support for gzip, and I will not be re-adding it. There is no benefit in continuing to retain legacy gzip support. Brotli can compress and decode faster than gzip, and it produces smaller file sizes. That Safari still doesn't support Brotli isn't my problem. It's Apple's problem. I'm not going to be yet another site that condones stagnant progress when everyone else has already supported it for more than a year. More sites should drop gzip support to force Apple to add support for Brotli in Safari.

Re: Two years of Rust

#54

Post by zzalpha »

dwaltrip wrote: post #51
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…

Just because you don't understand the benefits other people get from a REPL doesn't mean they don't exist.

Just because there are benefits, doesn't make it a deal-breaker.

Re: Two years of Rust

#55

Post by tatterdemalion »

brandur wrote: post #38
ben_jones wrote: post #27

Earlier quoted context omitted.

In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc.

> In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc. I think the most classically cited problem is the learning curve. Understanding ownership and lifetimes, and understanding how to satisfy the borrow checker can be quite daunting. Here are a few that I…

I think we all agree that future chaining isn't great surface API in the long-term, but we have a pretty good idea of how to desugar async/await to the futures we have. That's why we're build the runtime around them; because they're fast and they will (someday) have a relatively convenient API.

Re: Two years of Rust

#56

Post by coldtea »

brandur wrote: post #38
ben_jones wrote: post #27

Earlier quoted context omitted.

In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc.

> In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc. I think the most classically cited problem is the learning curve. Understanding ownership and lifetimes, and understanding how to satisfy the borrow checker can be quite daunting. Here are a few that I…

>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?

Re: Two years of Rust

#57

Post by steveklabnik »

coldtea wrote: post #56
brandur wrote: post #38

Earlier quoted context omitted.

> In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc. I think the most classically cited problem is the learning curve. Understanding ownership and lifetimes, and understanding how to satisfy the borrow checker can be quite daunting. Here are a few that I…

> 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?

Async/await is commonly suggested as a lighter-weight syntax.

Re: Two years of Rust

#58

Post by zzalpha »

sillysaurus3 wrote: post #49
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…

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 checks. Conversely, what you gain in a dynamic language, you lose in errors caught at run-time.

At that point I'd select for languages that are simpler with fewer surprising semantics (crossing Perl and Javascript off the list), with more built-in run-time and/or compiler safety (knocking things like C off the list). I generally also prefer compile-time safety over run-time safety, as I'd rather find problems on my workstation than in the field because I missed testing a codepath.

Re: Two years of Rust

#59

Post by arianvanp »

coldtea wrote: post #56
brandur wrote: post #38

Earlier quoted context omitted.

> In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc. I think the most classically cited problem is the learning curve. Understanding ownership and lifetimes, and understanding how to satisfy the borrow checker can be quite daunting. Here are a few that I…

> 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#)

Re: Two years of Rust

#60

Post by jononor »

mmstick wrote: post #53
lilyball wrote: post #48

Earlier quoted context omitted.

Your site is returning brotli-encoded data even when the browser doesn't support it. At least, I assume that's what it's doing, because the return value is complete garbage and it contains a "Content-Encoding: br" header.

Naturally. Since moving to HTTPS, I have dropped support for gzip, and I will not be re-adding it. There is no benefit in continuing to retain legacy gzip support. Brotli can compress and decode faster than gzip, and it produces smaller file sizes. That Safari still doesn't support Brotli isn't my problem. It's Apple's problem. I'm not going to be yet another site that condones stagnant progress when everyone else ha…

You just broke your site for 40% of the web. http://caniuse.com/#feat=brotli
Post reply on HN