jun lin wrote on 02/19/2016 04:24 AM:
I'm not sure using Racket is a good choice for a startup. Racket
itself is a good language, but if you need do something serious, you
also need bullet proof libraries. In the detail, I'm interested in web
development, and looks like Racket don't have good ORM and web
framework libraries.
It depends what you're trying to do, and how you want to do it.
Sometimes it goes back to my comments in another thread here the other
day, regarding "DIY":
Neil Van Dyke wrote on 02/13/2016 01:33 PM:
I'd say the biggest downside is that there is still lots of things
that are off-the-shelf for some mainstream platforms, but require some
in-house DIY work for Racket. Sometimes this is something you can DIY
faster and better than you can get an off-the-shelf solution
integrated, but sometimes the DIY is just extra cost with no direct
benefit.
There is also a long discussion to be had about the countless different
ways that people develop and deploy Web-based systems, and how that
relates to Racket and startups. Quick off-the-cuff brain dump for now,
since had a non-decaf coffee this afternoon...
Not only is the sheer size/complexity and numbers of 'standards' and
languages and frameworks *massive* now, but they're constantly growing.
And still, unless your needs fit some now-conventional way of doing
things, there's a significant chance you'll be unable to find a
framework that does what you need well, and you'll only discover that
after substantial investment in evaluating different ones. (In support
of that last assertion: notice that the houses of successful Web-ish
companies with skilled developers, like
Google/Amazon/Facebook/Twitter/Yahoo/Microsoft, usually end up
developing their own frameworks and other infrastructure, even when
that's not their business.) I have worked on projects in which Racket
DIY saved the day, when no off-the-shelf solution would've been viable,
no matter what other language had been used.
So, depending on the nature of your startup's innovation, it might well
be that you are doing something Web-related that doesn't actually fit an
off-the-shelf Web framework anyway. You're probably OK with
off-the-shelf "Web" frameworks, if you're making yet another photo
sharing site; possibly not, if you're doing yet another messaging/forum
service or `sharing economy' middleman middleware, that scales and
integrates with necessary devices/services; also possibly not, if doing
needing "Web" bits that competitors/owners currently guard closely or
that is just now emerging; also possibly not, if you're you're not just
exhausting the combinatorics of mash-ups of well-known successful ideas
like "We're like cats.com, but for hamsters!", and your ideas imply
non-entirely-clerical-grunt-coding technical requirements.
That said, if your startup's innovation does fit off-the-shelf
frameworks well, as they often do, then a Racket-inclined team
especially will have to ask themselves, "What are the
benefits/costs/risks of doing this in Racket, given what we can foresee
about how our architecture would use off-the-shelf and DIY, and how does
that compare to what we can foresee about other language-rooted
platforms we might use instead?" The decision could easily go either
way, with many rapidly-moving early startups. To contrast, for a stodgy
corporate system, the decision will usually go with what the broader
organization (or subset) already uses, or something otherwise
politically safe to pitch and implement, in a "nobody ever got fired for
buying IBM" way -- but startups tend to have more flexibility than that.
(Aside regarding contributing the hypothetical DIY bits back to Racket
community... I do have a model/story for, when an organization does DIY
some bits in Racket, how to maintain the non-proprietary DIY bits in a
low-cost and possibly-beneficial (not altruistic) open source
lifecycle. This involves a particular correspondence between kinds of
reusable open source components, and good practices for systems
architecture and organizational software engineering process, and some
tools to support that. But, for an early startup, I would probably
advise against open source contributions, except for patches to upstream
of others' established stuff, because cost:benefit doesn't seem likely
to work out for a startup in the near term. My own open source bits are
to promote the platform as a consultant, or just altruistic, not an
example for startups, and I've also been sitting on some unreleased
packages for reasons that a startup might. Later, once the startup is
more successful, they can look at retroactive open sourcing of bits, as
a one-time dump for PR/hiring purposes, or even maintained that way, or
possibly do new/ongoing development with a model/story of
self-beneficial architecture/process/tools that happens to fit well with
open sourcing, but that's after already successful.
