Ask HN: What server side language/framework did you choose and why?
9 comments
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?
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?
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.
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.
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?
Would you choose Ruby again today starting fresh? If not, what would you choose?
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 ), 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!
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!
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).
> 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...
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...
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...
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.
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.
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.
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.
Clojure, because it is Lisp, run on the JVM, node and browser.
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...