Live data from Hacker News

Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

blog.rust-lang.org

41–50 of 135 posts

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#41

Earlier quoted context omitted.

Yeah, I wonder how he manages to juggle all of that. What's your secret wycats? (I'm not really expecting there to be a single secret).

Maybe "wycats" is plural and he has a team of people implementing him, like Stephen King or TJ Holowaychuk.

What separates TJ from a lot of us is that he isnt afraid to actually go and read some source code,no matter what the language is. That's what separates the good devs from the average ones.How many of us actually read the source of libs or frameworks we use everyday? not that many. But he also have a thing for simplicity,and that is a matter of taste.

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#42
post #21
post #16

Earlier quoted context omitted.

I replied to this a bit on the other HN thread on this topic: https://news.ycombinator.com/item?id=8741987 TL;DR embedding small libraries with high-performance or low-memory requirements into programs written in high-level languages.

Since you know a lot about web frameworks : do you see rust becoming a good language for building a modern web framework anytime soon ?

One of the nice things about Rust is that it provides a lot of high-level abstraction capability in a way that doesn't impose any cost on the abstraction.

This means that, in theory, one could make a pretty good web framework in Rust that would be both quite fast and ergonomic. That said, writing those abstractions will take time, so we'll probably see lower-level HTTP libraries, followed by Express-style abstractions, followed further on by full-stack solutions like Rails.

The earlier parts of the stack are coming along quite well, so give it a few years and I think we'll have a pretty good story to tell. In the meantime, you can use Rust today very effectively as a language that you embed inside a high-level language, and I think a sizable chunk of the Rust community will use Rust for those kinds of embedding use-cases in perpetuity.

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#43
post #40

How will this affect Yehuda's involvement with Ember? I'm kinda scared he will jump ship and leave it in the air. :/

Most definitely not. Ember (and its ecosystem) and Rust are the two open source projects that are currently consuming most of my time. I have easily spent as much time on the planning for Ember 2.0, HTMLBars, and Service Side Rendering as I have on Cargo and Rust over the past six months or so. Also, both Ember and Rust are critical for my business (Skylight), and keeping them both strong and effective are key to my…

Thank you sincerely, Ember has been amazing and it's great to hear you don't plan to drop it.

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#44
post #11

Earlier quoted context omitted.

For what it's worth, a big part of this is slowly winding down earlier commitments over time. I joined TAG a couple years ago, and decided not to run again this year because I had largely achieved my original goals of changing the composition and mission of the TAG, and others can carry the torch forward. I also retired from the Rails team this year after a somewhat-long period of inactivity (from day-to-day decision…

How would you respond to those who see you merely as somebody who just hops on the bandwagon, so to speak, quite frequently? Whether this perception is right or wrong, there are a number of prominent individuals within the open source community who are widely seen as rapidly jumping between trendy or hyped projects as they arise, to benefit from the exposure that this involvement can bring. I'm not passing any judgme…

To be blunt, I would not have picked Ember, Handlebars, TAG or TC39 due to their "hype factor".

In the cases of TAG and TC39, I saw an opportunity to take low-hype, low-bandwagon organizations and revitalize their missions and purpose. In particular, bringing on web developers as active participants and the follow-on effects of having them join GitHub and modern practices (slowly), helped increase their profile and stature. In both cases, I hardly did most of the work, but I did spend a lot of time articulating a vision for these organizations as ones that could be far more effective by involving more practitioners. I think it has worked.

In the cases of Ember and Handlebars, I saw something missing in the ecosystem and built my own tools. In both cases, the tools were hardly instant-winners, and I had to spend a ton of time recruiting fellow-minded collaborators who shared a vision for the future. If I was in it for the bandwagon-hopping, I would have tried to join Mustache or Angular, and not spend years to build up my own, relatively small-in-comparison ecosystems.

