Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

2017 Rust Roadmap

github.com

Post reply on HN
Print view View original

181–190 of 201 posts

Re: 2017 Rust Roadmap

#181

Post by pjmlp »

lispm wrote: post #180
pjmlp wrote: post #177

Earlier quoted context omitted.

A thing called UNIX where the source code was available for free happened, but lets forget that fact. GC bashers would be surprised how much their lifes actually depends on embedded systems running real time Java deployments.

It thought UNIX originally belonged to AT&T and they sold licenses. See the UNIX history.

They were prevented to sell them in the beginning, which was when some of the AT&T guys brought the code into universities like Berkeley and Stanford.

EDIT: Well, they actually did sold licenses, but I guess $99 even in 70's was quite cheap vs what the alternatives were asking for

http://engineering2.berkeley.edu/labnotes/history_unix.html

"This led to requests for the system, but under a 1956 consent decree in settlement of an antitrust case, the Bell System (the parent organization of Bell Labs) was forbidden from entering any business other than "common carrier communications services", and was required to license any patents it had upon request.[6] Unix could not, therefore, be turned into a product. Bell Labs instead shipped the system for the cost of media and shipping."

-- Wikipedia

Re: 2017 Rust Roadmap

#182

Post by pjmlp »

berntb wrote: post #179
pjmlp wrote: post #177

Earlier quoted context omitted.

A thing called UNIX where the source code was available for free happened, but lets forget that fact. GC bashers would be surprised how much their lifes actually depends on embedded systems running real time Java deployments.

Huh? There were early Lisps with free source, too. Also, 1, I am not a GC basher. 2. I was wondering why Lisp didn't take over most of the world 15+ years ago. Overhead was more expensive then. (And small embedded systems will always have too little RAM.)

Overhead was more expensive and there was a cheaper alternative called UNIX.

I wonder how ir would have turned out if it wasn't available.

Re: 2017 Rust Roadmap

#183

Post by leshow »

berntb wrote: post #75
leshow wrote: post #52

Awesome. I have used Iron a few times to write small web services, but I can't wait for Rust to really have a strong story for the backend. If that happens it'll be the first language I reach for whenever I need to write a backend. I think it has a lot of great bonuses already. It's language ergonomics are that of a high-level language, yet it is extremely fast, and I can be very confident in my code if it compiles.…

Are you saying that Rust, a system programming language, can compete with the scripting languages in speed of developing features?! Or are you saying that it is a pleasure to use, so you'll use it for smaller backends where development speed isn't that critical? (Asking, not flaming. :-) )

Absolutely. But the trade-off is not so simple. I can be fairly confident that if my code compiles there are far fewer bugs than if I had written it in nodejs or php. So while it may take longer to get to the initial point that I have something running, I save time on subsequent refactors.

And the added bonus, is that my code runs 10-20x faster. So I really didn't give up anything to get the increased confidence.

However, I have to backtrack a bit here, because the largest Rust backend I've written was probably a little less than 10k lines. So while it was non-trivial it wasn't a massive undertaking.

Re: 2017 Rust Roadmap

#184

Post by leshow »

berntb wrote: post #169
pjmlp wrote: post #110

Earlier quoted context omitted.

It is possible to have both capabilities in a programming la language.

