Ask HN: What server side language/framework did you choose and why?
Without falling into the "Rails is dead, long live XYZ", I would love to know what language/framework you chose for your startup/project/company and why...
Without falling into the "Rails is dead, long live XYZ", I would love to know what language/framework you chose for your startup/project/company and why...
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?
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.
Would you choose Ruby again today starting fresh? If not, what would you choose?
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 ), 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!
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...
https://www.facebook.com/groups/173510639329747/permalink/14...
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.
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.