Live data from Hacker News

From Rails to Clojure, Then to Java, Then Back to Rails

engineering-management.space

61–70 of 157 posts

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#61
My career so far:

Delphi -> Microsoft stack -> Rails/Ruby -> Scala -> Clojure -> Rust

The stuff I remember well starts from Ruby. Good things:

- Ah man code is like a book.

- Lots of people were writing Ruby back then, so lots of libraries.

Bad:

- Deployments in general, this was before Docker, but I prefer having single binary/jar deployments

- Slow

- Lots of runtime errors

- You need lots of tests

Scala, good:

- If using IntelliJ, the development experience is kind of slick

- Quite modern, JVM libs work

- You can go functional or OOP, whatever you wish

- Fast

- Type system helps you out, so no need for that many tests

Bad:

- IntelliJ, I need my Emacs

- SBT is not very nice in the end, making a huge jar file can cause trouble sometimes

- Not the biggest fan of implicits

Clojure, good:

- Lisps are SO MUCH FUN to write

- ...especially if writing pure functions, stuff like code generators

- Emacs is good here, Cider rocks!

- JVM libs are available

- Leiningen is definitely nicer than SBT

- Everything is pretty easy and straightforward

Bad:

- Concurrency and effects can cause trouble, especially if doing it through Java libraries

- Leiningen is nice, but slow. You must use Cider.

- Runtime errors, as with every dynamic language

- Again lots of tests, but at least they're fun to write

Rust, good:

- Concurrency, IO and so on. Just damn nice with Rust

- Refactoring without fear

- Cargo is the best dependency management / build tool ever

- Small binaries

- Total control of CPU/RAM, you can do pretty fast systems

- If it compiles, it usually works

- Type system is great, libraries are quite nice already

- Community feels like the good old Ruby days, but better

Bad:

- Borrow checker still sometimes hurts, hopefully non-lexical lifetimes land to stable soon

- Problems with the current 0.1 tokio and futures can be pretty daunting. It's not a good idea to do super complex stuff with them yet

- Write your own libraries, especially if you started two years ago. That was fun though

I think the next thing I must grasp well is Haskell, just for the fun of it.

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#62

Another thing I’m getting is that the new kids won’t like rails, and it’s being harder to hire. I'm surprised by this, to me the language used would be a long way down the list when evaluating an employer.

It's because we don't like or approve of rails. It doesn't make business sense to us (us being a completely anecdotal group of young developers I'm friends with). There are other solutions that provide sufficiently more developer speed and safety, while also providing much better performance than any rails application. Edit: I guess I just hang out with like minded people, but our biases shouldn't negate the fact tha…

To answer many of the replies:

(Most prominent -> least prominent)

Web-related: Go, Elixir, JavaScript, Python

Desktop GUI: Python, C++

Game-Dev: C#, C++

Really its a matter of how much you'll pay us, and I think we've been scarred by too many bloated Rails apps and Wordpress sites to want to work on those.

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#64
post #36

Earlier quoted context omitted.

Not OP but in my limited experience the MVP slot is mostly held by Django, with Node + typescript, Go and Elixir being the “safer, faster” variants “kids” are using.

Ha it's funny seeing Django in that list because back in day (10 years ago or so) before rails took over I was trying to get everyone to use Django at my job. Then rails exploded and I moved to that. I honestly thought Django was mostly dead now.

[deleted]

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#65
post #41

The articles touches on this but just to reiterate because it's worth saying: The most important thing about Rails is knowing how the internals work and maintaining a clean code architecture. Too many times have I seen a mess in Rails because developers only use the APIs and DSLs given to them. The best Rails codebases are the ones who have ample "vanilla" Ruby and just happen to use Rails alongside said Ruby.

Really interesting comment.

I've started working on a Rails project. I don't have any professional experience with Rails in particular.

Can you recommend any code bases I can read that meet these criteria?

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#66
post #34

I've tried a lot of different languages over the years including Ruby, Go, Scala, and Haskell. Ruby actually isn't too bad if you don't use Rails. Between Rails and stuff like Spring over in Java-land I've developed a strong hatred of huge frameworks :) Clojure, however, is the one language that just 'clicked' for me almost immediately. In fact, I'm pretty certain I'll be sticking to Lisps as much as possible from he…

I'm agree with you as well except the Rails point.

I have used and deploy Go/Elixir/Clojure to some certain success. One thing I feel is that no code is as beautiful as Ruby code to my own eye.

What make Rails bad in your opinion? Is its performance? I think Rails is just a framework with many utility/helper to help you out.

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#67
post #21

In the "things learned from Ruby" section: Focus on strong object oriented programming What I've learned from Ruby is to favor functional programming concepts - minimize side effects, isolate state mutation, etc. Ruby is definitely OO, but when my Ruby code is more functional it's less buggy, easier to understand and move around, and generally less convoluted.

I've always had better luck restricting FP to using things like map, reduce, filter, (etc) inside methods as an implementation detail, but having the structure of the app use OOP.

Incidently that is how FP in done in Smalltalk as well.

All those methods, and reactive patterns (Observer and such) were already present in Smalltalk-80.

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#68
post #40

Earlier quoted context omitted.

Judging by listings in the month jobs posting, the vast majority of hiring companies won't look at you if you don't have immediate and long experience with their current tech stack.

Back in my late 20s, I got stuck on maintaining a legacy software system written in Ada95 (I was unemployed in 2008 and it was the only work I could find). When that job went away, I thought I could get a job using something more modern. However, the only job I was able to land was a new development project in Ada2005 (actually it was a port from SPARC to x64 and a partial rewrite of the same legacy application I had…

And even then, experience tells me one needs to have some luck that the HR people are even willing to listen about those side projects.

Good that it worked out for you.

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#69
I may sounds weird but Ruby is what make me look more into functional programming. I get done a lot with Ruby due to all method it has on Array/Object/Enumerable.

The beauty of `&` is awesome and I discover that Elixir/Clojure has that and bring it to next level. I think Ruby has inspired many other language to take that path too.

One of the thing about Ruby is that it optimize for happiness, which sound weird. But I really feel happy to write Ruby code. I feel like the language really care about me.

Who don't want to have stuff like this:

``` 10.seconds.from_now ```

Or just call method without `()`, and without even wrapping hash in `{}`.

Of course, lots of these are do-able in Lisp and I like Clojure. But I think the flexibility Ruby gives us is under estimated.

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#70
post #45

Earlier quoted context omitted.

Isn’t there something called LazyEnumerator that deals with this? In terms of chained .map at least

Lazy enumerators don't make each individual step of the iteration any more efficient. They just let you stop the iteration partway through without traversing the entire original enumerable. Given this contrived example: a = (1..1000).lazy.select(&:even?).map{|i| i*2 }.map{|i| i + 1 }.map(&:to_s).map(&:reverse) There is no benefit from lazy if you do `a.join(",")`, since that iterates over the entire sequence. But if…

There is absolutely a benefit to lazy if you're doing more than one combinator even if you ultimately need to iterate over the whole list such as the join case.

The lazy version basically turns into

   a = ""
   (1..1000).each { |i|
       next if i.odd?
       i *= 2
       i += 1
       a 
Where as the non lazy version turns into:

    odds = []
    (1..1000).each { |i| odds 
Which means that you have you went from N iterations to 5*N iterations, with 5 intermediate arrays in this case.
Post reply on HN