> Dependency hell is everywhere.

Excuse me, but as a long time Python user I have to disagree. I started using Rust two years ago and Rust’s dependency managment is easily the best thing I ever saw (keep in mind that I didn’t see everything, so there is a chance there are better things out there).

The project-/dependency-manager Cargo¹ is more “pythonic” than anything Python ever came up with and where others mumbled ”dependency hell is everywhere” the Rust people seem to have thought something like: ”there must be a way to do this properly”.

The whole thing gives me hope for Python, but angers me everytime I start a new python project. Poetry is good, but there should be an official way to do this.

It saddens me to see, that some people seem to just have given up on dependency managment alltogether and declared it unsolvable (which it is not, and probably never has been).

¹: https://doc.rust-lang.org/cargo/index.html

There's a pattern to this. The later the dependency manager was created, the better it is. This is a hard problem space where each new language got to use the lessons learned on the earlier ones.

Cargo, though, has a silver bullet. If it can't find a solution to determine a single version for a package, it simply includes more than one version in the object code. That would take a lot of work to duplicate in Python.

Python has had multi-version installation of libraries for a long time: https://packaging.python.org/guides/multi-version-installs/

Unfortunately, pip came along and took over, despite lacking support for that. It would have been nice if a better packaging tool had replaced easy_install, but alas.

That only helps when installing multiple versions at the same time, it doesn't help with using multiple versions in the same application.

Yeah, and the compiler will also report errors if different modules use different versions of the same package.

  - module A uses v1 and uses trait v1.A 
  - module B uses v2 and uses trait v2.A
  - will be reported as "A does not implement trait A"

It's actually quite discomforting for newcomers.

They definitly gave this a thought while designing the library system (”crates”) for the language. I am not sure if it is feasible to retrofit such a solution to something like python.. Python 4 maybe?

Rust's cargo, JS's yarn and the grand daddy of them all Ruby's bundler address all these issues. Even newer versions of Gradle support a workflow where you specify the versions you know you want and just on everything else, including transitive dependencies, down.

Go's new system addresses them all too.

This is the other frustrating thing: there is this stockholm syndrome effect, because people are so used to dependency management being horrible, they think there are just no good dependency management systems, and they give up.

What system is this? Isn't the built in package system still just pulling from github URL's?

No, there's a module system now: https://blog.golang.org/using-go-modules

GitHub is still the host for many of them, but there are Modules, so you get proper versioning and all that even when the place you end up getting them from is GitHub.

Huh, nice to hear, I was waiting for this to happen but apparently missed it.

Yeah.. not sure why the love for Ruby faded in startup-world

I think ruby is alive and well for a lot of startups. I do think it is being squeezed on three sides though.

* From javascript. If you have a app like front end, you are going to use js. Why not have the whole stack be js and have your developers use only one language.

* From python for anything web + data science. Again, why not have your whole stack be in one language?

* From lack of hype. Rails is still evolving, but a lot of packages are not seeing releases (I have used packages 3-4 years old). This indicates to me that the energy isn't there in the community the way it used to be. I have seen the consultants who are always on the bleeding edge move on to elixir.

That said I have seen plenty of startups using ruby (really rails) and staffing when I hired for ruby wasn't an issue.

I do help run a local ruby meetup and attendance is good but not exceptional (15-40 people every month). So that may skew my viewpoint.

"From JavaScript" also includes another side: When your frontend is in JS, your backend can be a simple REST API. And building a REST API requires much less framework than building a server-side-rendering webapp does, so it's tempting to use Go or Rust or whatever you like.

You’ll need (probably) at least: -Database connection -An ORM -Middleware against attacks / rate limiting -Caching -Jobs / workers -A rendering engine for email and maybe pdf -Some sort of admin/backend -Logging -Validation

I’ve written an API once from scratch. Actually twice. First time in Modena, because it was all the hype, but it was arcane. Then Sinatra, where I ended up creating all of the above. Rails is excellent for APIs.

Rust is nice, but I’m not sure if I’d like it for all of an API. I don’t like go. Crystal seems great, because it’s typed and it’s also super fast.

Have you looked at Graphiti? Haven't had a chance to use it but it looks great for creating APIs in rails:

https://www.graphiti.dev/guides/

Agreed. I still think that ruby is great for jamming out an API (far better in terms of development speed than go or rust) but a lot of the great gems that can speed up development assume server side rendering. That plus the fact that go/rust/whatever are probably more "interesting" and faster (at runtime) than ruby is an additional obstacle (for ruby!).

Probably JS taking over web dev and invading the server.

I loved Ruby, but unfortunately it didn't hold on to any kind of "killer app" role after Rails clones showed up in other language. I've switched to Elixir/Phoenix in that space and not looked back.

With the rise in ML and data science over the past years, Python finally has a killer app that no other scripting languages come close to touching. I migrated completely from Ruby when I started dabbling in ML, Pandas, etc.

From personal experience, hiring for Ruby development seemed to get a lot harder and of the few candidates that applied, many couldn't do FizzBuzz.

