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

191–200 of 201 posts

Re: 2017 Rust Roadmap

#191

Post by pjmlp »

berntb wrote: post #187
pjmlp wrote: post #186

Earlier quoted context omitted.

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?

No, I am saying that if UNIX was available at the same price as the other OS of the time, it would never have been as successful as it was.

In general, UNIX is a poor replacement for any of the OSes designed at Xerox PARC, they did at least three remarkable ones.

Or at ETHZ for that matter.

Re: 2017 Rust Roadmap

#192

Post by steveklabnik »

Too wrote: post #174
tatterdemalion wrote: post #84

Earlier quoted context omitted.

Not in Rust's type system. In a pure language, you could have some sort of "Heap" monad similar to the "IO" type in Haskell.

So Rust has no way to mark side effects and global dependencies of functions? Allowing singletons in a language that is supposed to be safe sounds like a huge design flaw.

Mutable statics are unsafe to access or update. You can use interior mutability with something like a Mutex to get a mutable-but-not-to-rustc value, which is safe.

Systems programming languages need this kind of functionality.

Re: 2017 Rust Roadmap

#193

Post by berntb »

pjmlp wrote: post #191
berntb wrote: post #187

Earlier quoted context omitted.

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?

No, I am saying that if UNIX was available at the same price as the other OS of the time, it would never have been as successful as it was. In general, UNIX is a poor replacement for any of the OSes designed at Xerox PARC, they did at least three remarkable ones. Or at ETHZ for that matter.

Uhm, I still don't get why the development (/execution) environment would have been different for Lisp?

I am aware of that Unix/Linux is/was quite a simple solution. It is designed to be. It was still (more or less) the basis for Next and the present MacOS. Quite nice.

(Disclaimer: Today I really only use Linux computers, for apt and compatibility with servers. No MacOS flames, please. :-) )

Re: 2017 Rust Roadmap

#194

Post by berntb »

hinkley wrote: post #188
tatterdemalion wrote: post #105

Earlier quoted context omitted.

> (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.…

Good point about tests and dynamic data structures. Thanks.

Re: 2017 Rust Roadmap

#195

Post by Too »

steveklabnik wrote: post #192
Too wrote: post #174

Earlier quoted context omitted.

So Rust has no way to mark side effects and global dependencies of functions? Allowing singletons in a language that is supposed to be safe sounds like a huge design flaw.

Mutable statics are unsafe to access or update. You can use interior mutability with something like a Mutex to get a mutable-but-not-to-rustc value, which is safe. Systems programming languages need this kind of functionality.

Putting a mutex around a global variable doesn't change the fact that it is still a global variable.

Memory access might be safe but you get spaghetti code and combinatorial state explosion due to all the potential side effects.

Allowing singletons for edge cases is fine but with no proper way to enforce it except code review you really have now idea what the underlying code might potentially do.

Re: 2017 Rust Roadmap

#196

Post by steveklabnik »

Too wrote: post #195
steveklabnik wrote: post #192

Earlier quoted context omitted.

Mutable statics are unsafe to access or update. You can use interior mutability with something like a Mutex to get a mutable-but-not-to-rustc value, which is safe. Systems programming languages need this kind of functionality.

Putting a mutex around a global variable doesn't change the fact that it is still a global variable. Memory access might be safe but you get spaghetti code and combinatorial state explosion due to all the potential side effects. Allowing singletons for edge cases is fine but with no proper way to enforce it except code review you really have now idea what the underlying code might potentially do.

I agree with you that using globals as sparingly as possible is good, but your original claim was about safety, so that's what I focused on.

Re: 2017 Rust Roadmap

#197

Post by pjmlp »

berntb wrote: post #193
pjmlp wrote: post #191

Earlier quoted context omitted.

No, I am saying that if UNIX was available at the same price as the other OS of the time, it would never have been as successful as it was. In general, UNIX is a poor replacement for any of the OSes designed at Xerox PARC, they did at least three remarkable ones. Or at ETHZ for that matter.

Uhm, I still don't get why the development (/execution) environment would have been different for Lisp? I am aware of that Unix/Linux is/was quite a simple solution. It is designed to be. It was still (more or less) the basis for Next and the present MacOS. Quite nice. (Disclaimer: Today I really only use Linux computers, for apt and compatibility with servers. No MacOS flames, please. :-) )

> Uhm, I still don't get why the development (/execution) environment would have been different for Lisp?

I still don't get why you keep focusing this discussion on Lisp alone, I explicitly referred to several OSes.

All of them more expensive to buy than UNIX, which was available for peanuts.

As for OS X.

UNIX was the base for NeXTSTEP, because NeXT was after the workstation market owned by Sun and SGI workstations.

But anyone that has bothered to learn the NeXTSTEP stack and respective APIs, knows how little UNIX culture it had, beyond "bring your stuff to our platform".

The hybrid Mach/BSD kernel, device drivers written in Objective-C and the whole user space frameworks and GUI workflows.

Mac OS X follows that tradition as any developer committed to OS X technology stack knows.

Drivers are written in a C++ subset, we have the frameworks, automation via Apple Script, Objective-C and now Swift for GUI applications.

Re: 2017 Rust Roadmap

#198

Post by hinkley »

leshow wrote: post #183
berntb wrote: post #75

Earlier quoted context omitted.

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. How…

There's a substantial discount in many developers heads about the ongoing maintenance costs of their code. To them the up front costs are the only thing that matters.

If you're not spending significant time on rework it means your coworkers are doing it for you.

As version control has gotten better it's harder to hide who is to blame but most people still don't bother to look. Which means you get no feedback about how good your code is.

Re: 2017 Rust Roadmap

#199

Post by lispm »

pjmlp wrote: post #181
lispm wrote: post #180

Earlier quoted context omitted.

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 settl…

cheap, but not 'free'.

See also the later fate of UNIX (-> Novell, ...).

Re: 2017 Rust Roadmap

#200

Post by Can_Not »

collinmanderson wrote: post #156
dikaiosune wrote: post #2

It's important to note that this is an RFC which has been proposed, and there's likely to be a good deal of discussion and revision before it's merged/adopted as the official 2017 roadmap. The conversation can be followed/joined/whatever here: https://github.com/rust-lang/rfcs/pull/1774

"accordance with RFC 1728" - could they have chosen a naming scheme so their documents are not confused with the _real_ RFC's? Even RRFC 1728 would helpful. Or maybe just #1728?

Why do "the _real_ RFC's" have exclusive rights to that term?
Post reply on HN