Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

engineering-management.space

Post reply on HN
Print view View original

111–120 of 157 posts

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

#111

Post by zombieprocesses »

iammiles wrote: post #110
zombieprocesses wrote: post #109

That reminds me of me after browsing HN's flavor of the month. Go -> Clojure -> Ruby -> Rust -> F# -> ...

Let me know when F# becomes flavor of the month. I'll gladly hop on that bandwagon.

https://news.ycombinator.com/item?id=13708453

https://news.ycombinator.com/item?id=14506287

Enjoy. If you want to dip your toes in the water, you can go through

https://learnxinyminutes.com/docs/fsharp/

for a quick introduction.

If you have background in functional languages/programming, most of it should look familiar. If you come from an OO or a procedural background, then it might take some getting used to.

But if you are looking to get a job at a windows shop, I'd stick to C# ( or VB.Net ) as that's where most of the jobs are.

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

#112

Post by innocentoldguy »

hashmal wrote: post #89
pimeys wrote: post #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…

> Community feels like the good old Ruby days, but better I really miss that old Ruby community. It was full of that hacker spirit, everyone trying stuff, no one to crush your creativity. Then the startup hipsters took over and came up with good practices, style guides, gems you absolutely had to know to get hired, etc. It drove me away from Ruby, actually. It just wasn't fun anymore. I hope it doesn't happen with Ru…

Your comment really speaks to me. I'm in the process of transitioning my career out of development altogether for the reason you mentioned getting out of Ruby. It just isn't fun anymore. I haven't been able to find a company with a good hacker-spirit since 2010. I like programming, and will probably continue with languages like Elixir and Haskell, but as far as the day-to-day work goes, I'm done.

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

#113

Post by mattnewton »

stevenwoo wrote: post #46
jarsin wrote: post #36

Earlier quoted context omitted.

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.

Anecdotally Django seems less common in the job listing post every month than Rails but is still present, and the python experience is relevant to many more.

Yeah I think it has to do with there being just more python scripts floating around, and Django (or flask) make it easy to turn that random script into a proper api. Plus CS courses have now started teaching python.

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

#114

Post by brandonbloom »

Years of Clojure has made me a dramatically better Rails programmer. The biggest change for me is that I now treat ActiveRecord models as gloried hashes with easy-access to a namespace of related functions (ie. methods) that operate on all manner of underspecified partial data, rather than traditional OOP-style objects with sophisticated invariants. I'm also very careful to strictly separate reads from writes, and to discard/reload all mutated objects immediately after transacting with them.

My new business is built on Rails for a very long list of reasons, not the least of which is that both Ruby is quite a nice language, and Rails is actually quite good for back-office/lo-fi/quick-and-dirty, server-side-rendered UX with relatively low web traffic.

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

#115

Post by faitswulff »

fyfy18 wrote: post #104
joshmn wrote: post #71

Earlier quoted context omitted.

My personal favorite codebase is GitLab (thanks syste and team!) — they do a very fine job of pumping out Ruby while hanging out in the Rails ecosystem. https://gitlab.com/gitlab-org/gitlab-ce — points of interest are in lib, as well as how they organize and call service objects from app/services.

As well as services, a couple of other folders you might want in app are for decorators and form objects. Form objects aren’t very common, but I’ve found it to be a really great patten for simplifying code. Strong params and ActiveRecord methods are fine for simple updates, but as soon as you get to something more complicated (e.g. what if you want validations to apply only for certain users?) it just becomes a mess…

Awesome, the form pattern is a useful one. My coworker and I were just talking about how frustrating it was to have validations coupled so tightly to the models and this would have helped a lot. Thanks!

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

#116

Post by oulu2006 »

jcadam wrote: 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 had a similar experience.

I felt so strongly about not wanting to go "backwards" anymore and use Go/Scala/Java etc I started my own company so I could dictate the technology decisions, so naturally I used Clojure!

I still use Javascript in most of the UX because ClojureScript I felt wasn't ready for primetime production but we'll be phasing that out over the next few years into ClojureScript.

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

#117

Post by dogweather »

tcopeland wrote: post #2

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.

Yes - Ruby makes it easy.

I'm run into the downside, though, that Ruby isn't optimized for immutable operations - tons of object instances created. I've needed to 'pythonize' my Ruby code in the worst cases - using mutable functions to dramatically reduce memory usage.

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

#118

Post by djur »

bbatha wrote: post #70
djur wrote: post #45

Earlier quoted context omitted.

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 inter…

That's how it could work theoretically, but in practice lazy iterators are much less efficient due to their implementation. I benchmarked it here:

https://gist.github.com/mboeh/bb480d93c71046e23816f2c24c23e3...

When applied to the same amount of work, lazy iterators consume more memory and take more CPU time than the equivalent non-lazy chained iteration.

There's a place for lazy iterators, but you should pretty much always profile first. If you have performance problems due to a long chain of iterators, you're always going to get better results by merging some of those iterators into a single block than by making the whole chain lazy. The best use case for lazy iterators is if you're trying to avoid having the original collection in memory (if it's being streamed from a file or the like). And at that point, if you're trying to optimize for performance, you should avoid chained iterations, period.

The good news is that in the vast majority of cases this just doesn't matter. Chaining iterators works fine until you start running into performance problems.

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

#119

Post by cutler »

blunte wrote: post #88
cutler wrote: post #78

Earlier quoted context omitted.

Ruby's composabilty really puts Python to shame. I can't imagine how Ruby lost out to Python.

While I much prefer writing Ruby to Python, Python is just dead simple to get real work done with. It's not elegant, but it's still so much less nasty than C++ or Java. Ruby's #1 problem, for me at least, is that your small project someday runs into a performance wall. I don't know the latest benchmarks, but last I recall Python was about 8x faster than Ruby when both are being interpreted. Yes, there's JRuby, but th…

What's your evidence for Python ever having been 8 times faster than Ruby? Apart from the numeric libraries, written mostly in C or Fortran, Python has at best only ever gained a very marginal speed lead over Ruby and that has been wiped out in recent releases of MRI. Ruby's startup time is a bit slower than Python's but once they're off to the races both of these horses have been neck and neck for a long time.

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

#120

Post by mikekchar »

yxhuvud wrote: post #97
joncampbelldev wrote: post #72

Earlier quoted context omitted.

Except if you're using immutable data, pure functions and explicit state there's a lot less room for OO which (as presented by ruby, java etc) involves mutable data accessed/changed via methods that conceal their state.

Nothing in the concept of OO enforces mutability. The paradigm doesn't enforce anything at all there. You want immutable objects that never changes once created? Fine, go for it.

I'm literally writing a blog post about this now (I'm building an objects system from scratch using only FP techniques in JavaScript... slightly eclectic ;-) ). The very interesting thing about this exercise is that immutability solves a huge host of problems in OO systems. As a very small example, even the diamond inheritance issue just goes away because nothing is ever updated. If B and C both have the base class A, you can safely instantiate A twice because it doesn't matter which one you use.

I'm about half way done. When I'm done, I'll post it on HN, but if you are interested here is what I've got so far: https://github.com/ygt-mikekchar/oojs/blob/master/oojs.org If anyone ends up reading it, I'm very happy to receive criticism, so feel free to leave an issue.

Post reply on HN