Re: [racket-users] New wiki page ‘friends of Racket’

[Neil Van Dyke]

> > https://github.com/racket/racket/wiki/Friends-of-Racket
> <https://github.com/racket/racket/wiki/Friends-of-Racket>
>

I recall Racket having a lot more friends over the years than are
represented on that page.

It would help if someone could dig up most of the past (public)
projects, summer romances, etc., and add them all to that page.

[Neil Van Dyke]

Moving this from `racket-users`...

> It seems pretty clear the change was because the team responsible for
> maintaining it changed it because they use C++:

I prefer to do engineering and science, rather than PR, but this
"friends of" effort seems to me to be mostly about PR. If you're doing
PR, then I think the above is not a safe assumption to make about
readers' perceptions, and I also think there is a good potential spin
here that you should consider making explicit:

> in the category of Paul Graham startup mode rapid highly iterative
> "first version in Lisp"
>

If you're doing PR, here might be an appropriate time to namedrop both
Carmack and Graham a single sentence that suggests a category of
industry application of Racket that would have startups using it from
the start.  As well as used by established organizations that value
"startup thinking" throughout, or within certain units/projects.

You can craft your exact message with an engineer/scientist's sense of
accuracy and constructiveness, and still get PR mileage out of it.  On
the "friends of" page, and also turning around the somewhat sour note in
that quoted thread.

I think there's a legitimate engineering argument to be crafted here,
not PR lies.  After that, you can work on being able to back up a future
argument of how Racket can scale for after the startup's initial
version, and keep delivering benefits, which I think is also possible,
and maybe one of those hypothetical startups' contributions turn out to
be key to that.

[Stephen De Gabrielle]

Hi Neil, 

> this "friends of" effort seems to me to be mostly about PR.

Yes - I just copied the title from the Rust website.

 

• John Carmac(Oculus CTO) wrote 'I just dumped the C++ server I wrote last year for a new one in Racket. May not scale, but it is winning for development even as a newbie.' (2015)

I hope this is OK?

>you can work on being able to back up a future argument of how Racket can scale

I'm out of depth with this - can you help?

Stephen

--
You received this message because you are subscribed to the Google Groups "Racket Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscribe@googlegroups.com.
To post to this group, send email to racke...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/36efb3e2-b1ca-024d-ae35-ae91bf2b62d3%40neilvandyke.org.

For more options, visit https://groups.google.com/d/optout.

[Neil Van Dyke]

That Carmack quote alone is missing important context that we now know. 
Personally, I'd instead try to very concisely summarize what we know of
the experience (i.e., Carmack found Racket to provide early development
wins sufficient to justify dumping C++ server that already existed, and
a later team moved server implementation back to C++) and to explicitly
reference the first-version-in-Lisp pattern that Paul Graham suggested
around the time he co-founded Y Combinator.  (I don't know whether PG
has said more about that since then.)

Just IMHO, and I could be overstating.  Neither of us is a PR person, so
probably we are both going to our intuition of what messages will
resonate with subsets of the audience with whom we are familiar.  And we
are familiar with different subsets.

Regarding Racket scaling for more kinds of production use, there was
some discussion on the email list recently about that.  I think that the
Racket community has enough technical expertise to grow/prove the
scalability of Racket for some production needs, but it's enough work
that I doubt it will soon be accomplished as anyone's weekend hobby
project, so I was stuck on the funding problem.[*]  One possible way
past the funding problem: startups that use Racket for the
initial/prototype version, and then the resulting investment round means
they can stressfully decide whether&how to go further with Racket or to
switch to a more proven "stack".

[*] Personally, I've only had funding in Racket for some
mission-critical but very specialized work that's not reusable.  The
only thing I can think to say about scalability at the moment is that
all that the generic Web serving stuff ended up custom (mostly due to
legacy architecture evolution, and the custom stuff performed
sufficiently well), but core Racket's `db` PostgreSQL support worked
like a champ when a large system migrated to it from a legacy `libpq` Mz
C extension interface (both alternate PostgreSQL layers being beneath a
versioned object-to-relational schema mapping layer).

[Alex Harsanyi]

On Wednesday, November 1, 2017 at 9:03:22 AM UTC+8, Stephen De Gabrielle wrote:

>you can work on being able to back up a future argument of how Racket can scale

I'm out of depth with this - can you help?

Hi Stephen,

Perhaps I can help a bit with this: based on my experience in writing and
using my ActivityLog2 fitness tracker, I found Racket to be pretty good for
data processing and drawing (both plots and general drawing operations).

