What I really liked about Ruby on Rails when I took an online course on it were the schema.rb files and `rake db:migrate` command. I don't know if there's an analog in Python, but honestly I think clean, highly structured, maintainable data is way more important than the backend you use. Having the ability to quickly iterate your SQL schemas and roll them back as necessary is essential to shipping high quality features with fast changing requirements.
Just wait til you actually work on some production code... For the most part you don't actually want to roll back schemas as you would lose data. And iterating on SQL schemas in a live app involves all kinds of tricky edge cases and backfills, knowing when to make your changes in multiple steps, being careful not to take down the whole thing because you didn't realize a certain change required a full table lock or a certain index would take so long to create, etc.
As is so often the case in Rails, it's set up to be nice and simple for a hello world example but little more. It doesn't actually make things as simple as they seem at first, and you're on your own to figure out which of its niceties are actually helpful and which are dangerous to use that you need to build your own workarounds for.
I'm having trouble understanding how one could run into a bottleneck only after you reach Facebook or Google or levels. Surely if you have performance issues when you are running on 10,000 machines, you would also have a bottleneck when you start to outgrow your single machine.
> For the most part you don't actually want to roll back schemas as you would lose data
Can you name a framework where you roll back schema changes and don't lose data?
> being careful not to take down the whole thing
You still need this caution if you don't use rails
> a certain change required a full table lock or a certain index would take so long to create, etc.
I feel like you're just describing working with a relational database in a production setting. This isn't rails specific
> Rails, it's set up to be nice and simple for a hello world example
Sure. I'm also pretty sure it's used in production by some great companies whose applications/APIs are a pleasure to use - SendGrid, Github, Stripe, and last time I checked Hulu to name just a few.
Just because it's not the framework of choice for the majority of companies doesn't make it incapable of being used at scale.
Or you inherit a DB that’s a complete disaster scheme wise and all the nice assumptions go out the window.
I’ve mostly found that migrations work best as a structure way to just run normal SQL and know a) what ran b) when.
For that they are handy.
I’ve even considered how to structure a stand alone migration running tool with a nice API since the good ones for each language tend to be fairly different.
It annoys me that the tooling around RDBMS in 2019 is still so shit.
Prime example, try to find a halfway reasonable way to debug a badly written MySQL sproc you inherited.
I’ve used Flywheel (https://flywaydb.org/) for this exact problem on personal projects before and been fairly happy with it. It’s intended for use in JVM-based projects, but ships with a CLI that gets you a long way.
Sqitch by David Wheeler is a great way to manage database schemas. I haven’t uses it in production, because I mostly use Rails and haven’t felt enough pain to justify the switch.
I agree, and most other commenters still miss the point about what makes Rails so great :
it's not the technical part (you can point slowness, quirks in how the language/framework is used) but the human and business part. It works. It makes adapting to change easy. Yes it's a monolith, yes it encourages fat models, etc. But it works so damn well.
`rake db:migrate` is not so great as a feature (other frameworks in other languages have it), the greatness comes from how well it's integrated with the Rails workflow.
Yep, Laravel (PHP) lifted it en masse (so much so that when I had to get up to speed with laravel years ago I used the rails docs to fill in the blanks) and Symfony with Doctrine is in some ways better.
Every time I try to write some "super simple web app" that I think is much too small for Rails I always end up in spots like this: migrations, then asset fingerprinting, then some quick sanity tests, oh, now I need this other thing and I've cobbled together a creaky messed up version of Rails.
Python SQLAlchemy/Alembic and Django has db/schema migrations.
.NET has db/schema migrations in Entity Framework.
Node/javascript has sequelize/umzug, node-db-migrate and others for db/schema migrations.
Migrations are pretty common now for ORMs, or any code first schemas, but are definitely a killer feature and needed with ORMs to see what is being changed/iterated on.
Came to this thread to suggest squitch. Glad it's mentioned here. I really enjoy it's three generic concepts - deploy, verify, revert - and not having to tie my migrations to any particular language or ORM. In additon, it's supported on every operating system I've used with it and has got a docker image in case that's not good enough.
I suggest checking out https://flywaydb.org/
It doesn't have the ORM-ness mapping rails migrate does, but it makes it really simple to organize sql scripts to move/update schema configs.
Another option is a schema management tool that doesn't rely on migrations at all. I'm the author of one, Skeema [1], for MySQL/MariaDB. Others include migra [2] for Postgres, and sqldef [3] for MySQL or Postgres.
These all use a declarative approach [4], where the user just specifies the desired new state, by adding or changing the set of CREATE statements. The tool knows how to run the correct DDL to reach that new state.
Yeah I've thought the exact same thing before and I've actually tried both.
The clear difference is that migrations are easily reversible. Good migration libraries can also reverse data migrations.
A folder of SQL scripts was very refreshing, but no way could I use that system in a production environment. There's just too many edge cases to keep in your head.
Manually migrating has the issue of testability and hit by the bus.
I don't believe every migration needs a roll back, sometimes the better strategy is restore from a snapshot/backup.
Java seems ideal as it will be completely cross platform and you can add / update the database drivers after the fact.
Migrate has a different binary for each platform and from what I can see, the support for each database is compiled in, so just to update a driver you are going to be maintaining that binary all over the place.
Migrate is awesome! My only issue: Since it uses bare SQL for the migrations, you have to do some lifting if you need to support multiple RDBMS with different DDLs. I have some regexes in my project to translate Postgres DDL into SQLite DDL for my test suite.
Why would you not test your code with the same RDBMS you will have in production? Especially if it’s something as easy to install as Postgres? It seems like begging for trouble...
If you're using an ORM, it can be an easy way to ensure that no vendor specific stuff sneaks in. Also, until recently it was difficult to run, e.g., SQL Server in Docker, so Postgres might be easier to test with. Agreed SQLite is a weird choice, but not all integration tests are robust enough to test characteristics of the underlying db, i.e. focus on business logic not performance.
I have several dozen tests that run in completely separate DBs. With SQLite, the test suite runs through in 1 second:
$ time go test github.com/sapcc/limes/... | grep -v 'no test files'
ok github.com/sapcc/limes 0.004s
ok github.com/sapcc/limes/pkg/api 0.515s
ok github.com/sapcc/limes/pkg/collector 0.449s
ok github.com/sapcc/limes/pkg/core 0.006s
I doubt that you can setup and tear down several dozen Postgreses in that time.
The activerecord-migrations gem allows you to use Rails migrations with other languages too—I’ve used it with node, clojure, and others where the community migration libs aren’t as good.
This type checks all ORM operations, and type checks against the actual schema at compile time. It's pretty cool and made by one of the long-time developers of ActiveRecord.
"Ruby was optimized for the developer, not for running it in production," says Sid. "For the things that get hit a lot and have to be very performant or that, for example, have to wait very long on a system IO, we rewrite those in Go … We are still trying to make GitLab use less memory"
Honestly, I think that Go is beginning to be where Rails was few years ago, and lots of developer friends want to hop on the Go train because everybody is doing the same.
In the same time, I'm thinking about switching to Gitea or Gogs + Drone.io, because Gitlab takes just too.damn.much.memory !
Seriously, 8GB RAM to even just begin with ? (Because yes, 4GB RAM + 4GB Swap is not viable).
Even my biggest website is not consuming as much.
So if I could suggest something, it would be a global rewrite in Go or something like that, to lower the requirements, not just one or two parts (excuse me, microservices ;)).
GitLab is using a lot of memory for various reasons, all of the big ones (like adding multi-threading which I proposed 3 years ago https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 ) can be solved without a rewrite. I've failed to make this a priority within the company. We had people work on it for some time but the day to day of shipping features, keeping GitLab secure, and other tasks took over. I'll advocate for a dedicated performance team to solve this. Until that team is formed people like Stan are making steady progress https://news.ycombinator.com/item?id=18973499
Or Elixir, or Rust, or Node. Having spent time with all of these options, Rails is still really really good for a lot of use cases. Go comes nowhere near Ruby's readability for me (but I like the lack of surprise).
Personally I'd love something typed, performant, and as readable as Ruby with a convention focused platform like Rails. Elixir + Phoenix is probably the closest I can find, but not a perfect fit. Maybe close enough though.
I am not fluent in either, and I'm not looking to change that, but I have read code in both. I feel the exact opposite way, and I'm not trying to start a war or anything, but I was wondering if you'd be open to talking about what things in Go you find hard to read (and what things in Ruby you find very easy to read). Or is this about libraries (are Go libraries providing lower-level APIs than Ruby ones?)? Or have you read/written a lot more code in Ruby than Go?
I agree - Go has issues, but they're not related to readability. Perhaps if you include "familiarity with the standard interfaces" (like using io.Reader) which is different to other languages, and took a while for me to get used to.
Crystal it is. Combined with the amber framework, porting the Ruby Code should be straightforward. Yes stuff isnt even 1.0 yet, but I would seriously bet on it right now.
I agree that memory requirements are too high, but I think there is a lot of room for improvement without a complete rewrite, which would be very costly. Also keep in mind that a standalone GitLab instance ships with all batteries included: PostgreSQL, Redis, etc., all of which add to the memory requirements. That being said, we are certainly looking at moving performance-critical functions into Go. See the GitLab Workhorse and Gitaly projects as examples.
There are two major ways to look at application memory usage: baseline and runtime usage. Most people pay attention to the first because that's what you see when you first deploy GitLab. However, runtime usage is just as important because a running instance could gobble up gigabytes of RAM.
Baseline memory: We've made some recent progress in reducing baseline memory usage (e.g. cutting 80-100 MB per Unicorn process in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21008). However, our Unicorn workers dominate most of the memory usage, and you can see more analysis of where our memory is going in https://gitlab.com/gitlab-org/gitlab-ce/issues/49702. https://brandur.org/ruby-memory is probably the best explanation I've seen why RAM usage in Unicorn processes often rises and doesn't come down. However, we can reduce baseline usage in a number of ways:
Runtime memory: Most of our runtime memory problems are often due to memory bloat or unoptimized code paths. For example, we put big dent in some of the most egregious background jobs over the last few months. For example, a change in our merge request processing in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22725... lowered 95% of our runtime usage by gigabytes. Switching to a faster XML processor in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23136 also dropped memory usage in another background job.
Obviously we're still far from where we should be, but we're making progress. If you or know anyone else who might be excited to help us, please let us know! https://about.gitlab.com/jobs/ Thanks for your feedback.
Very interesting, thanks!
One idea I had was to push "plugin-ability", for example not everybody want to have the Gitlab Pages function, or some might want to completely replace Gitlab-CI by Drone or Jenkins, and all that could help lower the memory requirements. Or maybe I'm wrong?
I used to be RoR developer a while ago. Working with gitlab is a breeze because I can apply all the knowledge I have - by the virtue of being a RoR app i know how can i apply migrations, how to call interactive console, how to monitor and clear work queues, how to add middleware. Gitlab using RoR is a great win for /me/
> Oh, and Ruby and multithreading don’t mix, who knew?
Modern Ruby has great support for threading. Rails has been threadsafe since 2008 and Ruby has a huge advantage over Python in JRuby: no GIL, JIT, parallel GC etc.
As an aside, when companies are doing these interview-style pieces are they actually interviewing the CEO? I always just assume they pull the quotes out of their ass.
I don't know about other companies, but given that gitlab's CEO is the type to be regularly active on HN (and will probably be reading this) it seems safe to assume that he would actively cooperate with such an article
As listed in the article under 'Overcoming challenges' we do replace code in Go and Vue where needed. I do believe Rails is still the most productive framework out there.
The full system is built in rails and I query and generate information on a million or so accounts and tens of millions of comments. Haven’t really hit a bottleneck yet.
It seems that every few years a new backend language comes to the forefront and becomes a popular for greenfield projects or rewrites. First people moved from PHP to Ruby, then Node, and now Go.
Of course, Go's popularity is helped a great deal by Google using it, as well as the huge amount of devops software written in Go (docker, terraform, kubernetes). But at some point the hype for those will settle and they'll just become more tools. At the same time there'll be more and more legacy Go projects at various companies that won't be very exciting. Around about this time we'll probably see the next language start rising in popularity.
To me, the article reads like "We REALLY don't want to abandon Rails so we rewrite the hot paths to Go". I mean no offense; I just wasn't able to find good argumentation in it for sticking with Rails. To me, the article kind of makes the argument for Go.
"Developer productivity" is not a myth and it does exist. But Rails is very far from the only framework that gives you that.
IMO you should seriously evaluate making your web + API gateway in either Elixir or Go, outline a migration plan and get on with it.
Well, that complexity is yours to evaluate -- what I am saying is that you are seriously underestimating the Elixir community. And our forum is full of people making this same admission and saying they regret not reaching for Elixir earlier! :)
In the end, it's your call of course. But line-count doesn't say anything about a project's complexity. Go is quite verbose but with rigorous CI, tests, code reviews and linters, teams produce pretty hardcore and good software in Go, regularly.
I agree Go produces great software. But for the same amount of functionality it tends to require more lines than ruby. I tend to favor the more expressive language http://www.paulgraham.com/avg.html
Another thing is that there isn't a web framework like Rails in Go. Although I'm keeping an eye on go-micro and we plan to add that as a template soon.
Yeah, fully agreed on that. Go just doesn't have as productive a framework like Rails. That's why I only use it for very small websites or even smaller API gateways. Or CLIs. Or network daemons.
I am not disputing your choices. Just wanted to give you the quick and intuitive (and likely misinformed) immediate reaction that I had from the article.
>"Our mission is that everyone can contribute," he explains. "Because Ruby on Rails is really opinionated about which pieces go where, it's much easier for new developers to get into the codebase, because you know where people have put stuff. For example, in every kitchen you enter, you never know where the knives and plates are located. But with Ruby on Rails, you enter the kitchen and it's always in the same place, and we want to stick to that.
If you’re in the business of developing enterprise apps (and that’s where the money for dev tools resides) then moving quickly without breaking things is critical in your formative years. Static typing goes a long way to facilitate that.
It’s by no means a panacea but it does eliminate an entire class of error and obviate a related class of unit testing.
Yes, otherwise we wouldn't be talking about it. That doesn't mean their parallel universe images who chose a statically typed equivalent, ceteris paribus, aren't better off.
"Lots of people do it so it must be fine," has to be the weakest form of argument I know. Which is funny, because lots of people use it. Hmm...
fwiw I completely understand! I have also regretted what seems to be an instinct or habit to go for that same perspective. I’m not sure I can explain in a way that makes sense.
After using it for our test pipelines for a year we've switched to GitLab CI completely with our deployments and right after we've started running into issues on our selfhosted instance where for about three weeks now we're fighting with stuck pipelines where runners won't pick up jobs until you manually restart them. We've been paying customers for GitLab Enterprise (now Starter) for years and the recurring theme is that our tickets go unanswered for basically ever.
We're having performance issues on AWS, trying to run on ECS with an EFS Filesystem underneath, have basically done everything to rule out the EFS as the issue and now because our tickets go unanswered migrating to a dedicated EC2 Instance to see if this makes things run faster...
From a product perspective we're starting to love GitLab, but from a technical & business pov it's getting increasingly painful to work with if you rely on it for too much.
I wonder if Ruby is the reason it's hard for them to run reliably as a self-hostable solution, but as I have 0 Ruby experience I wouldn't know.
I'd like to follow up on this to see where we dropped the ball and how (or if) we can make things right. Feel free to email me at lyle[at]gitlab.com and I'll look into your ticket history and move things along.
This isn't to say that EFS doesn't have its place, it's just that git operations quickly exhaust burst credits and many of our users on EFS end up with difficult to diagnose performance problems.
This may or may not have anything to do with @Roritharr's problems, but it's worth noting!
> Ruby was optimized for the developer, not for running it in production," says Sid. "For the things that get hit a lot and have to be very performant or that, for example, have to wait very long on a system IO, we rewrite those in Go
Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix. I wonder if they considered it.
> Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix. I wonder if they considered it.
The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community). Ecto is still going through some massive changes (ActiveRecord is comparatively stable). Personally I think that Elixr is an interesting language but it's not one I'd want to mess with in a production environment.
The big win for Go is that it compiles down to a single binary. Ruby you get a single point of entry (script with a shebang). But Elixr/Phoenix? You get a handful of bash (not even POSIX sh!) scripts and binaries and a whole VM to deploy. As a BSD user, I gave up on Elixr/Phoenix after trying to debug the nightmarish deployments that had been broken for months. I couldn't tell if it was an issue in the rat's nest of bash scripts or a VM bug. Sure, ruby-bcrypt is broken on FreeBSD too with a similar head-in-sand mentality from the bcrypt gem maintainer (which could make Rails deployments a non-starter) but that's easy to fix and has been fixed out-of-band. Elixr? Well there's one maintainer for the deployment tool and he's stopped responding to bug reports of any sort.
That said, I like Rails. A lot. But ruby is painfully slow and I've learned to push as much logic into the database as possible. So there's a compelling case to be made for an alternative. Unfortunately I've never had any other language give me that much trouble as Elixr has. Personally, I detest Go dependency and build management (and the Google involvement), but the simplicity of concurrency and deployment combined with the breadth of the standard library make a very compelling case for Go IMO. Hell, I would reach for Clojure before Elixr because at least then you're dealing with the comparatively mature Java VM.
Personally I've gone down the Rust road, but even then I'm not sure I'd want to deploy a Rust web app in production just yet (although I really do like Rocket).
> The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community)
What are you viewing as mature? It's a loaded word and many people use it with a different meaning in mind.
> Ecto is still going through some massive changes (ActiveRecord is comparatively stable)
As of the latest release of Ecto -- 3.0 -- the maintainers said they consider it mostly complete and said they will not do breaking API changes [0]; this part in particular:
"With the release of Ecto 3.0, I would like to announce that I finally consider Ecto to provide a stable API. This means no more new features, although we will continue providing bug fixes and updates. For everyone running Ecto in production, rest assured that Ecto will continue to be a well maintained project with the same production quality and polish that it has today."
So the first part of your statement is factually false.
For ActiveRecord being stable... subjective, I'll give you this much. Try and migrate a Rails 4.0 app to 5.x and come cry with me over a dozen beers. ;)
> Personally I think that Elixr is an interesting language but it's not one I'd want to mess with in a production environment.
Many people and organizations are "messing" with Elixir in production with great -- and increasing -- success.
Phoenix at the moment is one of the very few frameworks that delay your scalability problems much farther into the future than most me and many others have worked with. Phoenix can easily give you thousands of requests per second on a $5 DigitalOcean droplet. Rails and several C# and Java frameworks cannot.
I am not attacking you and I hope I don't sound that way -- but you seem to have a non-factually supported negative bias against Elixir. It gets more mature by the day and is quite capable of very serious work in pretty tough environments. Positive case studies spring into existence often.
> but you seem to have a non-factually supported negative bias against Elixir.
If deployments are broken for months[1] with no fix in sight, what do you expect? I'm currently seeing zero requests per second with Elixr. If the sole maintainer of the sole deployment tool is too disengaged to reply to bug reports I don't care one way or another what sort of performance a product (or its fanbase) are claiming. If the product can't be deployed it's not going to scale. Period.
It's a bit silly to talk performance comparisons between Ruby and Elixr as the premise of this article was that Ruby is simply too slow. Are you going to have a harder time scaling Go or Rust than Elixr? I doubt it. I have no idea if you're going to have a harder time scaling Java than Erlang, but Java is popular enough in the enterprise space that finding people with that sort of experience isn't so difficult. The only time I've seen Erlang at scale was with Megacorp's Enterprise Chef deployment. There was easily tens of thousands of dollars in hardware there and the Chef server was still regularly brought to its knees with well less than a thousand total users (and well fewer than that at any given time).
Open source maintainers burn out. It's a fact of life that's hardly specific to Elixir though, wouldn't you agree?
As for deployments, I've setup several of them in the last 2 months -- from scratch, and successfully. There's an initial learning curve that might be way too annoying for many. The deployment story is one of the weaker parts of Elixir -- I am not running away from that.
As for scaling, you might be mistaken. Erlang/Elixir can be scaled with almost zero effort up to 50 or so machines before you need to introduce special libraries or any extra tooling at all.
Of course, you can do the same with many other languages if you put Kubernetes or HAProxy in the picture. Point is, with Erlang/Elixir, it is 99% effortless up to a certain scale which most projects won't ever hit.
If you were talking about raw speed however, I can't argue that Erlang/Elixir are just a little faster than a very optimized JS (and still plenty faster than Python, Ruby or PHP). But nobody advocates Elixir for raw number crunching.
> Open source maintainers burn out. It's a fact of life that's hardly specific to Elixir though, wouldn't you agree?
Of course. How many languages have a single deployment story maintained by a single person though? That level of fragility is something I wouldn't put in production. Period. Not even on Linux.
And, yes, you could just compile the app in production (and watch the security team lose their shit). Or you can blow everything away for each deployment. Or you could use a tool that's simply less tedious to deploy (e.g. Rust, Go, Java, Clojure, ClojureScript, Javascript).
To put it another way, if deploying is a pain, scaling is a pain.
> To put it another way, if deploying is a pain, scaling is a pain.
I can't understand that argument. Would you please expand?
---
I agree it doesn't look very trustworthy that the only viable deployment option in Elixir is kind of stalled lately. Of course. What I am saying is, what we have at the moment works plenty well -- if you can get over the fact that enabling deployment in an Elixir app is needlessly complex.
As is said many times here in HN, judging an open-source project by its frequency and recency of commits is quite a flawed strategy.
> I can't understand that argument. Would you please expand?
See the Github issue linked (and the related issues). Distillery is known broken. Who cares if Elixr or Erlang scales really well if you can't even get it deployed? That Distillery is, for all intents and purposes, abandoned is secondary. It wasn't left in a usable state.
Uh, there's also a suggestion that setting NODE_NAME will fix the solution. Unfortunately the issue remains open because Distillery has been abandoned in a non-working (which, by definition, is broken) state.
I would compare Elixr to Go, Java (OpenJDK), Javascript (node) and Rust here. All have passive support for the BSDs, and yet all three have actively maintained native packages (rustup and/or ports tree). That neither the Distllery author nor the BSD users have managed to come up with a solution is quite telling — deployments on Elixir are nightmarishly complex. I'm most familiar with Rust, so in contrast if you look at the the BSD specific issues you'll find a very engaged userbase.
Deploying unmaintained software in production is sometimes a necessity with legacy stuff but is almost always a bad idea for new deployments. Elixir has plenty of passionate advocates but no good deployment or support stories. That's just a long-winded way of saying Elixir/Phoenix, unfortunately, aren't things I would be comfortable deploying in production (Linux or not) no matter how many compelling ideas they dangle in front of you. And, as has been pointed out, Elixr doesn't offer significant (if any performance benefits) over modern Ruby (and by extension Java, Go, or Rust).
That is undeniable. Java and Go are definitely faster in terms of raw performance.
The main value proposition of Erlang/Elixir is: a very acceptable performance combined with unparalleled concurrency primitives, plus resiliency and high availability. Not performance alone.
Could be. I abandoned Rails 2-3 years ago and haven't looked back since. Even then migrating a project to Ruby 2.3 was a huge pain due to the immutable strings feature. It was one of the things that made me throw my hands in the air.
But I almost haven't seen a Rails project using Sequel for 6 years of working with it. 99% of the projects use ActiveRecord.
> Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix.
Elixir does not have the language patterns of Ruby, though it has a deceptive visual similarity.
We are watching Elixir closely ever since visiting Krakow, Poland for the Railsberry conference in 2013. This is also where my co-founder Dmitriy and I first met in real life.
> language patterns of Ruby but want better performance for concurrent processes
But then take on the disadvantages of acquiring talent and less adopted programming paradigms (e.g. functional programming)? Elixir/Phoenix is awesome, but it's not a panacea for everything.
Language/framework choices aren't done in a vacuum.
We've had good success teaching team members with no FP or Elixir experience and training them to be productive Elixir developers. It takes investment, but so does having an employee.
Would you be able to give an example or two where you would reach for go vs elixir and vice-versa?
I’ve tinkered with Go, and while it was fairly enjoyable to work with on the small scale, but the lack of generics and constant err != nil checks, and Go 2 on the horizon, I decided to hold off on building anything non-trivial with it.
I’m currently rewriting a Rails app into smaller elixir components, the Rails app is mostly consists of several potentially long running processes that gathers large amounts of data from various sources, does some light transformations, and then combines it and outputs it in various forms. Elixir has been immensely more pleasurable to write in, as OTP, along with things like GenStage and Flow, seem like a perfect fit for this task. And, while go’s channels are cool, they don’t seem nearly as powerful as elixirs actor model/OTP — at least for this example.
The one advantage of Go I can immediately think of is using it for some networking heavy app, which is an area Elixir/Erlang has room for improvement, as making some simple outside http requests isn’t nearly as dead simple, iirc.
- Some programmers don't like functional programming (I'm not one of them)
- Go has static typing and I find it really cuts away bugs
- Go is backed by giants and has the horse power to push forward regardless of "Github stars"
- Go is easy to compile and run on most/many platforms
- I find myself more able to understand third party code
As a web developer, would I use Go as opposed to Phoenix/Elixir? Yes, I am actually using it in production on a fairly big project [1]. I tried Phoenix and I found it "weird" for my liking. The authentication part of a web app was a real deal-braker for me = too complicated to implement (not bad, just too complicated).
I'm the type of guy that brainstorms (90% of my projects are always "close to completion" though) a lot of ideas and wants to go up and running really fast. I can't do that with Python/Elixir/Ruby without many tests written because I don't trust the code/myself all that much.
Where would I use Elixir/Phoenix:
- a chat/support app or anything that relies heavily on websockets
I'm not the parent poster, but I love both Elixir and Go and have both in production at work. My two cents:
Phoenix is a joy to work with, so I like Elixir for the full-stack crud apps that you might otherwise do in Rails. The server-rendered HTML experience is every bit as painless as it is in Rails (this is not a selling point for Go), you get very good tooling for free, Elixir is fun to write, depending on the application the channels/websocket stuff can be a huge lift, etc.
I like Go for stuff that doesn't have a web front end - APIs, CLI tools, background services that need to be fast, etc. In my personal experience based on the small number of Elixir & Go apps I've written (only a few of each), Go gets the edge for performance and server cost. It isn't as quick to prototype in Go as it is in Elixir, but the type system pays off over the long haul.
Again just my quick take - both are really great IMO.
Earnest question: isn't Elixir dynamically typed? If so, how is Go's type system worse? You can always drop down to `interface{}` (the dynamic type) if you like, after all.
> And, while go’s channels are cool, they don’t seem nearly as powerful as elixirs actor model/OTP — at least for this example.
I haven't used Elixir, but I suspect this is true. Elixir/Erlang are probably the only two languages that probably have a better concurrency story than Go; however, there are other facets (tooling, deployment story, learning curve, etc) to consider in choosing a programming language, and I think Go is a really strong language on balance.
> Earnest question: isn't Elixir dynamically typed? If so, how is Go's type system worse?
Elixir has built in support for type specifications and supports static analysis for (among other things) typechecking via dialyzer, a static analysis tool from the Erlang distribution for the BEAM VM.
Are these widely-used? When I tried kicking the tires on Elixir, it seemed like type annotations (specifications?) weren't used in practice, and they also seemed pretty clumsy (I didn't try hard, to be fair).
As another sibling comment said: they serve different niches. I'd always reach for Elixir/Phoenix for any web app, or even API (if it's a big app). Also anything that requires heavy concurrency -- web spiders, data collectors of many kinds, scatter/gather flows (or any multi-stage flows; Elixir makes those processes brain-dead easy to code) -- then Erlang/Elixir are a no-brainer. People keep wrongfully underestimating them.
But if I am to write a CLI app or a very heavy-duty network daemon, Go is IMO hands down unbeaten and the best possible choice. Also anything that requires serious number crunching.
> Elixir and Go are not mutually exclusive though.
To be clear, I claimed nothing to the contrary. :) I only argued that concurrency isn't the only criteria in choosing a programming language for a particular project.
I wrote a small supervisord ripoff in go just after its launch, it was at the same time frustrating and enjoyable. I will have a week off in less than a month, do you think i should build a similar elixir app just to learn the language? Or do you have any idea of a better well known programm to build to "learn" the language in a week?
Don't want to be that guy, but imo one week is not enough to even "learn" Elixir. To be honest it depends on your previous experience, of course. But the problems is, that there a lot of books, but there are not that much code examples in the world. There are some Phoenix open sourced projects, but I didn't see that much OTP in them.
Not OP, but I've been interested in both technologies for a while. Elixir with Phoenix feels like modern RoR, so it's probably best suited for startups that want to build their products fast and want to scale easily and cheaper.
IMO Go is perfect for big companies and somewhat middle companies where they have some heavy traffic that needs to be addressed. I guess Golang is also easier to start with and craft something very fast as opposed to Elixir. (You can check multiple topics on elixirforum.com where people ask why their first-iteration code is slower than that in ruby/python.)
I can be wrong, but I haven't found any golang opinioned-matured web framework, because most of the community is okay with building from the ground up. This may suggest that golang would be preferable in complex/enterprise systems?
I'd choose Elixir for something that has to be done fast and be reliable and open for a lot of modifications that can be introduced without sweating.
My point of view is based on building some simple product in Elixir and doing research. Also, a previous company I worked for had Golang and Ruby stack.
I find the whole library/framework existing functionality thing to be vastly overrated. There’s a certain minimum you need, but once you hit it, OK.
For me, what I liked about Ruby when I played with it years ago was how expressive and concise the language was. There is joy in NOT having to read through a mountain of drivel when you go to dive in and maintain a feature.
I realize I am in a minority, though. Most of the industry seems to insist that we are doomed, DOOOOMED (!!!), without static types, no matter what the cost to have them. For me, mutable data seems like a much bigger evil and impediment to comprehension than dynamic types. Of course, to have something that had types and type inference, but also allowed dynamic types with minimum ceremony would be nice. Maybe someday (but until Typescript groks partial function application, and maybe type inference of object literals, that’s not yet the answer)
Anyway, back to work on a big fugly mountain o Java code...
I can't find the quoted part in the article. Anyway, we met online a year after GitLab started, so by the time we met it was already decided to many it in Ruby.
Sorry, I paraphrased as part of forming a TLDR - the actual article is much more loquacious
> Dmitriy Zaporozhets decided to build GitLab, he chose to do it with Ruby on Rails, despite working primarily in PHP at the time. GitHub, a source of inspiration for GitLab, was also based on Rails, making it a logical pick considering his interest in the framework.
By co-founders, I meant why GitHub chose RoR, not GitLab.
I was looking for a comment like this. I also assume the decision was influenced by GitHub which put RoR at it's high as well as what the original author ( Dmitriy ) decided to do so.
Anyway, why they stick to RoR these days is probably because they have invested too much into it ( same reason as of why FB is kinda stuck with PHP ).
This article doesn't make a lot of sense btw, since "they" ( hundreds+ people org ) did not choose anything as the reality is probably that one person ( Dmitriy Zaporozhets ) woke up one day and said "Hey let's see how far I can go with this."
Yes. I work for a company that used to build almost everything in Java and people are constantly asking why the hell we used Java for it and we're constantly apologizing and saying how quickly we're moving to a more modern solution.
Before this, I worked for a company that build almost everything in Java and we had to constantly explain why things were in Java and what we were doing to move things to a more modern solution.
But you don't read blog posts about those companies because they choose not to write them. The blog posts you see about the backend technologies are from companies who are proud to use those technologies and want to promote their use of that technology. The companies who use Java (mostly) are companies who aren't going to write blog posts about their backend technology choices.
I used to hate Java, but years of experience later, I would gladly inherit a well maintained/architected and modern Java codebase over anything written in Python or Ruby (even a well maintained one)
That, actually, is one of the the largest selling points of Java as a platform: when it's bad, it's not that bad, and even when it is, the tools to clean it up are better than anyone else's.
What exactly qualifies as a modern solution that Java(/jvm?) is disqualified?
Syntax, library eco-system, paradigm, type system, cruft? Is "modern solution" some function of blog post count? A social blade type score for how many early-20 somethings are using it?
Or is it going to be something "simplistic" & "clear" which will eventually inherit the cruft all other large languages do?
None of the people complaining are the developers (the developers like Java). They're all (enterprise) end users. The "modern" solution is something where the customers don't know it's Java, don't have to hear the words "tomcat" and don't bring to mind all the baggage associated with those names.
There's nothing wrong with Perl or PHP either, but plenty of end users have seriously negative associations with the technology and will blame every fault on the technology because it's had a rough history. All of those languages/ecosystems scream "dotcom" to enterprise users and they don't want to hear that they're paying $1.5m for a system that's built in what they consider to be legacy languages.
Java is the goto language in more conservative environments (e.g. insurance, banking, government) and I never had to justify using it there.
In small shops/startups it’s different. Hype is a real thing and running your backend on “25 year old tech” often does not attract the right kind of people you need to have in this space ;^).
That being said, I’ve been shipping stable and performant backends on the JVM for over 15 years and I could not be happier with the state of Java in 2019.
The ecosystem is amazing. Tooling, too. Talent and jobs are available everywhere.
Also, there is an active effort to modernise Javas syntax and I think it’s going into the right direction.
I don’t have the enthusiasm for Java I did 20 years ago (the alternate for employment in Sacramento was largely C++ back then, mind you), but I think what you said is accurate.
Personally, I want to see Java retire, but downvoting people who are pointing out legitimate benefits, even if there are counter points to be made, seems rude.
Consider Groovy if you're interested in something Python or Ruby-like but with access to the JVM and its ecosystem. It's basically the best of of both worlds with almost none of the downsides.
Not at all, with Hibernate, Spring, Groovy, building web applications is much faster and more maintainable than other alternatives.
I am a huge fan of the Grails framework, they do a lot of things right. As a developer I can focus on creating business value as most technical challenges are easily solved with Grails. Grails is performant and memory efficient. With Grails 4 which will be released later this year, memory usage will decrease significantly more.
I'm not in that industry, but in general yes, even other JVM languages, since one of the reasons is that using a common language makes it simpler to move people between projects. If there is a sole kotlin developer or small group of kotlin devs and they leave it's harder to replace. Also integrating new members coming frommother teams is harder. The more architectures, libraries, coding styles, ... are standardized the higher are the chances that others can take over which is beneficial even if individual productivity might be lower.
I agree, PHP is more than viable to build companies, and has proved it again and again. As did Ruby :) The fact that PHP isn't my favorite language is really besides the point.
Those vocal Ruby/Elixir/Go/Node enthusaists who crap all over other battle tested stacks are very immature individuals.
I really enjoy Gitlab's UI/UX, but I wish it were easy to manage a self-hosted Gitlab presence. The architecture diagrams[1] frankly read as supporting justification to go with the hosted solution.
(gitlab employee here) what is it you find particularly painful? It's definitely not intended to make it seem like people should go with hosted, so any feedback you have would be really appreciated
This really strangely sounds like an advertisement for Ruby on Rails. It doesn't even give any specific advantages of RoR.
> If you look at GitLab, it has an enormous amount of functionality. Software development is very complex and to help with that, we need a lot of functionality and Ruby on Rails is a way to do it.
What I really liked about Ruby on Rails when I took an online course on it were the schema.rb files and `rake db:migrate` command. I don't know if there's an analog in Python, but honestly I think clean, highly structured, maintainable data is way more important than the backend you use. Having the ability to quickly iterate your SQL schemas and roll them back as necessary is essential to shipping high quality features with fast changing requirements.
Just wait til you actually work on some production code... For the most part you don't actually want to roll back schemas as you would lose data. And iterating on SQL schemas in a live app involves all kinds of tricky edge cases and backfills, knowing when to make your changes in multiple steps, being careful not to take down the whole thing because you didn't realize a certain change required a full table lock or a certain index would take so long to create, etc.
As is so often the case in Rails, it's set up to be nice and simple for a hello world example but little more. It doesn't actually make things as simple as they seem at first, and you're on your own to figure out which of its niceties are actually helpful and which are dangerous to use that you need to build your own workarounds for.
> As is so often the case in Rails, it's set up to be nice and simple for a hello world example but little more.
This is just wrong. Rails works very well for 90% of the situations. When it stops working that’s great news:
You’ve won!
You’re Twitter, Facebook or the next big thing. You’ll find talent and money to replace your rails app.
I'm having trouble understanding how one could run into a bottleneck only after you reach Facebook or Google or levels. Surely if you have performance issues when you are running on 10,000 machines, you would also have a bottleneck when you start to outgrow your single machine.
Why would you need more than a single machine to serve a request? You need multiple machines to serve many requests concurrently.
> For the most part you don't actually want to roll back schemas as you would lose data
Can you name a framework where you roll back schema changes and don't lose data?
> being careful not to take down the whole thing
You still need this caution if you don't use rails
> a certain change required a full table lock or a certain index would take so long to create, etc.
I feel like you're just describing working with a relational database in a production setting. This isn't rails specific
> Rails, it's set up to be nice and simple for a hello world example
Sure. I'm also pretty sure it's used in production by some great companies whose applications/APIs are a pleasure to use - SendGrid, Github, Stripe, and last time I checked Hulu to name just a few.
Just because it's not the framework of choice for the majority of companies doesn't make it incapable of being used at scale.
Or you inherit a DB that’s a complete disaster scheme wise and all the nice assumptions go out the window.
I’ve mostly found that migrations work best as a structure way to just run normal SQL and know a) what ran b) when.
For that they are handy.
I’ve even considered how to structure a stand alone migration running tool with a nice API since the good ones for each language tend to be fairly different.
It annoys me that the tooling around RDBMS in 2019 is still so shit.
Prime example, try to find a halfway reasonable way to debug a badly written MySQL sproc you inherited.
I’ve used Flywheel (https://flywaydb.org/) for this exact problem on personal projects before and been fairly happy with it. It’s intended for use in JVM-based projects, but ships with a CLI that gets you a long way.
Sqitch by David Wheeler is a great way to manage database schemas. I haven’t uses it in production, because I mostly use Rails and haven’t felt enough pain to justify the switch.
https://sqitch.org
Migrations are rad! Django (the Python equivalent of Rails) has had built-in migrations for several years now: https://docs.djangoproject.com/en/2.1/topics/migrations/
Granted my rails experience is minimal at best, but I really favor Django's migrations. They're pretty fantastic.
And long before that, it had South: https://south.readthedocs.io/en/latest/about.html
Also laravel and CodeIgniter for PHP.
I agree, and most other commenters still miss the point about what makes Rails so great :
it's not the technical part (you can point slowness, quirks in how the language/framework is used) but the human and business part. It works. It makes adapting to change easy. Yes it's a monolith, yes it encourages fat models, etc. But it works so damn well.
`rake db:migrate` is not so great as a feature (other frameworks in other languages have it), the greatness comes from how well it's integrated with the Rails workflow.
> other frameworks in other languages have it.
Yep, Laravel (PHP) lifted it en masse (so much so that when I had to get up to speed with laravel years ago I used the rails docs to fill in the blanks) and Symfony with Doctrine is in some ways better.
Every time I try to write some "super simple web app" that I think is much too small for Rails I always end up in spots like this: migrations, then asset fingerprinting, then some quick sanity tests, oh, now I need this other thing and I've cobbled together a creaky messed up version of Rails.
Python SQLAlchemy/Alembic and Django has db/schema migrations.
.NET has db/schema migrations in Entity Framework.
Node/javascript has sequelize/umzug, node-db-migrate and others for db/schema migrations.
Migrations are pretty common now for ORMs, or any code first schemas, but are definitely a killer feature and needed with ORMs to see what is being changed/iterated on.
Another option is Sqitch. It's database and framework agnostic.
https://sqitch.org/
Postgres Tutorial: https://metacpan.org/pod/sqitchtutorial
Came to this thread to suggest squitch. Glad it's mentioned here. I really enjoy it's three generic concepts - deploy, verify, revert - and not having to tie my migrations to any particular language or ORM. In additon, it's supported on every operating system I've used with it and has got a docker image in case that's not good enough.
Analog in python: https://docs.djangoproject.com/en/2.2/topics/migrations/
I suggest checking out https://flywaydb.org/ It doesn't have the ORM-ness mapping rails migrate does, but it makes it really simple to organize sql scripts to move/update schema configs.
I sometimes suspect a folder full of sql scripts would be better than black box migrations (which are a folder full of sql scripts or similar anyway).
Migrations are great, until they aren't.
Sometimes if you actually manually do the thing you know how it works better and can adjust. I suppose the drawback to that is everyone else doesn't.
Another option is a schema management tool that doesn't rely on migrations at all. I'm the author of one, Skeema [1], for MySQL/MariaDB. Others include migra [2] for Postgres, and sqldef [3] for MySQL or Postgres.
These all use a declarative approach [4], where the user just specifies the desired new state, by adding or changing the set of CREATE statements. The tool knows how to run the correct DDL to reach that new state.
[1] https://github.com/skeema/skeema
[2] https://github.com/djrobstep/migra
[3] https://github.com/k0kubun/sqldef
[4] https://www.skeema.io/blog/2019/01/18/declarative/
How Interesting. Thanks!
Yeah I've thought the exact same thing before and I've actually tried both.
The clear difference is that migrations are easily reversible. Good migration libraries can also reverse data migrations.
A folder of SQL scripts was very refreshing, but no way could I use that system in a production environment. There's just too many edge cases to keep in your head.
Manually migrating has the issue of testability and hit by the bus. I don't believe every migration needs a roll back, sometimes the better strategy is restore from a snapshot/backup.
I personally tend to prefer migrate[1] as it doesn't require java.
[1]: https://github.com/golang-migrate/migrate
Java seems ideal as it will be completely cross platform and you can add / update the database drivers after the fact.
Migrate has a different binary for each platform and from what I can see, the support for each database is compiled in, so just to update a driver you are going to be maintaining that binary all over the place.
Migrate is awesome! My only issue: Since it uses bare SQL for the migrations, you have to do some lifting if you need to support multiple RDBMS with different DDLs. I have some regexes in my project to translate Postgres DDL into SQLite DDL for my test suite.
Why would you not test your code with the same RDBMS you will have in production? Especially if it’s something as easy to install as Postgres? It seems like begging for trouble...
If you're using an ORM, it can be an easy way to ensure that no vendor specific stuff sneaks in. Also, until recently it was difficult to run, e.g., SQL Server in Docker, so Postgres might be easier to test with. Agreed SQLite is a weird choice, but not all integration tests are robust enough to test characteristics of the underlying db, i.e. focus on business logic not performance.
I have several dozen tests that run in completely separate DBs. With SQLite, the test suite runs through in 1 second:
I doubt that you can setup and tear down several dozen Postgreses in that time.Flyway doesn't require Java. The CLI ships with a private JRE as well as drivers for most databases out of the box. Simply untar and run.
The activerecord-migrations gem allows you to use Rails migrations with other languages too—I’ve used it with node, clojure, and others where the community migration libs aren’t as good.
https://github.com/diesel-rs/diesel
This type checks all ORM operations, and type checks against the actual schema at compile time. It's pretty cool and made by one of the long-time developers of ActiveRecord.
"Ruby was optimized for the developer, not for running it in production," says Sid. "For the things that get hit a lot and have to be very performant or that, for example, have to wait very long on a system IO, we rewrite those in Go … We are still trying to make GitLab use less memory"
Honestly, I think that Go is beginning to be where Rails was few years ago, and lots of developer friends want to hop on the Go train because everybody is doing the same.
In the same time, I'm thinking about switching to Gitea or Gogs + Drone.io, because Gitlab takes just too.damn.much.memory ! Seriously, 8GB RAM to even just begin with ? (Because yes, 4GB RAM + 4GB Swap is not viable). Even my biggest website is not consuming as much.
So if I could suggest something, it would be a global rewrite in Go or something like that, to lower the requirements, not just one or two parts (excuse me, microservices ;)).
Just my 2 cents
GitLab is using a lot of memory for various reasons, all of the big ones (like adding multi-threading which I proposed 3 years ago https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 ) can be solved without a rewrite. I've failed to make this a priority within the company. We had people work on it for some time but the day to day of shipping features, keeping GitLab secure, and other tasks took over. I'll advocate for a dedicated performance team to solve this. Until that team is formed people like Stan are making steady progress https://news.ycombinator.com/item?id=18973499
Thanks, VERY much appreciated !
Or Elixir, or Rust, or Node. Having spent time with all of these options, Rails is still really really good for a lot of use cases. Go comes nowhere near Ruby's readability for me (but I like the lack of surprise).
Personally I'd love something typed, performant, and as readable as Ruby with a convention focused platform like Rails. Elixir + Phoenix is probably the closest I can find, but not a perfect fit. Maybe close enough though.
If we're talking memory usage, I don't think Node is necessarily a significant improvement over Ruby.
FWIW Elixir isn't necessarily lightweight. Memory will stay pretty flat (even during high workloads) but it's not lightweight.
> Go comes nowhere near Ruby's readability for me
I am not fluent in either, and I'm not looking to change that, but I have read code in both. I feel the exact opposite way, and I'm not trying to start a war or anything, but I was wondering if you'd be open to talking about what things in Go you find hard to read (and what things in Ruby you find very easy to read). Or is this about libraries (are Go libraries providing lower-level APIs than Ruby ones?)? Or have you read/written a lot more code in Ruby than Go?
I agree - Go has issues, but they're not related to readability. Perhaps if you include "familiarity with the standard interfaces" (like using io.Reader) which is different to other languages, and took a while for me to get used to.
Is there a benefit learning Elixir over Erlang? I've working a little bit with Erlang, and I've wondered if its worth the jump.
Completely! With convention and macros, it's a whole new language.
Crystal it is. Combined with the amber framework, porting the Ruby Code should be straightforward. Yes stuff isnt even 1.0 yet, but I would seriously bet on it right now.
I agree that memory requirements are too high, but I think there is a lot of room for improvement without a complete rewrite, which would be very costly. Also keep in mind that a standalone GitLab instance ships with all batteries included: PostgreSQL, Redis, etc., all of which add to the memory requirements. That being said, we are certainly looking at moving performance-critical functions into Go. See the GitLab Workhorse and Gitaly projects as examples.
There are two major ways to look at application memory usage: baseline and runtime usage. Most people pay attention to the first because that's what you see when you first deploy GitLab. However, runtime usage is just as important because a running instance could gobble up gigabytes of RAM.
Baseline memory: We've made some recent progress in reducing baseline memory usage (e.g. cutting 80-100 MB per Unicorn process in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21008). However, our Unicorn workers dominate most of the memory usage, and you can see more analysis of where our memory is going in https://gitlab.com/gitlab-org/gitlab-ce/issues/49702. https://brandur.org/ruby-memory is probably the best explanation I've seen why RAM usage in Unicorn processes often rises and doesn't come down. However, we can reduce baseline usage in a number of ways:
* Removing dependencies from the main application
* Reducing any unnecessary allocations at startup
* Moving to a multi-threaded application server (we've shipped Puma in experimental mode in https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/...)
* Improving Rails memory usage (e.g. ActiveRecord optimizations in https://github.com/rails/rails/pull/34711)
* Improving the Ruby interpreter (e.g. helping ship a compacting garbage collector, see https://gitlab.com/gitlab-org/gitlab-ce/issues/54555).
Runtime memory: Most of our runtime memory problems are often due to memory bloat or unoptimized code paths. For example, we put big dent in some of the most egregious background jobs over the last few months. For example, a change in our merge request processing in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22725... lowered 95% of our runtime usage by gigabytes. Switching to a faster XML processor in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23136 also dropped memory usage in another background job.
Obviously we're still far from where we should be, but we're making progress. If you or know anyone else who might be excited to help us, please let us know! https://about.gitlab.com/jobs/ Thanks for your feedback.
Very interesting, thanks! One idea I had was to push "plugin-ability", for example not everybody want to have the Gitlab Pages function, or some might want to completely replace Gitlab-CI by Drone or Jenkins, and all that could help lower the memory requirements. Or maybe I'm wrong?
Yes on Gogs + Drone.
I used to be RoR developer a while ago. Working with gitlab is a breeze because I can apply all the knowledge I have - by the virtue of being a RoR app i know how can i apply migrations, how to call interactive console, how to monitor and clear work queues, how to add middleware. Gitlab using RoR is a great win for /me/
No offense, but this is just a really weak PR fluff piece. The with only interesting thing is that they use Go for the hit access part.
Oh, and Ruby and multithreading don’t mix, who knew?
I like that if you preface your offending remarks with “no offense” you’re excused.
> Oh, and Ruby and multithreading don’t mix, who knew?
Modern Ruby has great support for threading. Rails has been threadsafe since 2008 and Ruby has a huge advantage over Python in JRuby: no GIL, JIT, parallel GC etc.
As an aside, when companies are doing these interview-style pieces are they actually interviewing the CEO? I always just assume they pull the quotes out of their ass.
I don't know about other companies, but given that gitlab's CEO is the type to be regularly active on HN (and will probably be reading this) it seems safe to assume that he would actively cooperate with such an article
Correct, this was an interview with me. We keep a list of topics that might be a CEO interview https://gitlab.com/gitlab-com/www-gitlab-com/issues?scope=al...
If I recall correctly https://gitlab.com/gitlab-com/www-gitlab-com/issues/2887 was part of a 1 hour interview that generated 4 articles https://gitlab.com/gitlab-com/www-gitlab-com/issues?scope=al... Great work by our content team.
I suspect that a PR person writes the piece with rough quotes, which the CEO then puts into their own words.
"Why GitLab are stuck with Ruby on Rails"
As listed in the article under 'Overcoming challenges' we do replace code in Go and Vue where needed. I do believe Rails is still the most productive framework out there.
See https://docs.gitlab.com/ee/development/architecture.html#com... for more information on what parts are Go.
I’ve utilized inline C quite a few times to replace sections of code. Specifically to do some of the server side computations for my applications:
e.g. https://hnprofile.com
The full system is built in rails and I query and generate information on a million or so accounts and tens of millions of comments. Haven’t really hit a bottleneck yet.
Serious question. Why do so many companies choose to rewrite in Go? I tried to like it, but it just felt so painful to use.
It seems that every few years a new backend language comes to the forefront and becomes a popular for greenfield projects or rewrites. First people moved from PHP to Ruby, then Node, and now Go.
Of course, Go's popularity is helped a great deal by Google using it, as well as the huge amount of devops software written in Go (docker, terraform, kubernetes). But at some point the hype for those will settle and they'll just become more tools. At the same time there'll be more and more legacy Go projects at various companies that won't be very exciting. Around about this time we'll probably see the next language start rising in popularity.
To me, the article reads like "We REALLY don't want to abandon Rails so we rewrite the hot paths to Go". I mean no offense; I just wasn't able to find good argumentation in it for sticking with Rails. To me, the article kind of makes the argument for Go.
"Developer productivity" is not a myth and it does exist. But Rails is very far from the only framework that gives you that.
IMO you should seriously evaluate making your web + API gateway in either Elixir or Go, outline a migration plan and get on with it.
I think a rewrite in Go would greatly increase our line-count.
I think Elixir is very interesting but Phoenix still has some way to go before the ecosystem matches that of Rails. Our Gemfile.lock https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile.... is more than 1000 lines!
Well, that complexity is yours to evaluate -- what I am saying is that you are seriously underestimating the Elixir community. And our forum is full of people making this same admission and saying they regret not reaching for Elixir earlier! :)
In the end, it's your call of course. But line-count doesn't say anything about a project's complexity. Go is quite verbose but with rigorous CI, tests, code reviews and linters, teams produce pretty hardcore and good software in Go, regularly.
I agree Go produces great software. But for the same amount of functionality it tends to require more lines than ruby. I tend to favor the more expressive language http://www.paulgraham.com/avg.html
Another thing is that there isn't a web framework like Rails in Go. Although I'm keeping an eye on go-micro and we plan to add that as a template soon.
Yeah, fully agreed on that. Go just doesn't have as productive a framework like Rails. That's why I only use it for very small websites or even smaller API gateways. Or CLIs. Or network daemons.
I am not disputing your choices. Just wanted to give you the quick and intuitive (and likely misinformed) immediate reaction that I had from the article.
Keep making GitLab awesome. <3
Thank you! <3
Line-count really isn't a great way to measure developer productivity either though...
It does measure bug count though.
>"Our mission is that everyone can contribute," he explains. "Because Ruby on Rails is really opinionated about which pieces go where, it's much easier for new developers to get into the codebase, because you know where people have put stuff. For example, in every kitchen you enter, you never know where the knives and plates are located. But with Ruby on Rails, you enter the kitchen and it's always in the same place, and we want to stick to that.
Sounds like they have no desire to switch away.
you win the "most hacker newsiest comment" on this thread award!
What would you prefer?
The advantages of typed languages are too great to not work in them.
The advantages of some particular insight into a business problem far outweigh the particulars of programming languages, for most problem domains.
If you’re in the business of developing enterprise apps (and that’s where the money for dev tools resides) then moving quickly without breaking things is critical in your formative years. Static typing goes a long way to facilitate that.
It’s by no means a panacea but it does eliminate an entire class of error and obviate a related class of unit testing.
We're coming dangerously close to holy war territory here. I don't think that assumption holds true in your average web app.
And yet large swaths of our profession choose to do so every day
Yes, otherwise we wouldn't be talking about it. That doesn't mean their parallel universe images who chose a statically typed equivalent, ceteris paribus, aren't better off.
"Lots of people do it so it must be fine," has to be the weakest form of argument I know. Which is funny, because lots of people use it. Hmm...
I took it as rrix2 were pointing out a tragedy :)
That’s a far better way of looking at it. I now regret not having seen it that way.
I guess you see what you want to see :(
fwiw I completely understand! I have also regretted what seems to be an instinct or habit to go for that same perspective. I’m not sure I can explain in a way that makes sense.
My biggest issue with GitLab is support.
After using it for our test pipelines for a year we've switched to GitLab CI completely with our deployments and right after we've started running into issues on our selfhosted instance where for about three weeks now we're fighting with stuck pipelines where runners won't pick up jobs until you manually restart them. We've been paying customers for GitLab Enterprise (now Starter) for years and the recurring theme is that our tickets go unanswered for basically ever.
We're having performance issues on AWS, trying to run on ECS with an EFS Filesystem underneath, have basically done everything to rule out the EFS as the issue and now because our tickets go unanswered migrating to a dedicated EC2 Instance to see if this makes things run faster...
From a product perspective we're starting to love GitLab, but from a technical & business pov it's getting increasingly painful to work with if you rely on it for too much.
I wonder if Ruby is the reason it's hard for them to run reliably as a self-hostable solution, but as I have 0 Ruby experience I wouldn't know.
Hi @Roritharr - Support Manager at GitLab here.
I'd like to follow up on this to see where we dropped the ball and how (or if) we can make things right. Feel free to email me at lyle[at]gitlab.com and I'll look into your ticket history and move things along.
For others, performance issues with EFS and GitLab have been frequent enough that we specifically call EFS out in our documentation: https://docs.gitlab.com/ee/administration/high_availability/...
This isn't to say that EFS doesn't have its place, it's just that git operations quickly exhaust burst credits and many of our users on EFS end up with difficult to diagnose performance problems.
This may or may not have anything to do with @Roritharr's problems, but it's worth noting!
Hi, mail is out, if for some reason this doesn't reach you:
Our Ticketnumber is 111794 for the pipeline issue and the other one is 104887 for the Performance Issue.
> Ruby was optimized for the developer, not for running it in production," says Sid. "For the things that get hit a lot and have to be very performant or that, for example, have to wait very long on a system IO, we rewrite those in Go
Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix. I wonder if they considered it.
> Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix. I wonder if they considered it.
The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community). Ecto is still going through some massive changes (ActiveRecord is comparatively stable). Personally I think that Elixr is an interesting language but it's not one I'd want to mess with in a production environment.
The big win for Go is that it compiles down to a single binary. Ruby you get a single point of entry (script with a shebang). But Elixr/Phoenix? You get a handful of bash (not even POSIX sh!) scripts and binaries and a whole VM to deploy. As a BSD user, I gave up on Elixr/Phoenix after trying to debug the nightmarish deployments that had been broken for months. I couldn't tell if it was an issue in the rat's nest of bash scripts or a VM bug. Sure, ruby-bcrypt is broken on FreeBSD too with a similar head-in-sand mentality from the bcrypt gem maintainer (which could make Rails deployments a non-starter) but that's easy to fix and has been fixed out-of-band. Elixr? Well there's one maintainer for the deployment tool and he's stopped responding to bug reports of any sort.
That said, I like Rails. A lot. But ruby is painfully slow and I've learned to push as much logic into the database as possible. So there's a compelling case to be made for an alternative. Unfortunately I've never had any other language give me that much trouble as Elixr has. Personally, I detest Go dependency and build management (and the Google involvement), but the simplicity of concurrency and deployment combined with the breadth of the standard library make a very compelling case for Go IMO. Hell, I would reach for Clojure before Elixr because at least then you're dealing with the comparatively mature Java VM.
Personally I've gone down the Rust road, but even then I'm not sure I'd want to deploy a Rust web app in production just yet (although I really do like Rocket).
> The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community)
What are you viewing as mature? It's a loaded word and many people use it with a different meaning in mind.
> Ecto is still going through some massive changes (ActiveRecord is comparatively stable)
As of the latest release of Ecto -- 3.0 -- the maintainers said they consider it mostly complete and said they will not do breaking API changes [0]; this part in particular:
"With the release of Ecto 3.0, I would like to announce that I finally consider Ecto to provide a stable API. This means no more new features, although we will continue providing bug fixes and updates. For everyone running Ecto in production, rest assured that Ecto will continue to be a well maintained project with the same production quality and polish that it has today."
So the first part of your statement is factually false.
For ActiveRecord being stable... subjective, I'll give you this much. Try and migrate a Rails 4.0 app to 5.x and come cry with me over a dozen beers. ;)
> Personally I think that Elixr is an interesting language but it's not one I'd want to mess with in a production environment.
Many people and organizations are "messing" with Elixir in production with great -- and increasing -- success.
Phoenix at the moment is one of the very few frameworks that delay your scalability problems much farther into the future than most me and many others have worked with. Phoenix can easily give you thousands of requests per second on a $5 DigitalOcean droplet. Rails and several C# and Java frameworks cannot.
I am not attacking you and I hope I don't sound that way -- but you seem to have a non-factually supported negative bias against Elixir. It gets more mature by the day and is quite capable of very serious work in pretty tough environments. Positive case studies spring into existence often.
[0] https://elixirforum.com/t/ecto-3-0-is-out-and-stable-api/173...
> but you seem to have a non-factually supported negative bias against Elixir.
If deployments are broken for months[1] with no fix in sight, what do you expect? I'm currently seeing zero requests per second with Elixr. If the sole maintainer of the sole deployment tool is too disengaged to reply to bug reports I don't care one way or another what sort of performance a product (or its fanbase) are claiming. If the product can't be deployed it's not going to scale. Period.
It's a bit silly to talk performance comparisons between Ruby and Elixr as the premise of this article was that Ruby is simply too slow. Are you going to have a harder time scaling Go or Rust than Elixr? I doubt it. I have no idea if you're going to have a harder time scaling Java than Erlang, but Java is popular enough in the enterprise space that finding people with that sort of experience isn't so difficult. The only time I've seen Erlang at scale was with Megacorp's Enterprise Chef deployment. There was easily tens of thousands of dollars in hardware there and the Chef server was still regularly brought to its knees with well less than a thousand total users (and well fewer than that at any given time).
1: https://github.com/bitwalker/distillery/issues/561
Open source maintainers burn out. It's a fact of life that's hardly specific to Elixir though, wouldn't you agree?
As for deployments, I've setup several of them in the last 2 months -- from scratch, and successfully. There's an initial learning curve that might be way too annoying for many. The deployment story is one of the weaker parts of Elixir -- I am not running away from that.
As for scaling, you might be mistaken. Erlang/Elixir can be scaled with almost zero effort up to 50 or so machines before you need to introduce special libraries or any extra tooling at all.
Of course, you can do the same with many other languages if you put Kubernetes or HAProxy in the picture. Point is, with Erlang/Elixir, it is 99% effortless up to a certain scale which most projects won't ever hit.
If you were talking about raw speed however, I can't argue that Erlang/Elixir are just a little faster than a very optimized JS (and still plenty faster than Python, Ruby or PHP). But nobody advocates Elixir for raw number crunching.
> Open source maintainers burn out. It's a fact of life that's hardly specific to Elixir though, wouldn't you agree?
Of course. How many languages have a single deployment story maintained by a single person though? That level of fragility is something I wouldn't put in production. Period. Not even on Linux.
And, yes, you could just compile the app in production (and watch the security team lose their shit). Or you can blow everything away for each deployment. Or you could use a tool that's simply less tedious to deploy (e.g. Rust, Go, Java, Clojure, ClojureScript, Javascript).
To put it another way, if deploying is a pain, scaling is a pain.
> To put it another way, if deploying is a pain, scaling is a pain.
I can't understand that argument. Would you please expand?
---
I agree it doesn't look very trustworthy that the only viable deployment option in Elixir is kind of stalled lately. Of course. What I am saying is, what we have at the moment works plenty well -- if you can get over the fact that enabling deployment in an Elixir app is needlessly complex.
As is said many times here in HN, judging an open-source project by its frequency and recency of commits is quite a flawed strategy.
> I can't understand that argument. Would you please expand?
See the Github issue linked (and the related issues). Distillery is known broken. Who cares if Elixr or Erlang scales really well if you can't even get it deployed? That Distillery is, for all intents and purposes, abandoned is secondary. It wasn't left in a usable state.
I agree it doesn't look well but you simply can't claim that Distillery is broken. The last stable version works just fine.
Interesting to see an outside take on the situation though. Thank you.
(EDIT: Also, in the issue it's pointed out that a newer Erlang OTP release fixes the problem.)
Uh, there's also a suggestion that setting NODE_NAME will fix the solution. Unfortunately the issue remains open because Distillery has been abandoned in a non-working (which, by definition, is broken) state.
I would compare Elixr to Go, Java (OpenJDK), Javascript (node) and Rust here. All have passive support for the BSDs, and yet all three have actively maintained native packages (rustup and/or ports tree). That neither the Distllery author nor the BSD users have managed to come up with a solution is quite telling — deployments on Elixir are nightmarishly complex. I'm most familiar with Rust, so in contrast if you look at the the BSD specific issues you'll find a very engaged userbase.
Deploying unmaintained software in production is sometimes a necessity with legacy stuff but is almost always a bad idea for new deployments. Elixir has plenty of passionate advocates but no good deployment or support stories. That's just a long-winded way of saying Elixir/Phoenix, unfortunately, aren't things I would be comfortable deploying in production (Linux or not) no matter how many compelling ideas they dangle in front of you. And, as has been pointed out, Elixr doesn't offer significant (if any performance benefits) over modern Ruby (and by extension Java, Go, or Rust).
vOv
Phoenix can easily give you thousands of requests per second on a $5 DigitalOcean droplet. Rails and several C# and Java frameworks cannot.
Phoenix doesn't hold a candle to anything JVM or Golang though: https://www.techempower.com/benchmarks/
That is undeniable. Java and Go are definitely faster in terms of raw performance.
The main value proposition of Erlang/Elixir is: a very acceptable performance combined with unparalleled concurrency primitives, plus resiliency and high availability. Not performance alone.
> Phoenix can easily give you thousands of requests per second on a $5 DigitalOcean droplet. Rails and several C# and Java frameworks cannot.
Elixir + Phoenix is no faster than CRuby + Sequel/Roda today.
When Elixir was started the common Ruby version was 1.8, a tree walking interpreter with no parallelism. Today's Ruby is nothing like that.
Could be. I abandoned Rails 2-3 years ago and haven't looked back since. Even then migrating a project to Ruby 2.3 was a huge pain due to the immutable strings feature. It was one of the things that made me throw my hands in the air.
But I almost haven't seen a Rails project using Sequel for 6 years of working with it. 99% of the projects use ActiveRecord.
> But ruby is painfully slow and I've learned to push as much logic into the database as possible.
Since you said you like Rails, have you tried using Ruby with Sequel instead of AR? AR is incredibly convenient but performance isn't a strong point.
> Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix.
Elixir does not have the language patterns of Ruby, though it has a deceptive visual similarity.
We are watching Elixir closely ever since visiting Krakow, Poland for the Railsberry conference in 2013. This is also where my co-founder Dmitriy and I first met in real life.
As for the reasoning please see https://news.ycombinator.com/item?id=18973348
> language patterns of Ruby but want better performance for concurrent processes
But then take on the disadvantages of acquiring talent and less adopted programming paradigms (e.g. functional programming)? Elixir/Phoenix is awesome, but it's not a panacea for everything.
Language/framework choices aren't done in a vacuum.
We've had good success teaching team members with no FP or Elixir experience and training them to be productive Elixir developers. It takes investment, but so does having an employee.
quite a big gap between Elixir & Go though for most use cases.
Would you be able to give an example or two where you would reach for go vs elixir and vice-versa?
I’ve tinkered with Go, and while it was fairly enjoyable to work with on the small scale, but the lack of generics and constant err != nil checks, and Go 2 on the horizon, I decided to hold off on building anything non-trivial with it.
I’m currently rewriting a Rails app into smaller elixir components, the Rails app is mostly consists of several potentially long running processes that gathers large amounts of data from various sources, does some light transformations, and then combines it and outputs it in various forms. Elixir has been immensely more pleasurable to write in, as OTP, along with things like GenStage and Flow, seem like a perfect fit for this task. And, while go’s channels are cool, they don’t seem nearly as powerful as elixirs actor model/OTP — at least for this example.
The one advantage of Go I can immediately think of is using it for some networking heavy app, which is an area Elixir/Erlang has room for improvement, as making some simple outside http requests isn’t nearly as dead simple, iirc.
Sure, here's a few, personal opinions:
- Some programmers don't like functional programming (I'm not one of them)
- Go has static typing and I find it really cuts away bugs
- Go is backed by giants and has the horse power to push forward regardless of "Github stars"
- Go is easy to compile and run on most/many platforms
- I find myself more able to understand third party code
As a web developer, would I use Go as opposed to Phoenix/Elixir? Yes, I am actually using it in production on a fairly big project [1]. I tried Phoenix and I found it "weird" for my liking. The authentication part of a web app was a real deal-braker for me = too complicated to implement (not bad, just too complicated).
I'm the type of guy that brainstorms (90% of my projects are always "close to completion" though) a lot of ideas and wants to go up and running really fast. I can't do that with Python/Elixir/Ruby without many tests written because I don't trust the code/myself all that much.
Where would I use Elixir/Phoenix:
- a chat/support app or anything that relies heavily on websockets
- real-time apps (related to first point)
- apps that rely heavily on distributed tasks
[1] https://typely.com
I'm not the parent poster, but I love both Elixir and Go and have both in production at work. My two cents:
Phoenix is a joy to work with, so I like Elixir for the full-stack crud apps that you might otherwise do in Rails. The server-rendered HTML experience is every bit as painless as it is in Rails (this is not a selling point for Go), you get very good tooling for free, Elixir is fun to write, depending on the application the channels/websocket stuff can be a huge lift, etc.
I like Go for stuff that doesn't have a web front end - APIs, CLI tools, background services that need to be fast, etc. In my personal experience based on the small number of Elixir & Go apps I've written (only a few of each), Go gets the edge for performance and server cost. It isn't as quick to prototype in Go as it is in Elixir, but the type system pays off over the long haul.
Again just my quick take - both are really great IMO.
> the lack of generics
Earnest question: isn't Elixir dynamically typed? If so, how is Go's type system worse? You can always drop down to `interface{}` (the dynamic type) if you like, after all.
> And, while go’s channels are cool, they don’t seem nearly as powerful as elixirs actor model/OTP — at least for this example.
I haven't used Elixir, but I suspect this is true. Elixir/Erlang are probably the only two languages that probably have a better concurrency story than Go; however, there are other facets (tooling, deployment story, learning curve, etc) to consider in choosing a programming language, and I think Go is a really strong language on balance.
> Earnest question: isn't Elixir dynamically typed? If so, how is Go's type system worse?
Elixir has built in support for type specifications and supports static analysis for (among other things) typechecking via dialyzer, a static analysis tool from the Erlang distribution for the BEAM VM.
Are these widely-used? When I tried kicking the tires on Elixir, it seemed like type annotations (specifications?) weren't used in practice, and they also seemed pretty clumsy (I didn't try hard, to be fair).
Elixir and Go are not mutually exclusive though.
As another sibling comment said: they serve different niches. I'd always reach for Elixir/Phoenix for any web app, or even API (if it's a big app). Also anything that requires heavy concurrency -- web spiders, data collectors of many kinds, scatter/gather flows (or any multi-stage flows; Elixir makes those processes brain-dead easy to code) -- then Erlang/Elixir are a no-brainer. People keep wrongfully underestimating them.
But if I am to write a CLI app or a very heavy-duty network daemon, Go is IMO hands down unbeaten and the best possible choice. Also anything that requires serious number crunching.
> Elixir and Go are not mutually exclusive though.
To be clear, I claimed nothing to the contrary. :) I only argued that concurrency isn't the only criteria in choosing a programming language for a particular project.
True. I mostly wrote my reply to help future readers.
Sorry, didn't mean to leave you with the impression that you misworded your comment! :)
I wrote a small supervisord ripoff in go just after its launch, it was at the same time frustrating and enjoyable. I will have a week off in less than a month, do you think i should build a similar elixir app just to learn the language? Or do you have any idea of a better well known programm to build to "learn" the language in a week?
Don't want to be that guy, but imo one week is not enough to even "learn" Elixir. To be honest it depends on your previous experience, of course. But the problems is, that there a lot of books, but there are not that much code examples in the world. There are some Phoenix open sourced projects, but I didn't see that much OTP in them.
I don't disagree, but Im curious of the ones you're referring to
Not OP, but I've been interested in both technologies for a while. Elixir with Phoenix feels like modern RoR, so it's probably best suited for startups that want to build their products fast and want to scale easily and cheaper.
IMO Go is perfect for big companies and somewhat middle companies where they have some heavy traffic that needs to be addressed. I guess Golang is also easier to start with and craft something very fast as opposed to Elixir. (You can check multiple topics on elixirforum.com where people ask why their first-iteration code is slower than that in ruby/python.)
I can be wrong, but I haven't found any golang opinioned-matured web framework, because most of the community is okay with building from the ground up. This may suggest that golang would be preferable in complex/enterprise systems?
I'd choose Elixir for something that has to be done fast and be reliable and open for a lot of modifications that can be introduced without sweating.
My point of view is based on building some simple product in Elixir and doing research. Also, a previous company I worked for had Golang and Ruby stack.
I find the whole library/framework existing functionality thing to be vastly overrated. There’s a certain minimum you need, but once you hit it, OK.
For me, what I liked about Ruby when I played with it years ago was how expressive and concise the language was. There is joy in NOT having to read through a mountain of drivel when you go to dive in and maintain a feature.
I realize I am in a minority, though. Most of the industry seems to insist that we are doomed, DOOOOMED (!!!), without static types, no matter what the cost to have them. For me, mutable data seems like a much bigger evil and impediment to comprehension than dynamic types. Of course, to have something that had types and type inference, but also allowed dynamic types with minimum ceremony would be nice. Maybe someday (but until Typescript groks partial function application, and maybe type inference of object literals, that’s not yet the answer)
Anyway, back to work on a big fugly mountain o Java code...
https://kotlinlang.org/
> Because GitHub did.
Which was because two of the co-founders met at a Ruby meetup.
I can't find the quoted part in the article. Anyway, we met online a year after GitLab started, so by the time we met it was already decided to many it in Ruby.
Sorry, I paraphrased as part of forming a TLDR - the actual article is much more loquacious
> Dmitriy Zaporozhets decided to build GitLab, he chose to do it with Ruby on Rails, despite working primarily in PHP at the time. GitHub, a source of inspiration for GitLab, was also based on Rails, making it a logical pick considering his interest in the framework.
By co-founders, I meant why GitHub chose RoR, not GitLab.
Ah, thanks for explaining.
I was looking for a comment like this. I also assume the decision was influenced by GitHub which put RoR at it's high as well as what the original author ( Dmitriy ) decided to do so.
Anyway, why they stick to RoR these days is probably because they have invested too much into it ( same reason as of why FB is kinda stuck with PHP ).
This article doesn't make a lot of sense btw, since "they" ( hundreds+ people org ) did not choose anything as the reality is probably that one person ( Dmitriy Zaporozhets ) woke up one day and said "Hey let's see how far I can go with this."
Does anyone ever have to justify using Java for their backend?
Yes. I work for a company that used to build almost everything in Java and people are constantly asking why the hell we used Java for it and we're constantly apologizing and saying how quickly we're moving to a more modern solution.
Before this, I worked for a company that build almost everything in Java and we had to constantly explain why things were in Java and what we were doing to move things to a more modern solution.
But you don't read blog posts about those companies because they choose not to write them. The blog posts you see about the backend technologies are from companies who are proud to use those technologies and want to promote their use of that technology. The companies who use Java (mostly) are companies who aren't going to write blog posts about their backend technology choices.
I really enjoy modern java. Its extremely performant and the ecosystem is amazing.
I used to hate Java, but years of experience later, I would gladly inherit a well maintained/architected and modern Java codebase over anything written in Python or Ruby (even a well maintained one)
So the only thing you would trade ruby or python for is something that doesn't exist.
Oh but it does. And even when it’s not great, it’s usually a less horrendous task to refactor into something better.
That, actually, is one of the the largest selling points of Java as a platform: when it's bad, it's not that bad, and even when it is, the tools to clean it up are better than anyone else's.
> we're moving to a more modern solution
What exactly qualifies as a modern solution that Java(/jvm?) is disqualified?
Syntax, library eco-system, paradigm, type system, cruft? Is "modern solution" some function of blog post count? A social blade type score for how many early-20 somethings are using it?
Or is it going to be something "simplistic" & "clear" which will eventually inherit the cruft all other large languages do?
None of the people complaining are the developers (the developers like Java). They're all (enterprise) end users. The "modern" solution is something where the customers don't know it's Java, don't have to hear the words "tomcat" and don't bring to mind all the baggage associated with those names.
There's nothing wrong with Perl or PHP either, but plenty of end users have seriously negative associations with the technology and will blame every fault on the technology because it's had a rough history. All of those languages/ecosystems scream "dotcom" to enterprise users and they don't want to hear that they're paying $1.5m for a system that's built in what they consider to be legacy languages.
Were the companies you were working for agencies?
> that's built in what they consider to be legacy languages
Who's the software company in this situation - you or them or both?
What's the modern solution which they expect you to be on? Go?
What characteristics does it have?
A solution could just as easily be packaged for them in such a way that they just have to run "java -jar someuberjar.jar"
It depends on the project.
Java is the goto language in more conservative environments (e.g. insurance, banking, government) and I never had to justify using it there.
In small shops/startups it’s different. Hype is a real thing and running your backend on “25 year old tech” often does not attract the right kind of people you need to have in this space ;^).
That being said, I’ve been shipping stable and performant backends on the JVM for over 15 years and I could not be happier with the state of Java in 2019.
The ecosystem is amazing. Tooling, too. Talent and jobs are available everywhere.
Also, there is an active effort to modernise Javas syntax and I think it’s going into the right direction.
I don’t understand why you got voted down.
I don’t have the enthusiasm for Java I did 20 years ago (the alternate for employment in Sacramento was largely C++ back then, mind you), but I think what you said is accurate.
Personally, I want to see Java retire, but downvoting people who are pointing out legitimate benefits, even if there are counter points to be made, seems rude.
It's nitpicky, but Java is just so fucking ugly and verbose. Does Kotlin extend beyond the Android ecosystem? I'd totally consider that if the case.
Kotlin runs on the standard JVM, not just android.
Consider Groovy if you're interested in something Python or Ruby-like but with access to the JVM and its ecosystem. It's basically the best of of both worlds with almost none of the downsides.
Not at all, with Hibernate, Spring, Groovy, building web applications is much faster and more maintainable than other alternatives.
I am a huge fan of the Grails framework, they do a lot of things right. As a developer I can focus on creating business value as most technical challenges are easily solved with Grails. Grails is performant and memory efficient. With Grails 4 which will be released later this year, memory usage will decrease significantly more.
IMO yeah. I can't stand Java and for someone to sell me on building any of my backend in Java it'd have to be one hell of a compelling argument.
What is your preferred language for backend?
mostly in the industry (finance) I work Java is the default. You need to justify and seek approvals for using anything else.
even things like scala or kotlin?
I'm not in that industry, but in general yes, even other JVM languages, since one of the reasons is that using a common language makes it simpler to move people between projects. If there is a sole kotlin developer or small group of kotlin devs and they leave it's harder to replace. Also integrating new members coming frommother teams is harder. The more architectures, libraries, coding styles, ... are standardized the higher are the chances that others can take over which is beneficial even if individual productivity might be lower.
AFAIK, most of AWS is built on top of the JVM, including massive services like S3 or DynamoDB.
Seems to be working well enough for them.
Haters gonna hate. Shopify, Stripe, Github, Gitlab, AirBNB, Fiverr, Bloomberg, Hulu, Kickstarter, Deliveroo, Zendesk, New Relic, etc etc etc.
How many more companies does it take to prove the point that Ruby/Rails is a viable option to base a company on?
Same with PHP and its frameworks (lots of haters comes from RoR side, isn't it?) So let's leave this aside :)
I agree, PHP is more than viable to build companies, and has proved it again and again. As did Ruby :) The fact that PHP isn't my favorite language is really besides the point. Those vocal Ruby/Elixir/Go/Node enthusaists who crap all over other battle tested stacks are very immature individuals.
I really enjoy Gitlab's UI/UX, but I wish it were easy to manage a self-hosted Gitlab presence. The architecture diagrams[1] frankly read as supporting justification to go with the hosted solution.
[1] https://docs.gitlab.com/ee/development/architecture.html#com...
It's fairly easy to host in my opinion.
Either you use the omnibus installer for a single server, or the helm chart for a distributed kubernetes install.
(gitlab employee here) what is it you find particularly painful? It's definitely not intended to make it seem like people should go with hosted, so any feedback you have would be really appreciated
Because Rails was all the hype in 2011?
i just assumed it was becasue "we didnt know better"
because it was the "the thing" at that time, just admit it.
It's amusing, that you can substitute every reference from Ruby to Python and Rails to Django and article would still make sense.
Except for the part about running in production. Seems like Python is a bit ahead there.
This really strangely sounds like an advertisement for Ruby on Rails. It doesn't even give any specific advantages of RoR.
> If you look at GitLab, it has an enormous amount of functionality. Software development is very complex and to help with that, we need a lot of functionality and Ruby on Rails is a way to do it.
You could say this about almost any framework.