To be clear, I have never had a problem with Racket's performance, I'm just thinking about ways to push for a wider adoption. Personally, anything faster than Python is more than enough, especially with a good FFI. I'm guessing a lot of people look at Rust and Go just because it's supposed to be faster (than Java) and safer (than C). I strongly believe performance depends on who's in front of the keyboard, not which compiler one uses.
Dex On Wed, Apr 29, 2020 at 4:26 PM Dominik Pantůček < dominik.pantu...@trustica.cz> wrote: > Hi, > > I can't leave this without reaction... > > > > > To the point: what would make Racket2 the ultimate tool (for me): > > > > * Performance. Faster startup times, shorter execution times in > > general. Optionally, a ‘lite’ version of Racket that compiles > > directly to no-deps binaries, bypassing the JIT altogether, would be > > a game-changer. As far as high levels languages with functional > > concepts and metaprogramming facilities that compiles to tiny, fast > > bins, Nim comes dangerously close, but it’s not a Lisp, and it’s not > > Racket. > > They say that Racket is slow. I would like to know who are "they". > > Racket can be surprising. For example - our GUI application on RPi has a > start-up time of 24s... But when we compile it using `raco exe`, it goes > down under 2s including some hardware setup the program does. Usually > the slow startup times are caused by not using compiled byte-code. > > As I have mentioned a few times on this list, I am working on a side > project right now which pushes Racket to its limits and let's say that > the results might look impossible to many people. Full 3D rendering > pipeline in pure Racket with no external libraries (no OpenGL, no SDL, > just pure Racket) which can run at 60fps FullHD kind of beats the > argument "Racket is slow". Racket can be REALLY fast. But you need to > know how to achieve that (think contract boundaries, unsafe ops guarded > by other mechanisms, ultimate parallelism support - yes, once you grasp > futures to their full extent, you will see what performance gains you > get virtually for free... see my sorting package[1]) > > > * Production-quality, modern and fast GUI facilities. I’ll take > > properly documented, complete Qt bindings. Racket/GUI is great for > > internal tools, but it quickly becomes slow, tedious and limited for > > more complex client-facing UIs. > > My experience is quite contrary to that. In the last three years we were > forced to develop a few GUI tools used by our customers and there are no > complains only against the tools using racket/gui. Yes, it is far from > perfect - but it is the only thing that really behaves consistently > across all three platforms we need to support (Linux, Mac, and ... > Windows). Python+Qt and go+Qt are absolutely insupportable without a > long list of per-platform/per-widget hacks. It might be that we are just > hitting corner cases (actually that's pretty probably), yet with Racket > there were no such hurdles. > > > * One complete, commercial-grade Web framework, inspired from Symphony > > or Laravel. Security and ease of use first, continuations later. > > And this is the part that made me actually hit the "Reply List" button. > The good thing about mentioned PHP frameworks is only that anyone can > start producing something with them without any prior experience. So > right now we are encountering vulnerable and unmaintainable code > anywhere we bump into some 3rd party "web application" we are hired to > audit. With Racket - the entry barrier is really high, I agree. I > actually spent many days getting through it - but once you pass the > barrier, it really helps you write applications where you can focus on > the actual functionality and let the libraries do the rest for you. And > securing such application is almost trivial task. Yes, I have hit some > corner cases here as well, but if you follow for example Bogdan's > work[2][3], you'll see that there are solutions readily available. It is > just necessary to read the docs and understand how the whole thing works. > > > * Better documentation: Racket docs are aesthetically very pleasing, > > complete and detailed. However some parts are still very obscure and > > lacking simple examples (if only the part about Continuations > > included just one basic example, such as a ‘return’ implementation, > > on the very first page. If only the Macros documentation started > > with define-simple-macro and a few very basic, practical examples. > > Instead we’re greeted with pattern-based macros, which although very > > powerful, are very hard to comprehend for newcomers). > > I am not sure whether it is the best thing to start with > define-simple-macro (if anything, I'd start with define-syntax-rule), > but yes, more examples are always useful. Just write them and send a > pull request to appropriate repository - I was pleasantly surprised when > I first did this. All the Racketeers are super helpful when it comes to > incorporating any improvements. (Thanks Ben!) > > > > > > > I am well aware that what I’m wishing for isn’t necessarily compatible > > with Racket’s intended public’s needs (comp-sci teachers and students? > > That’s the impression I’m getting). But Racket is the most advanced > > general purpose programming tool I’ve ever seen. Wouldn’t it be a shame > > if it was limited to academic use? > > As far as I can tell, it is definitely limited to academic use. Although > I prepare support materials for my students with Racket, I actually > teach Clojure - so for me, Racket is tool mostly for my business and > only remotely for my academic activities. But I guess that I am a corner > case here :) > > > > > > > Racket’s home page starts with ‘Racket - Solve Problems - Make > > Languages’. That very first line will scare anybody looking to just... > > write programs. Yes it is the entire point, but why not try and go back > > to basics with Racket2, and (also) tackle what really matters? Easily > > writing correct, fast and powerful programs that let us build tomorrow’s > > technologies. > > You would be surprised, why so many people in the industry use Perl. > They use it for producing what is effectively a pile of DSLs. And they > are really keen on trying to do the same with Racket once they find out > they can. I really think that it the perception that making languages is > something hard is biased. If you go to a carpenters workshop, you > probably won't understand much of what they say, even though you are > talking the same language. Then if you would come to visit aerospace > engineers and hear them talking about their latest improvements to > whatever they are doing, again, it will be a different dialect. And in > my opinion, this is exactly what Racket provides us with - common > platform (Racket, English, UTF-8, math ...) and you can create a dialect > that suits your needs. Quickly and without sacrificing any > inter-operational possibilities. > > And - as it is evident - I don't need project Rhombus for my work. I am > really happy with Racket as it is. I do not even use brackets... > everything is just plain parentheses to me. Yet I am really closely > following the project to see what it will bring. Because although I use > parentheses exclusively, I use at-exp for certain use-cases and it > boosts my productivity tenfold at least. But on my own, I would never > think about something like at-exp syntax. So I don't know what will > project Rhombus bring and I am pretty sure that right now it is > something I cannot help with, but I can definitely say I like the > approach the core team is taking to research the possibilities. > > > > Wow, that was a long one :). But I hope it shows nicely, that different > people with different use-cases can bring interesting ideas to the > discussion. > > > Cheers, > Dominik > > [1] https://pkgs.racket-lang.org/package/futures-sort > [2] https://defn.io/ > [3] https://pkgs.racket-lang.org/package/koyo > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/7d816c28-21a7-85d0-355d-b32030d60354%40trustica.cz > . > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CACUENr%2BfvLErgutDCVSEigVAVgZ4MKof6oyWpitbK8FVQSab-Q%40mail.gmail.com.
