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

Racket v9.0

blog.racket-lang.org

Post reply on HN
Print view View original

71–80 of 129 posts

Re: Racket v9.0

#71

Post by gus_massa »

brabel wrote: post #68
wduquette wrote: post #30

I first experimented with Lisp back in the mid-80’s, and have returned to it time and again—not as a language for serious projects, but just as a way of learning new techniques and new ways to think about writing software. I’ve tried using Racket on a number of occasions going back to way before it was called that, and something about the software just puts me off. Perhaps I could get past that if I stuck with it, bu…

I liked it many years ago but when I noticed how slow and heavy my code was I left it. It manages to be slower than Python. Perhaps the Chez Scheme rewrite helped with that but now if I need a Lisp I have Common Lisp which is super fast and lightweight enough.

It's usually faster than Python for numeric stuff, and has a similar speed for strings. See for example https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

But if you run the code inside the default IDE call DrRacket, you must go to the menu Language>Choose_Language... then click "Show_Details" and disable "Debugging".

With debugging enabled, you get nicer error messages, but it blocks a lot of optimizations and the program get slow.

Re: Racket v9.0

#72

Post by gus_massa »

gus_massa wrote: post #49
hatmatrix wrote: post #27

Earlier quoted context omitted.

What are some difference between the education tooling around Racket and that which enables "industrial" applications Common Lisp is known for?

I think SBCL has better support for annotations. You can claim that a variable is an int and the compiler will thrust you and generante fast code. You can use Typed Racket to add annotations. The compiler will verify your that your claims are consistent and perhaps add some runtime checks when you read data or use other external sources. It will remove most of the internal checks, but not all of them. (Probably some…

Too late to edit:

> impersonators make generating fast code faster

should be

> impersonators make generating fast code harder

Re: Racket v9.0

#73

Post by gus_massa »

shakna wrote: post #60
ModernMech wrote: post #57

Earlier quoted context omitted.

Maybe I just have a different working definition of these words. To me "mature" means "fully developed" and "polished" means "achieved a high level of refinement". To me, rewriting it all to introduce a major feature that fills in a longstanding hole in the language doesn't say "mature and polished". Because often times many bugs are introduced into a codebase on a major rewrite despite extensive test suites, especia…

The rewrite started in 2017. Fears about refactoring introducing bugs are fine and valid - but after eight years, haven't really happened. Seems the extensive test suite did its job. This isn't a case of Python 2 v 3. Packages weren't broken en masse. The API remained stable. If anything, the rewrite has proved that it is mature. Because they could perform a refactor without breaking everyone's everyday.

I agree. I remember very few bugs caused by the rewrite, but I don't remember recent ones.

For example, I found a bug running the tests of the r7rs package, it was simplified to a bug in "plain" Racket and later fixed, 3 days after the initial report. It was in June 2019 https://github.com/racket/racket/issues/2675 Note that at that time, the default version of Racket was he old one (before the rewrite).

Re: Racket v9.0

#74

Post by dinkleberg »

mono442 wrote: post #48

Speaking of lisp, if I wanted to use a lisp nowadays, what would be the best choice, common lisp, clojure or some scheme implementation?

I’ve been playing around with Janet for scripting use cases and it’s pretty cool.

Re: Racket v9.0

#76

Post by chamomeal »

yonki wrote: post #59
mono442 wrote: post #48

Speaking of lisp, if I wanted to use a lisp nowadays, what would be the best choice, common lisp, clojure or some scheme implementation?

Clojure is widely used, opinionated, promotes immutability, has lots of libraries and lively community. It is overall great language, really nicely designed, 100% worth using. If you want the best performance and need to build executables without JVM then SBCL is a better choice, although probably takes longer to learn. I wrote my fair share of Clojure, SBCL just had a look at.

Although if your executables are script-like, you can use babashka, which lets you write shell scripts in clojure. Good stdlib, full macro support, shell out to other commands, just a great tool.

I love babashka. I could never convince my company to use clojure for a big project, so now I’m exposing all of my coworkers to clojure by making a set of nice specific-to-our-company utilities in babashka.

Re: Racket v9.0

#77

Post by shawn_w »

dleary wrote: post #16
Zambyte wrote: post #10

Earlier quoted context omitted.

Agree? Or maybe none of them graduate into a role where they get to decide what language to use?

Everyone gets to choose which language they use for their personal projects. Where are all the Racket personal projects? N.B. I say this as someone who personally contributed small fixes to Racket in the 90s (when it was called mzscheme) and 00s (when it was called PLT-Scheme).

Racket is my first choice for most code I write these days and I've published a fair number of libraries into the raco package manager ecosystem in hopes other people using Racket might find them useful too.

Re: Racket v9.0

#78

Post by vindarel »

gabrielsroka wrote: post #4
webdevver wrote: post #2

i only know about racket because Carmack was doing Oculus stuff with it once 10 years ago: https://youtu.be/ydyztGZnbNs?t=412

HN is written in Arc, and Arc is (was?) written in Racket. https://en.wikipedia.org/wiki/Arc_(programming_language)

Arc was re-written to Common Lisp (SBCL) around last year, for performance reasons.

> [Clarc] is much faster and also will easily let HN run on multiple cores. It’s been in the works for years, mainly because I rarely find time to work on it, but it’s all pretty close to done.

> there’s now an Arc-to-JS called Lilt, and an Arc-to-Common Lisp called Clarc. […]

> open-sourcing the Arc implementation (i.e. Clarc) would be much easier [than the HN site]. [Because…]

more and sources of Dang quotes: https://lisp-journey.gitlab.io/blog/hacker-news-now-runs-on-...

Re: Racket v9.0

#79

Post by jetti »

kryptiskt wrote: post #26

The big news here is that Racket now can run threads in parallel. While there were ways to get parallelism before (like places), this is much more lightweight and familiar. Anything that expands the areas where Racket is viable is good news to me since I like writing stuff in Racket.

What kinds of things do you write in Racket? I’m a clojure dev and so I’m a big fan of lisp. I’m just curious what kinds of projects you would use Racket for

Re: Racket v9.0

#80

Post by zelphirkalt »

kryptiskt wrote: post #26

The big news here is that Racket now can run threads in parallel. While there were ways to get parallelism before (like places), this is much more lightweight and familiar. Anything that expands the areas where Racket is viable is good news to me since I like writing stuff in Racket.

While reading the release notes, I was also surprised, that they finally have this kind of multi-threading. I knew about places, but they were kind of inflexible, as you couldn't easily send a lambda in Racket, and serializable-lambda was infectious, so one ended up having to pre-define all logic and at runtime only sending data not functions to other places, which was a shame. One could not really build a thing that distributes work via multiple places with that. Or at least no one managed to do that and no one could tell me how to do it. I hope that with the new concurrency stuff this is now possible, even if it may not be as conceptually clean as places were supposed to be.

Ultimately, multi-threading is one reason, why I mostly used GNU Guile, instead of Racket in recent years. Guile's story of using multiple cores is much more solid, using its futures and possibly fibers via a library. I have used futures, which are backed by a pool of threads underneath, to implement a toy parallelized decision tree algorithm/model, that had linear (or close to) speedup.

Post reply on HN