Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team • Hacker News Board

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

#111

Post by kibwen » Sat, Dec 13, 2014, 4:08 PM UTC

Ygg2 wrote: post #100

Kiro wrote: post #98

Earlier quoted context omitted.

What are the shortcomings?

From what I gather, lack of user defined generics is primary reason, followed by the loose typing in interfaces. I'm not an expert in Go, so feel free to correct me there. Additionally, IIRC Rust wanted to take the same route like GO regarding interfaces and generics, but Niko made an argument that it is wrong turn to make.

  > IIRC Rust wanted to take the same route like GO 
  > regarding interfaces and generics, but Niko made an 
  > argument that it is wrong turn to make.

This is a mistaken conception, as Rust has had something approximating generics since the very beginning (though they have changed drastically since the outset), and traits have always been explicit rather than implicit (and it was pcwalton who initially conceived traits, not nmatsakis (and traits as well have changed drastically since their inception (the bottom line is that pretty much everything about Rust has changed drastically since its inception))).

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

#112

Post by igouy » Sat, Dec 13, 2014, 4:56 PM UTC

imanaccount247 wrote: post #92

igouy wrote: post #91

Earlier quoted context omitted.

>>It is a benchmark, the point of it is to write the fastest code you can. The point of it is to show the performance differences, but that doesn't exclude a program like -- http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... -- or like -- http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... etc

It doesn't exclude "idiomatic" versions, but the data is presented so as to make them useless. How do I compare "idiomatic" rust to "idiomatic" haskell? All you can get is "here's the fastest versions from each language". If you want to compare any other version you have to do it on an individual basis, one at a time. So there's absolutely no reason for people to bother adding "idiomatic" versions.

"Idiomatic" in whose opinion? "Idiomatic" is a slogan not a well-defined property.

The reason for people to bother adding "idiomatic" versions, is that other people really do work through looking at the source code "on an individual basis, one at a time."

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

#113

Post by igouy » Sat, Dec 13, 2014, 5:10 PM UTC

imanaccount247 wrote: post #93

igouy wrote: post #90

Earlier quoted context omitted.

> A regex benchmark doesn't tell you much of anything… And yet, the programs don't all perform the same. One regex task doesn't tell you much of anything because so much can be different with a different task. Then again, people are usually surprised by V8 and Irregexp. The GHC version has been updated so many times since the last programs were contributed, that I hope the code would look better if it was written to…

>And yet, the programs don't all perform the same. Because they don't all use pcre. Duh? >The GHC version has been updated so many times since the last programs were contributed, that I hope the code would look better if it was written to use the latest greatest Haskell. Why on earth would the code change because of a new compiler release? Do people rewrite the C one every time a new GCC is released? And the code loo…

>>Because they don't all use pcre. Duh?"Duh?" because you haven't looked at the code?

http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

>>Why on earth would the code change because of a new compiler release?New GHC releases (and libraries) have in the past provided new ways to write the code.

>>what "better" do you want?Any "better" that 6 or 7 releases has provided.

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

#114

Post by yonibot » Sat, Dec 13, 2014, 5:48 PM UTC

wycats wrote: post #40

sergiotapia wrote: post #35

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…

This is reassuring - I'm happy to know that you've bet your personal business on it, and really glad that they've got you and Steve on board. Looking forward to great things from Rust, and excited to get more involved!

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

#115

Post by yonibot » Sat, Dec 13, 2014, 5:49 PM UTC

nardi wrote: post #4

Thus continues Yehuda's quest to join every cool core team on the Internet. :) See also: Rails, Bundler, Ember.js, jQuery, W3C TAG, TC39.

Guess who makes them cool :)

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

#116

Post by yonibot » Sat, Dec 13, 2014, 5:55 PM UTC

jonahx wrote: post #107

MichaelGG wrote: post #76

Earlier quoted context omitted.

The main similarity is that Go was called a systems language for some reason, and the idea is now cached in people's minds.