I note the long list of obvious examples...? :-) But sure, the world would be a better place if Rust, Go and/or Swift could fulfill that niche. I really don't know enough. (Go seems a bit boring. Rust is too new. Swift is a bit limited re Linux etc support.) (I've seen the claim that some C++ gurus could develop features as quick as seasoned scripters, but... how many years did it take to get to that state? :-( ) (So…

Go doesn't have any of the same safety guarantees as Rust. If you look at most production Go code, very few make use of channels, most Go code is actually locking/unlocking memory, and the Go compiler doesn't validate against data races in the same way that Rust code would. So I don't believe that Go actually makes things better, in that respect anyway.

Re: 2017 Rust Roadmap

#185

Post by berntb »

pjmlp wrote: post #182
berntb wrote: post #179

Earlier quoted context omitted.

Huh? There were early Lisps with free source, too. Also, 1, I am not a GC basher. 2. I was wondering why Lisp didn't take over most of the world 15+ years ago. Overhead was more expensive then. (And small embedded systems will always have too little RAM.)

Overhead was more expensive and there was a cheaper alternative called UNIX. I wonder how ir would have turned out if it wasn't available.

Uh... did I miss something? You don't need a lisp machine or a PDP-10 to run a lisp variant?

(Do you argue that it was too late when sh had scripting? The sh is gone now, bash will probably be replaced too.)

Re: 2017 Rust Roadmap

#186

Post by pjmlp »

berntb wrote: post #185
pjmlp wrote: post #182

Earlier quoted context omitted.

Overhead was more expensive and there was a cheaper alternative called UNIX. I wonder how ir would have turned out if it wasn't available.

Uh... did I miss something? You don't need a lisp machine or a PDP-10 to run a lisp variant? (Do you argue that it was too late when sh had scripting? The sh is gone now, bash will probably be replaced too.)

Scripting via the UNIX shell is a poor man's REPL.

Personally I don't remember the last time I used it for anything other than setting environment variables, for anything else there are better actual programming languages.

Re: 2017 Rust Roadmap

#187

Post by berntb »

pjmlp wrote: post #186
berntb wrote: post #185

Earlier quoted context omitted.

Uh... did I miss something? You don't need a lisp machine or a PDP-10 to run a lisp variant? (Do you argue that it was too late when sh had scripting? The sh is gone now, bash will probably be replaced too.)

Scripting via the UNIX shell is a poor man's REPL. Personally I don't remember the last time I used it for anything other than setting environment variables, for anything else there are better actual programming languages.

I never argued anything positive about shell programming. Ever. :-)

I still don't get your point, but assume you are saying that Unix is a poor replacement for a real lisp machine environment?

Re: 2017 Rust Roadmap

#188

Post by hinkley »

tatterdemalion wrote: post #105
berntb wrote: post #100

Earlier quoted context omitted.

Bold. :-) I do hope you're correct. (Given a modest test suite and checking parameters at external API interfaces, scripting languages didn't have much problems with bugs that could be found at compile time, imho.)

> (Given a modest test suite and checking parameters at external API interfaces, scripting languages didn't have much problems with bugs that could be found at compile time, imho.) Not my experience at all .

I've given JavaScript about six years to prove that tests make up for static analysis and all I've learned is that we need MORE static analysis.

I've met about four people in a dozen years that write better tests than me, and pretty much everyone else is writing garbage. And when I look back at my own I'm never satisfied.

Essentially the only thing worse than no tests is thinking you have test safety when you don't.

Particularly, negative tests in a dynamic language are easy to write but are virtually guaranteed to break at a later date without anyone noticing, because you are now looking in the wrong spot for a piece of data.

Re: 2017 Rust Roadmap

#189

Post by steveklabnik »

tmzt wrote: post #172
steveklabnik wrote: post #116

Earlier quoted context omitted.

This is an area in which I haven't quite figured out how to communicate properly; I feel like I have a good understanding of how Rust maps to asm, but I don't know how to transfer that understanding to other people. I'll certainly be reading your link below, thanks for that!

Would an updated and expanded Rust for C++ Programmers make sense as a companion to the book with references to concepts in the book along with low-level details on data structures or implementation? It would nice to see that and Nomicon more closely related and fully up-to-date. It soulds like an informal "specification" of #[repr(c)] or #[repr(packed)] for common platforms would also be useful for FFI.

Yeah it'd be great to have.

Re: 2017 Rust Roadmap

#190

Post by steveklabnik »

pjmlp wrote: post #163
steveklabnik wrote: post #114

Earlier quoted context omitted.

https://github.com/rust-lang/cargo/issues/396

Thanks for point it out, it just isn't clear what the current state is. It looks kind of dropped with the github repository only having a basic example.

Yeah. Nobody has championed it as of yet. That's open source :)
Post reply on HN