For data processing, my current ActivityLog2 database [1] contains 6 years
worth of training data, it is 470 Mb in size, for a total of 2.5 million data
points.  Each data point contains up to 28 data items, such as GPS position,
heart rate, power, etc.  A single run or bike activity contains between 3000
and 10000 such data points, and plots for these data sets can be instantly
generated, directly from callbacks of GUI elements.  Generating data for trend
charts (like histogram, or best-avg) involve analyzing data points from lots
of activities; these operations are is still fast but require judicious use of
caching, as they are no longer "instant" operations. The GUI for such
operations also had to be changed to be non-blocking and to show progress.

Drawing operations, such as displaying and moving a map with several GPS
tracks, are fast and responsive.  Most of the drawing code is "naive" and
straightforward, with no optimizations, so all the speed and performance is
due to the drawing libraries in Racket.

Footnotes:

[1] Unfortunately, this database contains a lot of private information and I
    will not share it.

Best Regards,

Alex.

 

Stephen

On Tue, Oct 31, 2017 at 9:49 PM, Neil Van Dyke <ne...@neilvandyke.org> wrote:

Moving this from `racket-users`...

It seems pretty clear the change was because the team responsible for maintaining it changed it because they use C++:

I prefer to do engineering and science, rather than PR, but this "friends of" effort seems to me to be mostly about PR. If you're doing PR, then I think the above is not a safe assumption to make about readers' perceptions, and I also think there is a good potential spin here that you should consider making explicit:

    in the category of Paul Graham startup mode rapid highly iterative
    "first version in Lisp"

If you're doing PR, here might be an appropriate time to namedrop both Carmack and Graham a single sentence that suggests a category of industry application of Racket that would have startups using it from the start.  As well as used by established organizations that value "startup thinking" throughout, or within certain units/projects.

You can craft your exact message with an engineer/scientist's sense of accuracy and constructiveness, and still get PR mileage out of it.  On the "friends of" page, and also turning around the somewhat sour note in that quoted thread.

I think there's a legitimate engineering argument to be crafted here, not PR lies.  After that, you can work on being able to back up a future argument of how Racket can scale for after the startup's initial version, and keep delivering benefits, which I think is also possible, and maybe one of those hypothetical startups' contributions turn out to be key to that.

--

You received this message because you are subscribed to the Google Groups "Racket Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.

To post to this group, send email to racke...@googlegroups.com.

[Stephen De Gabrielle]

Hi Neil, 

> I'd instead try to very concisely summarize what we know of the experience

I just don’t have the skills for that. I’ll just remove the mention of John Carmack. 

Maybe people like yourself and John can add their testimonials about their experiences with Racket. 

>w switch to a more proven "stack".

 I *suspect* the whole ‘scaling Racket’ thing is a furfy, and for the vast majority of applications or websites this is never going to be a problem. I don’t *know* if this is true, so I’d welcome some _evidence_.

Kind regards,

Stephen

--

Kind regards,
Stephen
--
Ealing (London), UK

[Stephen De Gabrielle]

Hi Alex,

That is brilliant. Woul you put you good experience with Racket performance on your blog? we can then link to it on the wiki. 

Thanks,

Stephen

[Neil Van Dyke]

Stephen De Gabrielle wrote on 11/01/2017 04:46 AM:
>  I *suspect* the whole ‘scaling Racket’ thing is a furfy, and for the
> vast majority of applications or websites this is never going to be a
> problem. I don’t *know* if this is true, so I’d welcome some _evidence_.

I agree that some of the industry chatter about "scalability" is just
chatter.  And it's a good grown-up-sounding term to use when we don't
know anything else to say about a platform.  But I think the reason it's
grown-up-sounding is that, at one point, our honorable ancestors learned
that servers have performance characteristics and requirements, that
naive approaches are often simply inadequate, and that "scalability" is
a real concern.

Two scenarios of being concerned about scalability:

* If my new-college-grad startup team does a bunch of coding like the
platform tutorials say to do, and we don't yet understand much of what's
going on, will the result perform well enough on an EC2 large instance
for the moderate-volume webservice of our iPhone app, despite much of
our own startup code being sloppy?  (Answer: Maybe...)  And will we be
able to keep it working acceptably if our beta users grow
ten-thousand-fold literally overnight?  (Answer: We could probably
simulate that load, against our evolving prototype, in a testbed server
setup.)

* If my highly-skilled team uses this platform in our architecture, when
we need our processing to handle X requests per second with Y
responsiveness, and we know we'll have to be creative regardless of
which platform we use, is this platform's part of it going to perform at
least as well as if we'd used this other platform for that part, or are
we going to have to work harder or pay more for hosting to compensate? 
(Answer: Maybe...)  And are there platforms that are more proven in this
regard?  (Answer: Yes.)

