3 ms·
What do you mean by Ruby "hackery"? I'll agree that how to do things properly with Ruby isn't obvious when you're new to the language - just as it isn't obviou
by Tainnor 5y ago
What do you mean by Ruby "hackery"?
I'll agree that how to do things properly with Ruby isn't obvious when you're new to the language - just as it isn't obvious how to do things in Java (or other JVM languages) when you're coming from Ruby or another language.[0]
But Bundler doesn't work all that differently from Maven, in the end. Instead of running your commands through `./mwnw`, you run them through `bundle exec`[1]. Dependency management is straightforward and mostly hassle-free (the problems arise "only" when you use C extensions which, to be fair, is not that rare, but I don't really see a way around this in a language where you need C for certain fast things). In particular, Bundler by default[2] also stores dependencies centrally like maven to avoid duplication and then selects the appropriate version of a given dependency (unlike e.g. NPM which stores everything locally).
Rbenv (or alternative tools such as chruby or asdf) solves a problem completely distinct from Bundler or Maven, it's about selecting the right Ruby version for your project, a problem that also needs to be solved with Java. IME, many developers just let the IDE deal with that, but Ruby developers are more used to running things from CLI, so that's why rbenv exists. In any case, the most popular analogue for Java would be sdkman which works, mostly, the same way (and which, IME, is even a bit hackier than rbenv).
JS and Python are different. Node is a mess IMHO, and Python isn't able to agree on which package manager to use (I would hope people would migrate to Poetry, which seems to be doing things right).
[0]: For example, one thing that I find very annoying over in Java-land is that it's a real hassle to make sure things behave the same way when called from the CLI as opposed to from the IDE, such as setting the active spring profile. This is because, mostly, the IDE circumvents maven/gradle (you can run things through the build system, but typically the output, e.g. test output, is better when using the IDE-internal system, at least with IntelliJ).
[1]: There are "hackeries" to get rid of having to run everything through "bundle exec", such as binstubs and direnv, although I would mostly call them "shell script tricks", and anyway, if you instead just alias "bundle exec" to something shorter or create a wrapper script, it's not really worse than `./mwnw`.
[2]: This can be overriden and is actually a good idea for production builds, especially if you use a multi-stage docker build since then it's easy to copy over all your dependencies.
- tootie 5y agoI think you're missing that Maven does actually solve the rvm/nvm/pyenv problem. You can specify the bytecode version in the config and compile/run any backward compatible version. Your actual JDK need only be new enough, not an exact match and it doesn't need to change between projects. I have never had a single compiler or runtime version compatibility issue even with native dependencies ever with Java. The IDE situation can have some subtle edge cases, but no other language (save C#) actually gains so much utility from an IDE. Stack traces, break points, runtime inspection and profiling are all nearly flawless in IntelliJ (or Visual Studio) in ways that are monstrously difficult with any dynamic language.
- Tainnor 5y agoYes, but now you're not comparing maven vs. Bundler, you're comparing statically vs. dynamically typed languages. It's almost impossible to get the strong guarantees you get in a statically typed language in a dynamically typed one. If that's the discussion you want to have, well, I personally also prefer statically typed languages, but that's beyond the point. That said, I've had issues, e.g. on CI, that didn't manifest locally because of a mismatch in Java versions (something with JAXB, IIRC), and Java is maybe sometimes a bit too cavalier about the issue.
- npteljes 5y agoBy Ruby, Python and JavaScript hackery I was meaning rvm, venv / pip, and npm. I have the most experience with rvm, and the hackery part comes from the experience when I created a web interface that could instruct the server to do ruby tasks. Turned out that rvm (and also bundler) does a bunch of stuff to the environment of the user, that's sometimes inaccessible, even if you invoke a "login shell" programatically. One of these "hacks" is doing a bunch of stuff when the user navigates to a Ruby project directory with cd, which is when rvm creates or uses the existing virtual env for the project - named is a specific way based on the directory name. I solved this of course but the discovery was quite annoying. Regarding Python, I don't have much experience, other than the general feeling that it's fragile and that specific projects work with specific dependency managegers / virtual environments, and they are not really interchangeable or anything. I either could replicate the env or I couldn't. I definitely don't have much of a Python experience. Now regarding your Java IDE annoyance, I share the same experience. Also the case with Tomcat. IDEs do so much hackery so that user experience is convenient, that you would be hard pressed to replicate the results, and often need to test both because it just doesn't work the same way, due to the different dependencies used, deployment method etc. Now that I think about it, every single one of the programming ecosystems I used were quite annoying.