Why We Chose Rails to Build Gitlab
about.gitlab.com
about.gitlab.com
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.
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.
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
$ 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
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.
.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.
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.
Postgres Tutorial: https://metacpan.org/pod/sqitchtutorial
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.
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’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.
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.
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.
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
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?
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.
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.
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.
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.
"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 guess you see what you want to see :(
It’s by no means a panacea but it does eliminate an entire class of error and obviate a related class of unit testing.
Sounds like they have no desire to switch away.
See https://docs.gitlab.com/ee/development/architecture.html#com... for more information on what parts are Go.
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.
"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 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!
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.
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.
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
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.
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.
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!
Our Ticketnumber is 111794 for the pipeline issue and the other one is 104887 for the Performance Issue.
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.
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’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
- real-time apps (related to first point)
- apps that rely heavily on distributed tasks
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.
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.
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.
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.
Sorry, didn't mean to leave you with the impression that you misworded your comment! :)
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.
Elixir does not have the language patterns of Ruby, though it has a deceptive visual similarity.
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.
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).
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...
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).
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.
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.
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.
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.
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.)
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 doesn't hold a candle to anything JVM or Golang though: https://www.techempower.com/benchmarks/
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.
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.
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 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.
As for the reasoning please see https://news.ycombinator.com/item?id=18973348
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...
Which was because two of the co-founders met at a Ruby meetup.
> 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.
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."
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.
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?
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.
> 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"
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.
Seems to be working well enough for them.
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.
How many more companies does it take to prove the point that Ruby/Rails is a viable option to base a company on?
[1] https://docs.gitlab.com/ee/development/architecture.html#com...
Either you use the omnibus installer for a single server, or the helm chart for a distributed kubernetes install.
Except for the part about running in production. Seems like Python is a bit ahead there.
> 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.