I suggest... We appreciate that scalability of one's use of a platform
is a legitimate concern, and hard to answer, and the "platform" is just
one factor.  And we know that, with Racket, like most other platforms, a
CS 101 student can't just make a poo in an IDE and call it a high-volume
Web site.  Usually.  And we don't assume that we scale in ways that have
never been proven.  And we know people feel better about picking a
platform as a part of their architecture when they see successes that
managed to use that platform in a similar way.

For your evidence, I think the most-known public server deployment among
developers is probably Hacker News.  You can ask them how their setup
works currently, and how much of Racket is being used, and what they had
to do around that.  (I suspect their answer is not that different than
my own production server experience: most of it is not what current
Racket docs imply is the platform, there was also some standard
extra-platform infrastructure, and clever engineering was required on
some tricky parts.)

What I suspect Racket industry promotion wants is a startup team that
does their rapid prototype in Racket, and, when it comes time to move
forward, they are technically strong enough to assess things and see a
way that they can confidently keep using Racket.  (Good news: clever
engineering, elbow grease, and cloud servers make most things possible.)

[Stephen De Gabrielle]

Hi Neil,

I agree with everything you have written, but the suggested actions are beyond my capabilities;
- Hacker news(or ycombinator) are not likely to be interested in providing a Racket testimonial and I’m not the right person to be asking.
- I don’t know any startups, and I’m not ready to start one.

(If someone does - there is a place to put it on the wiki!)

I know very little about PR, I put up the ‘friends of’ page because it was fun to collect the bits and pieces I’d heard of, and I thought it might be useful because it is one of those questions that come up from time to time. Changing the licence and moving to the Chez VM will probably have mor impact than my occasional noodling about with the wiki.

Kind regards,
Stephen

--
You received this message because you are subscribed to the Google Groups "Racket Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.

To post to this group, send email to racke...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/cf5c8857-3a00-ff64-d77e-f8cc2806a791%40neilvandyke.org.

For more options, visit https://groups.google.com/d/optout.

[Alex Harsanyi]

On Thursday, November 2, 2017 at 2:39:09 AM UTC+8, Neil Van Dyke wrote:

Stephen De Gabrielle wrote on 11/01/2017 04:46 AM:
>  I *suspect* the whole ‘scaling Racket’ thing is a furfy, and for the
> vast majority of applications or websites this is never going to be a
> problem. I don’t *know* if this is true, so I’d welcome some _evidence_.

I agree that some of the industry chatter about "scalability" is just
chatter. 

Not necessarily.

From my ActivityLog2 experience, around the Racket 6.2 release, using the 32
bit build, "raco make" would run out of virtual memory when trying to compile
my application (on a machine with 12 Gb of memory).  The 64 bit build would
use several Gb of memory.  Also, the resulting application would start out at
~900 Mb of resident memory before opening a database.  This turned out to be a
bug in the Typed Racket compiler.

At the time, I didn't think a 30000 line application to be a large one: the
code bases I work with are several million lines.  This was a disappointment
for me: Given that no one complained about these compilation problems, the
only conclusion I could draw was that no one was using Racket for anything
more than a small program.  I was very close to abandoning Racket at that
point.

The high memory usage bug was fixed by now, although I still don't know if I
can use a 32 bit Racket to build my application.

BTW, I also had problems with drawing performance, and "rkt/plot-hack.rkt"
is a testimony of that.  I believe the file is still needed, but I would have
to check.

Given my experience, I think having a wiki page showcasing *concrete cases* of
Racket applications would boost confidence of others to use it in their
projects.

BTW, I will write the blog page Stephen asked for, but I'll do it over the
weekend.

Best Regards,
Alex.

 

[Neil Van Dyke]

IMHO, the Racket techie community should naturally have a lot of overlap
with the Hacker News community, so it sounds odd if we are not already
friends.

If you want to prioritize outreach for smart, independent-thinking
techies who might be inspired to try commercial use of Racket, then,
near the top of the priority list for meaningful engagement, I would put
places like HN and some non-totally-astroturfed corners of Reddit. 
These are people already seeking out high-quality concentrations of
social hardcore nerds, and isn't that one side of Racket?  (Just because
a particular huge 'social media' dotcom still has a lot of users,
doesn't mean you'll find concentrations of smart techies still using it
more than they have to.)

Ideally, 100% genuine immersion, and personally wanting to participate
with other communities on their own merits, not a corporate Social Media
Community Manager or Buzz Marketer type of role.  But if not enough
people have time for that, then more an ambassador role can be done well.

(I'm speaking here of engaging techies who are likely to be ready to use
Racket for real-world development.  I also very much approve of Racket
welcoming everyone who comes to it, as well as mass education that
elevates everyone, but I don't know much about those.)