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

Racket-on-Chez Status

blog.racket-lang.org

Post reply on HN
Print view View original

21–30 of 53 posts

Re: Racket-on-Chez Status

#21

Post by bjoli »

logicchains wrote: post #13
bjoli wrote: post #9

Earlier quoted context omitted.

Iirc Idris2 went straight to running on chez since Edwin was so impressed by chez scheme and it's runtime.

The result is super fast: if you use if after using Idris1 you'll be blown away by how much quicker it type-checks. I'd never have thought a Scheme could perform noticeably faster than Haskell, but maybe most of the improvements are just due to algorithmic improvements made during the rewrite.

I never played with Idris2, but I recall running some idris1 programs using the chez scheme backend instead of thebc one and got instant 5x speedups. Across the board.

Not that it wouldn't be possible to make the C code fast. It is just that the chez backend was a one man job.

Re: Racket-on-Chez Status

#22

Post by kryptiskt »

bjoli wrote: post #21
logicchains wrote: post #13

Earlier quoted context omitted.

The result is super fast: if you use if after using Idris1 you'll be blown away by how much quicker it type-checks. I'd never have thought a Scheme could perform noticeably faster than Haskell, but maybe most of the improvements are just due to algorithmic improvements made during the rewrite.

I never played with Idris2, but I recall running some idris1 programs using the chez scheme backend instead of thebc one and got instant 5x speedups. Across the board. Not that it wouldn't be possible to make the C code fast. It is just that the chez backend was a one man job.

Thank the Chez Scheme developers for an absolutely fantastic compiler, and also Idris for being designed so that it's possible to feed any of the IRs to the particular backend. There's not much of an impedance mismatch between Scheme and Idris lambda output, so the overhead is small. I could have made it a bit better if I had represented Idris lists and bools as the corresponding scheme types, instead of being mapped as all the other types by their structure.

Re: Racket-on-Chez Status

#24

Post by kamaal »

dTal wrote: post #18
kamaal wrote: post #15

Earlier quoted context omitted.

Because you are not exactly running Rhombus as a side toy language, but as a successor to Racket. This requires Rhombus to eventually replace Racket. Anything less than this and it makes Rhombus a non-successor to Racket. While at the same time much needed resources to make Racket win, will go to making Rhombus happen. Even if Rhombus comes along, it won't have any of the current Racket goodness to begin with. Rhombu…

Racket is not like other languages. Racket is a language with first class support for building languages on top of it. And so no, Rhombus does not need to be a "successor" to Racket. It does not need to "replace" Racket. It will have all the current Racket goodness to begin with, because all of its semantics will come from Racket - they will be the same language. Nor will it steal valuable developer attention - a bug…

Well PyonR is not a replacement for Racket. It's something totally a different project altogether. Rhombus is supposed to replace Racket. We could have PerlRacket or AwkRacket or RubyRacket and none of it should effect Racket, because you are using Racket as a language to build things, not exactly using RubyRacket as a replacement for Racket.

This is how it rings to my ear. Racket as is, is in some way frozen when it comes to features and big changes. Rhombus is where the next set of awesomeness will happen. Lispers who happen to be core users of Racket have no use at the time for non-existent Rhombus, and its not Lispy so their whole use case ends here. Racket won't be continued to developed in the same breath as Rhombus, so Racket is also dead here. C based language devs have a lot of good stuff already, so they don't need Rhombus either.

Eventually this could lead to the exact situation Perl was in the 2000s. The core development was frozen for 5+ years. The language usability just fell year over year. Perl 6 took forever to even start with the implementations. Pugs, then Neitza, then Rakudo. Eventually they came to a point, where they announced Perl 5 development would just run parallel as a separate project compared to Perl 6. By then a lot of dev mind share was lost to Python/Java. Now neither Perl 5 nor Perl 6 have significant mind share. Perl 5 certainly has lost a lot of its users.

Also in general trying to be everything to everybody is a bad idea in general. Ask Parrot VM people. It doesn't work the way you expect. You won't solve anyone's specific problem, and it takes forever to get done.

Re: Racket-on-Chez Status

#25

Post by zeveb »

kamaal wrote: post #10
kamaal wrote: post #8

Earlier quoted context omitted.

So will the current Racket language continue to be developed, as in new features, bug fixes and regular releases after Rhombus is released? Renaming doesn't help the case much here, if Racket's future is abandonware.

