2 ms·
> I was part of a SaaS startup using Java Spring You may accuse me of shifting the goalposts, but do notice I said modern above. I'm not up-to-date with Java a
by pka 8y ago
> I was part of a SaaS startup using Java Spring
You may accuse me of shifting the goalposts, but do notice I said modern above. I'm not up-to-date with Java anymore, but iirc Play [0] would be worth checking out.
> This is a problem you want to have because you have skin in the game.
I'm saying that this is a problem you don't have to have at all.
> Back to you - you didn't address my question - if you were to launch a product idea, what static stack would you pick?
In the context of SPAs, I'd choose some of the Purescript React libraries and some generic Haskell REST/Websocket server, like Warp/Servant (this is a stack I've used in production).
For a standard web app, I'd go with Yesod [0], which is a somewhat Rails-like framework, but it fully leverages the advantages of static types, i.e. it turns things like dead links, trying to inject user input into a DB query without escaping it first, invalid queries (i.e. querying a person by product id), and many more into compile-time type errors.
> I'm not saying you're categorically wrong, but you haven't presented any science to support your dismissive tone.
Still, to claim that the context of the current thread at least doesn't suggest that Rails is a maintenance nightmare would be disingenuous at best.
> Pick the right tool for the job.
That's what we're discussing here, right? I can't see when Rails would ever be the "right tool" for anything (except for the one use case I alluded to above) but that's obviously subjective, rendering that phrase utterly meaningless.
[0] https://www.playframework.com https://www.playframework.com
[1] https://www.yesodweb.com https://www.yesodweb.com
- hnzix 8y agoThanks for the thoughtful response. I think this comes down to low ceremony (move fast but easy to make a mess) vs high ceremony (upfront cost when adding features but high safety). I'll check out Warp and Yesod, although tbh the next stack I'd like to try is Clojurescript/Spec/Figwheel. Spec driven design seems to offer some of the benefits of static typing with the flexibility of dynamism.
- pka 8y ago> I think this comes down to low ceremony vs high ceremony One of the most cited qualities of languages like Haskell are their "refactorability" - i.e. one can routinely rip out the guts of a 100KLOC codebase and replace fundamental data structures and functionality in order to implement new features in a couple of hours, no problem whatsoever. In Rails, I'd do everything in my power to not touch any "important" code if I can get away with it, because no matter how good the test suite, it's still a test suite. It shows the existence of bugs, it doesn't prove their absence. Many people claim that's not a problem in practice, but I personally tend to avoid more fundamental code changes in dynamic codebases precisely because of that fact. To drive that point home, I'd trust a Haskell codebase without a test suite more than a Rails codebase with an average to good test suite. Also, it seems to me that "moving fast" is directly at odds with the topic at hand, upgrading Rails. If Rails allowed one to move fast, then surely upgrading Rails shouldn't take a year and a half, even in a big codebase? > Spec driven design seems to offer some of the benefits of static typing with the flexibility of dynamism. Definitely, though it's not a replacement for types. Also, the probably more important thing here is that Clojure is functional, making a whole class of bugs stemming from mutability and OOP impossible. If you're planning to go down the Clojure/spec route, you might want to check out Ghostwheel [0], a lightweight DSL which seems to be gaining a lot of traction lately. [0] https://github.com/gnl/ghostwheel https://github.com/gnl/ghostwheel