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. Maybe more on this later.)

Neil V.

--
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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to