A bit of Googling landed me here: https://groups.google.com/forum/#!msg/racket-users/-x_M5wIht... From there: Phase 1: Brainstorming (months) Phase 2: Iterative Design (years) Phase 3: Conversion (months or years) Phase 4: Transition (years) I am a nobody in front of people like Matthew Flatt, but this feels like Seconds Systems Effect taken to its extreme definition: https://en.wikipedia.org/wiki/Second-system_effec…

> a top successor for Common Lisp

I know that some well-known Lisp hackers left for Racket, but I've never been clear on how it is really a successor. It does have a great community and ecosystem, but it inherits a ton of the mistakes of Scheme, is unspecified and as such is susceptible to derailments like Rhombus. I think that performance is not that great either, which isn't necessarily a huge deal for many problems but is for some.

What I am genuinely curious about is: from your point of view, what makes Racket a preferable successor to Lisp (which can't easily be grafted into a Lisp environment)? The two things which leap to my mind are the sane read case and the community mindset.

Re: Racket-on-Chez Status

#28

Post by wtetzner »

kamaal wrote: post #24
dTal wrote: post #18

Earlier quoted context omitted.

Racket is not like other languages. Racket is a language with first class support for building languages on top of it. And so no, Rhombus does not need to be a "successor" to Racket. It does not need to "replace" Racket. It will have all the current Racket goodness to begin with, because all of its semantics will come from Racket - they will be the same language. Nor will it steal valuable developer attention - a bug…

Well PyonR is not a replacement for Racket. It's something totally a different project altogether. Rhombus is supposed to replace Racket. We could have PerlRacket or AwkRacket or RubyRacket and none of it should effect Racket, because you are using Racket as a language to build things, not exactly using RubyRacket as a replacement for Racket. This is how it rings to my ear. Racket as is, is in some way frozen when it…

> This is how it rings to my ear. Racket as is, is in some way frozen when it comes to features and big changes. Rhombus is where the next set of awesomeness will happen.

You still seem to be misunderstanding how Racket and #lang's work. Rhombus and Racket will be the same language, but with different parsers. Big features of Rhombus will be added by adding those features to Racket.

Languages in Racket are not developed independently of each other, they all share the underlying language machinery.

Re: Racket-on-Chez Status

#29

Post by wtetzner »

logicchains wrote: post #20
dTal wrote: post #18

Earlier quoted context omitted.

Racket is not like other languages. Racket is a language with first class support for building languages on top of it. And so no, Rhombus does not need to be a "successor" to Racket. It does not need to "replace" Racket. It will have all the current Racket goodness to begin with, because all of its semantics will come from Racket - they will be the same language. Nor will it steal valuable developer attention - a bug…

Would you say Rhombus is to Racket as ReasonML ( https://reasonml.github.io/ ) is to OCaml?

I think it's a reasonable analogy, but I would say ReasonML is actually more than Rhombus in a sense. Rhombus doesn't require any external tooling, because Racket has support for implementing #lang's built in to it.

Re: Racket-on-Chez Status

#30

Post by lispm »

zeveb wrote: post #25
kamaal wrote: post #10

Earlier quoted context omitted.

A bit of Googling landed me here: https://groups.google.com/forum/#!msg/racket-users/-x_M5wIht... From there: Phase 1: Brainstorming (months) Phase 2: Iterative Design (years) Phase 3: Conversion (months or years) Phase 4: Transition (years) I am a nobody in front of people like Matthew Flatt, but this feels like Seconds Systems Effect taken to its extreme definition: https://en.wikipedia.org/wiki/Second-system_effec…

> a top successor for Common Lisp I know that some well-known Lisp hackers left for Racket, but I've never been clear on how it is really a successor. It does have a great community and ecosystem, but it inherits a ton of the mistakes of Scheme, is unspecified and as such is susceptible to derailments like Rhombus. I think that performance is not that great either, which isn't necessarily a huge deal for many problem…

I also think that language oriented programming like in Racket is overrated. As a Lisp programmer I'm happy to have different paradigms integrated into one language, and not have them added as 'languages'. For some amount of languages it makes sense, but generally it's more like an academic exercise and makes the whole machinery more complicated - which for many use cases is not needed. Working on a hosted platform with deep integration into the host language environment was during the last years preferred by a lot more users - that's more compatible and reusable (since more reusable libraries work).
Post reply on HN