My real MO is to try to envision a better future for something related to the web or my product, and then either find existing projects that already share a part of that vision or create them if they do not. My involvement in many different projects is because of the fact that big-picture ideas involve improvements to multiple technologies.

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#45
post #21
post #16

Earlier quoted context omitted.

I replied to this a bit on the other HN thread on this topic: https://news.ycombinator.com/item?id=8741987 TL;DR embedding small libraries with high-performance or low-memory requirements into programs written in high-level languages.

Since you know a lot about web frameworks : do you see rust becoming a good language for building a modern web framework anytime soon ?

Having programmed a bit of Rust, while Rust will definitely be a very capable language for web frameworks/applications, I don't think that it'll ever be the most popular choice.

To be honest, if you think about your Rails controllers/models, 1. There isn't really all that much there(fat-models/controllers are pretty slim when you're language was built for web browsers/operating systems). 2. Think about your priorities. I can guarantee its not performance or safety. You want to build a content-rich/feature-full application. Basically, prioritize iteration speed, at all costs. No matter how good the Rust frameworks get, I don't think Rust will be the "iteration speed" language.

Meanwhile, I think, in the spirit of wycats' comment, image if ActiveRecord, Unicorn, Rack, the template renderers, etc, were all built with Rust, but still used through a Ruby interface. That would be quite the performance improvement for Rails and it would be interesting to compare its performance characteristics to a fully Rust web framework/application.

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#47
post #27

Anyone care to mention the best reasons to start using/learning Rust? There must be a lot with these guys joining the team.

It allows you to predictably squeeze more out of your system than you ever could in a higher level language without the worry of weird undefined behavior, buffer overflows, use-after-frees or segfaults. It also has an expressive static type system that draws a great deal from ML and Haskell.

What would be the reason to learn Rust over Haskell? They seem to be about in the same speed ballpark:

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

Is that not representative, or is the idea that Rust speeds the learning curve with its similarity to Ruby?

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#48
post #47
post #27

Earlier quoted context omitted.

It allows you to predictably squeeze more out of your system than you ever could in a higher level language without the worry of weird undefined behavior, buffer overflows, use-after-frees or segfaults. It also has an expressive static type system that draws a great deal from ML and Haskell.

What would be the reason to learn Rust over Haskell? They seem to be about in the same speed ballpark: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Is that not representative, or is the idea that Rust speeds the learning curve with its similarity to Ruby?

(1) Even in that benchmark, Haskell is over twice as slow as Rust on average.

(2) The Haskell code is nowhere near idiomatic.

It is still useful to know that Haskell can be quite fast if necessary, but it likely does not reflect what your actual experience using Haskell would be.

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#49
post #44

Earlier quoted context omitted.

How would you respond to those who see you merely as somebody who just hops on the bandwagon, so to speak, quite frequently? Whether this perception is right or wrong, there are a number of prominent individuals within the open source community who are widely seen as rapidly jumping between trendy or hyped projects as they arise, to benefit from the exposure that this involvement can bring. I'm not passing any judgme…

To be blunt, I would not have picked Ember, Handlebars, TAG or TC39 due to their "hype factor". In the cases of TAG and TC39, I saw an opportunity to take low-hype, low-bandwagon organizations and revitalize their missions and purpose. In particular, bringing on web developers as active participants and the follow-on effects of having them join GitHub and modern practices (slowly), helped increase their profile and s…

high five bro!

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#50
post #47
post #27

Earlier quoted context omitted.

It allows you to predictably squeeze more out of your system than you ever could in a higher level language without the worry of weird undefined behavior, buffer overflows, use-after-frees or segfaults. It also has an expressive static type system that draws a great deal from ML and Haskell.

What would be the reason to learn Rust over Haskell? They seem to be about in the same speed ballpark: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Is that not representative, or is the idea that Rust speeds the learning curve with its similarity to Ruby?

Idiomatic, typical Rust code does not involve a garbage collector, which makes it suitable for embedding in environments with a garbage collector as well as any application with real-time (no pauses) requirements.
Post reply on HN