I've been working since the 90s and I never attempted to do FizzBuzz. Is it really relevant? Maybe to screen junior developers out of college?

So, as someone who spends maybe 20% of their time hiring, it's still a very effective screen. You wouldn't believe how many people can't do it. People at big companies, respected places. It's surprising.

Wow, that's depressing.

I used a different screen (having people make change based on an arbitrary amount, so if the input was 81, you'd return [25, 25, 25, 5, 1], as we were in the USA) and it was also helpful. I didn't track the number of people that it stymied though.

That sounds like a really fun one, and isn't dependent on people knowing about the modulus operator (which is rarely used)

Yah, that's also a good one. I like the variant that asks how many different ways you can make change for a given amount and a given array of currencies.

(I always feel weird talking about interview questions publicly, but honestly anyone who prepares that diligently deserves to go to the next stage. If anyone's reading this because they're preparing for an interview with me and I ask this question, just mention this comment and I'll be impressed.)

Correct me if i 'm wrong, isn't this one 'for' loop with 3 nested 'if' conditions ?

If someone can't do FizzBuzz, I'm not going to waste an hour interviewing. I get a surprising number of non new-college grads failing to do it.

OTOH I couldn't find a Ruby job in my town. Learning Scala these days.

I love Ruby but my customers are with Python and Elixir now. I do Ruby 5 to 10% of the time. Nearly all my personal project except some Node.

I think many people still "love" ruby I never liked Python from day 1 of my work (I am Ruby on Rails Dev for my job)

Wish there are more useful projects written in ruby :)

I am trying to find a place in the industry - again, starting from RoR. I absolutely love Ruby. And all this talk of "Ruby dying" makes me feel sad. The rational thing to do is to move on, and learn something popular, like node.js but the more I see Ruby in action, I just can't pull myself away from it.

I had managed to get a job as a Java developer a long time ago, but at that time all I could do was barely write toy apps in Java and I had no exposure to stuff like design patterns. The whole experience left me in a bad place. Now after all these years, Ruby feels like a breath of fresh air, and the texts that I have come across on the subject - Design Patterns in Ruby, Practical OOD in Ruby, Ruby under a Microscope etc. have increased my interest in the language.

But more and more frequent articles on Ruby's decline are pretty disheartening.

Ruby's future may actually not be Ruby itself. Probably the major problem with Ruby is its performance, which is slow even compared to other interpreted languages. While I'm not sure it is really production ready yet, Crystal is very interesting -- it's a native compiled statically typed language that nevertheless feels very much like Ruby. Check it out if you haven't.

I saw Tenderlove's interview on SE Radio, about Ruby internals. He seemed optimistic, but also because he's been working on a performance related project for the past few years now. Anyway, I'm hopeful.

It’s faster than python. And crystal is often faster than go.

Python's Poetry also addresses these issues.

Python is uniquely ill-suited for dependency management compared to many other languages. For some reason dependencies are installed into the interpreter itself (I know what I just said is very imprecise/inaccurate but I think it gets the point across).

In JS, which also has a single interpreter installed across the system (or multiple if you use nvm), the packages aren't installed "directly" into the interpreter, which removes the need for things like virtual-envs, thus making life a lot easier. I wish Python did something like this.

That being said, pipenv is making things easier. However, I think pipenv is a workaround more fundamental problems.

Not trying to defend Python, but it's not hard to make it work like JS without virtualenv:

    pip install -r requirements.txt --target=python_modules

Then to run:

    PYTHONPATH=python_modules python myscript.py

This will keep all the dependencies in the local "python_modules" directory. I've used this on a custom SaaS platform, and it worked quite well.

Also, that's more or less what virtualenv does. It would be nice if this was default, but IIRC it's coming.

Thanks for that! I am tired of messing with conda, virtualenv, etc. and since I use simple Makefiles to build and run most of my code, I can easily stick with the standard latest stable version Python installation when using your trick.

EDIT: a question: when I have to use Python, I like to break up my code into small libraries and make wheel files for my own use. How do you handle your own libraries? Do you have one special local directory that you build wheel files to and then reference that library in your requirements.txt files?

> How do you handle your own libraries? Do you have one special local directory that you build wheel files to and then reference that library in your requirements.txt files?

We didn't build wheels. We had a centralized git host (Gitlab, but any of them works) with all our libraries, and just added the git url (git+https://...) to the requirements.txt

Even better, thanks.

It's not a "model," but if you're able to 1) use fewer dependencies 2) use stable dependencies 3) use dependencies with fewer dependencies, it helps with dependency hell. I've even made commits to projects to reduce their dependency count.

I find rust with cargo and go with go-modules to be pretty nice to work with.

Does it have to be?

I have found that I would rather code my own versions of some libraries so I have control over it. Even if there is some extra long term maintenance and some up front dev costs, it's paid off already a number of times.

A little off topic, but this is why I really like a Common Lisp with Quicklisp: library dependencies are stored in a convenient location locally and the libraries I write can be treated the same way (with a trivial config change to add Quicklisp load paths to my own library project directories).

maven for java