Could you explain what differences make Go optimized for server software and Rust for systems software/C replacement? I'm not being rhetorical -- I genuinely don't understand and would like to. Related: Would Rust be a bad choice for backend web development (ie, an alternative for Ruby/Python) and why or why not?

It's not mature enough to be a contender for Ruby/Rails or Python/Django yet, but assuming it gets there, it may offer incredible performance. Teepee (a Rust HTTP library under development) put together a page that explains the current state of affairs: http://arewewebyet.com/

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

#117

Post by platz » Sat, Dec 13, 2014, 6:25 PM UTC

igouy wrote: post #112

imanaccount247 wrote: post #92

Earlier quoted context omitted.

It doesn't exclude "idiomatic" versions, but the data is presented so as to make them useless. How do I compare "idiomatic" rust to "idiomatic" haskell? All you can get is "here's the fastest versions from each language". If you want to compare any other version you have to do it on an individual basis, one at a time. So there's absolutely no reason for people to bother adding "idiomatic" versions.

"Idiomatic" in whose opinion? "Idiomatic" is a slogan not a well-defined property. The reason for people to bother adding "idiomatic" versions, is that other people really do work through looking at the source code "on an individual basis, one at a time."

This exact thread came up last year when we started talking about the shootout and haskell. And Its always the same people who bring up the shootout and defend the existing entries.

Please stop bringing up the shootout (esp when haskell is mentioned) and dragging everyone through this conversation again.

Benchmarks are great to debate but this one is causing more harm than good; let's talk about other benchmarks.

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

#118

Post by reledi » Sat, Dec 13, 2014, 8:17 PM UTC

wycats wrote: post #11

adamnemecek wrote: post #5

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

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…

Would you mind explaining more about how you find and recruit fellow-minded collaborators and eventually delegate tasks to them?

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

#119

Post by ralfn » Sat, Dec 13, 2014, 8:43 PM UTC

MichaelGG wrote: post #76

bjz_ wrote: post #60

Earlier quoted context omitted.

Rust and Go do not overlap much other than they are both natively compiled, have curly braces and are backed by 'web' companies. Go was designed for building server software and for encouraging standardized, easy to maintain software. Rust on the other hand is generally targeted at the same areas where C and C++ are used for today.

The main similarity is that Go was called a systems language for some reason, and the idea is now cached in people's minds.

I think some people refer to "Systems language" as a language you would write services and back-end code in, like Java, rather than than a language you would use to write a kernel driver or a render engine, like C.

It confused me a bit initially.

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

#120

Post by ralfn » Sat, Dec 13, 2014, 9:03 PM UTC

jonahx wrote: post #107

MichaelGG wrote: post #76

Earlier quoted context omitted.

The main similarity is that Go was called a systems language for some reason, and the idea is now cached in people's minds.

Could you explain what differences make Go optimized for server software and Rust for systems software/C replacement? I'm not being rhetorical -- I genuinely don't understand and would like to. Related: Would Rust be a bad choice for backend web development (ie, an alternative for Ruby/Python) and why or why not?

The mandatory garbage collection by default in Go would be a good example of a trade-off they make differently.

A rust programmer must be aware of the complexity of memory management. Although they are not forced to use all of it it, the standard library does expose enough of it, to force every rust programmer to be comfortable with the complexity of it.

In return they get the opportunity to write code that can compete with c/c++ in terms of performance, and control over latency, while still retaining safety.

>Would Rust be a bad choice for backend web development (ie, an alternative for Ruby/Python) and why or why not?

Depends on how much you care about maturity and what timescale the code has to run in production.

Rust code will be much faster than equivalent Ruby/Python code, but the memory management of it, will be more complicated. I would argue Go offers a better trade-off in performance, complexity and maturity for those types of projects, even though Rust is a much more interesting language.

So, if you can afford to not micro optimize your allocation strategies and just use a garbage collector, i would always choose to do so. Even with a language design as pretty as that of Rust.