
Ask HN: What server side language/framework did you choose and why? - avitzurel
I&#x27;ve had an interesting discussion in a Ruby&#x2F;Rails related group.<p>Without falling into the &quot;Rails is dead, long live XYZ&quot;, I would love to know what language&#x2F;framework you chose for your startup&#x2F;project&#x2F;company and why...
======
pmontra
I still believe that Rails is more productive than anything Python, because of
basic choices in both the design of the frameworks (I've used Django, Web2py
and Flask) and the underlying language. With the same level of skills you
write less code in Rails and deliver quickly also because of the
predictability of where stuff is.

Phoenix can be an alternative, at least you get some advantages with
parallelism. Elixir could have been designed to require less boilerplate when
doing common operations like creating genservers. Basically you can copy/paste
and search/replace the code around the functions that would be methods in
Ruby, which is a waste of time, but the thing that every object (the
genserver) has its own CPU is great.

That is what I suggest to customers that don't care about the language of new
projects. If they already have invested in a language anything would do. I've
seen PHP frameworks with various degrees of predictability and readability,
JavaScript (always anarchically written applications), Java 8 (can't remember
the framework but something modern, much improved compared to years ago, but
still unproductive because of Java's verbosity). I wouldn't use any of them in
my company. It would be Rails or Phoenix and a separate project for the
frontend, possibly with some server rendered pages to reduce the time to see
the initial content. I could consider writing Ruby and deploying to the JVM
for parallelism.

I never seen or used Go or .NET. Did anybody already use the latter to deploy
to Linux servers and has experience to share?

------
angersock
First time I tried doing a web startup, we used Rails, Sinatra for testing,
and no real client-side JS. Ruby provided a fairly familiar way of thinking
about classes and objects, and had enough sugar and utilities and great
libraries to get a project up in reasonable time.

The second web/healthtech startup I was an early engineer and engineering lead
on, and we used Node and C/C++. I initially wanted to backport practices from
Ruby and Rails--and did so making some view helpers and other things--but
eventually I came around to really enjoying Javascript as a functional-C-with-
closures-and-associative-arrays. Almost all of my subsequent hacks and
prototypes were in JS, going as far as Angular until it was rolled back for
simpler-to-maintain pure JS.

Nowadays I wouldn't bother doing any server-side stuff not in Erlang or
Elixir, because the community is a bit mature and conservative and because the
languages don't have a lot of magic and are still quite performant. My best-
tested web application would probably be an Elixir message board.

~~~
avitzurel
What lead you to "ditch" ruby the second time? (if it was your decision).

Would you choose Ruby again today starting fresh? If not, what would you
choose?

~~~
angersock
The second time was a result of my inability to get the CTO to move off of an
ancient version (0.10) of NodeJS--our web frontend could've been quite happy
as a Rails or Sinatra app and we could've made great use of ActiveRecord for
some of the early problems we tried to solve.

However, the realtime component of the system (streaming data to the browser)
was implemented using websockets through Node and even if we had Rails for
that we still would've kept that part in Node. I would've loved to have kept
Ruby around just for scripting and munging, but since it was also a Windows
shop (uggggh) I found it more expedient to just move things over to
Javascript. The things that I _did_ manage to take from Rails were view
helpers for things like generating links, certain types of buttons and forms,
and that sort of thing. We ended up doing a lot of reporting and that ended up
in boring old SQL, but that would've been the case with Rails too.

Today, I'm still a bit faster hacking in JS than I would be getting the rust
off of my Ruby...so if I needed to do a spike, I'd do it in Node/Express/pg-
node--again, that's just personal skill and speed, your mileage may vary. From
a testability standpoint, I think the two ecosystems are about on par
(finally), with a slight edge for Ruby. Either one is a fine choice, but if
you don't need realtime (websockets) stuff, I think you'll probably just enjoy
Ruby more. That said:

For starting a new project today, I would use Elixir. I value the already-
reasonable testing story. I value the general quality of the ecosystem
packages and conservatism (good taste, sorely lacking in Node). I especially
value that, as a compiled language, it can catch a lot more of my stupid. I
also value that it is conservatively 10x using Phoenix than Rails (
[https://github.com/mroth/phoenix-showdown](https://github.com/mroth/phoenix-
showdown) ), and does so while having a much more compelling functional and
reliability story than I see in Ruby without slowness-inducing metaprogramming
tricks. For the prototype architecture I favor, monolith + a few
microservices, that efficiency means I don't have to worry about ops stuff as
much at the start.

At the end of the day, though, go to war with the framework that you are most
comfortable with or the one that most clearly matches the problem space of
your domain. For me, that used to be Ruby. For you or somebody else, it still
might be--and that's a great thing!

------
hawkice
I used to use Elm + Elixir/Phoenix and am transitioning to Rust/Elm. Both for
the same reason: I don't want things breaking. Elixir is pretty great for
that, but odd DB connection problems every ~1.5 server-years left me with a
emergency-response burden that was a little too much (across all my services).

------
aikah
> I've had an interesting discussion in a Ruby/Rails related group.

if the discussion has a log somewhere on the web it would be interesting to
provide a link.

I don't choose this or that tech for the sake of it. I choose the right tool
for the job or what the client imposes. So it should mostly be about the
requirements. Obviously some techs are more versatile than others.

The community is also important. Getting help from a respectful and friendly
community is important. Because there are some really shitty language
communities out there...

~~~
avitzurel
The discussion does exist, although you'll need to use the "translate" options
on some of the comments

[https://www.facebook.com/groups/173510639329747/permalink/14...](https://www.facebook.com/groups/173510639329747/permalink/1493584430655688/)

I agree with your comment 100% and that's what I commented in that discussion
as well.

Question is, with 3 things that conceptually serve almost the same purpose,
why would you choose one over the other.

For example: Rails, Django, Meteor.

------
squiguy7
I get to use Go at my day job and have had great success with it considering
it has a great ecosystem of third-party packages. It's nice to have graceful
shutdown, middleware chaining, and request contexts in tandem with easy
concurrent programming.

The only troubling thing is trying to find a package manager that makes sense
and so far that has been glide.

Perhaps someday I will get to use Rust paired with the new async libraries
that are being worked on.

------
meira
Clojure, because it is Lisp, run on the JVM, node and browser.

