Hacker Newsnew | comments | show | ask | jobs | submit | samth's comments login

The last time I counted, I think there were more packages between PLaneT and pkgs.racket-lang.org than Chicken eggs. Also, Chicken relies on eggs to provide a lot of things that the Racket standard library contains.

-----


Fair enough. I'd not done the comparison myself, I use Racket myself.

-----


Actually, lifetimes are basically the same as regions, going back to FX87. Lifetimes in Rust are more like regions in Tofte & Talpin 94 than those in FX87, but where inter-region pointers are constrained by the lifetime of regions rather than changing the lifetimes of the regions (as required by Rust's goals for regions).

-----


Rust's goals for linear typing and regions changed. Ownership types didn't happen until typestate was abandoned. The current design is quite different from what was being explored before. If they're happy with what they've got, more power to them, but the project's priorities have changed dramatically in the last 2 years. I think it's worth asking why something that started seemingly as a research language backed off the original work and was converted into a relatively safe technology product in a short span of time.

I find it profoundly disquieting when redactions are created around the history of projects, pushing the impression that the place arrived at was what was wanted all along. Our failures can inform posterity as much as our successes.[1] The core Rust team has been perfectly candid about the history of the project.

[1]: Cf. pre-Monad IO subsystems for Haskell, http://www.scs.stanford.edu/~dbg/readings/haskell-history.pd... and http://research.microsoft.com/en-us/um/people/simonpj/papers...

-----


I didn't claim (and neither did kibwen, who unlike me is a major Rust contributor) that Rust's approaches around memory management didn't change. But your claim that "Lifetimes aren't regions" is false -- lifetimes are squarely in the 30-year research history of region systems.

-----


A region calculus[1], such as Tofte described, is not what I see in Rust as it exists today. It could've been so with typestate, if I understood the intent behind typestate correctly.

If what Rust has is understood to be regions, then I need a couple of words for distinguishing the two. Ordinarily, I refer to what Rust/C++ have as "ownership types" and what exists in research as regions/RBMM/RC.

[1]: http://www.researchgate.net/profile/Simon_Helsen/publication... (the defintion provided here is what I understand "regions" to mean, as contrasted with what exists in C++ and Rust)

-----


As someone not terribly familiar with the literature but familiar with Rust's type system, I just spend a few minutes googling various pages about region based memory management (including Tofte + Talpin) as well as skimming your link (not very hard, I admit), and I don't really understand what it lets you do (that doesn't exist in a roughly analogous form in Rust). Well, there's the fact that most of the papers describe region inference, while Rust is fully explicit, but that doesn't seem critical to the scheme to me. Out of curiosity, I'd be interested to see you elaborate on the difference.

Also, I do not know what other 'PLs with similar facilities' exist with anywhere near as much effort put into them (other than Cyclone, which is dead). You mentioned C++, but it doesn't have lifetime checking at all, which is of course a core feature of Rust...

-----


C++ doesn't cover the full extent of safety Rust offers at all, but there is a fair bit of overlap in how the functionality is packaged up WRT ownership types.

I checked the docs and it looks like at least http://doc.rust-lang.org/0.12.0/guide-lifetimes.html#named-l... is covered which was one of my objections. I still don't like that I can't design my own linearly typed constraints, but it appears that was never a goal to begin with. Not surprising given the lack of emphasis on expressive types.

As it stands my only options for linear'ish types are indexed Monads in Haskell or building a model of linear types in a proof assistant or DTPL.

-----


I and some others are working on a rough approximation to linear types here: https://github.com/Manishearth/humpty_dumpty

A perfect implementation can be added to the language, but getting it to work perfectly with backcompat is hard so it might be made in 2.0.

-----


Actually, sweet.js is based almost entirely on various macro innovations developed in Racket (such as the Honu approach to macros in languages without parens).

-----


I think you're assuming that a language built that way would have to adopt Racket's underlying meanings for things, probably because Arc is, in the grand scheme of things, pretty close to Racket. But because Arc makes some fairly fundamental decisions that are different than Racket (such as how macros work), you can't keep those the same -- Arc macros can't be just Racket macros.

However, just because Arc can't be a layer of macros on top of Racket, that doesn't mean that the language can't be implemented as a Racket language. There are Racket language implementations of Algol 60, Python, and JavaScript, all of which are very different from Racket, more so than Arc is. And those implementations get the tooling benefits that Arc today misses.

It's easier to write a simple interpreter than a compiler, and Arc's current implementation seems to be working well for you, so far be it from me to tell you how to run your project. But certainly it could be implemented as a Racket language, no matter how far away it is.

-----


Typesafe (from their web site) sells a packaged version of their "stack" (similar to RHEL), plus support, plus what looks like a proprietary management tool (ConductR, which I think is pretty new). Also training and consulting.

-----


Typed Racket operates on a per-module basis -- only some of your program has to be typed. But it's entirely static -- errors are caught at compile time.

-----


No, it's a statement that the developers of Racket care about explaining how things work.

-----


Perhaps because they need to? Or do you find Racket as clear as other languages? Even other Lispy ones?

Without trying to be insulting, I find Racket aesthetically unappealing.

-----


The cool thing is that if you had asked me a week ago, I would have said return-type polymorphism like this was impossible without types.

-----


While indeed we are doing a major refactoring of the repository, the split into many packages has already happened. And you can download the Minimal Racket installer today!

-----


No, this was a seminar at EPFL and wasn't recorded.

-----


Dammit! :(

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: