7 ms·
Another Scala user here. And I've been using Scala for the last six months. Mostly developing web applications on Scalatra and Play. I love Scala - It still has
by neya 13y ago
Another Scala user here. And I've been using Scala for the last six months. Mostly developing web applications on Scalatra and Play. I love Scala - It still has its goodiness and it's an excellent alternative to Java.
If you notice in all of the Scala books (I've read the one by Martin and the One by David Pollak as well), they all seem to push you towards the functional programming model instead of the much more common imperative model.
But you know, there's a problem with that. Not with the language itself, but with the web development side of Scala. There's only certain ways by which you can program with a particular function that accepts a request and returns a response. So, most of the time, I would find myself wasting time thinking "How can I make this more functional?"
Functional programming is really great when you can actually enforce it - When writing algorithms and so forth, but otherwise, you are forced to fallback to this imperative model which sucks, because you have to constantly keep changing your mindset between these two models.
Another downside of Scala is its HUGE syntax. Processing strings? Here's a ten million ways to do it.. (a bit over-exaggerating). Oh and if you chose this way, then you should use this syntax. No, not that one, THIS one. Oh no, not that one, this variation of that one that looks like this.
I've advocated Scala to many HN members here in the past, you can even check out my comments, for instance. But from my experience, I think Scala is an Academic language. But it's superior in its own ways - I just LOVE the concept of avoiding nulls and passing an Option. It's beautiful. But the downside is its huge academic complex syntax. I want to be able to write code which shouldn't reduce my hair count even if I look at it after 6 long months. I don't want to refer to an 800 page book each time I'm confused about something.
That's why I think Go is beautiful. The syntax is just enough to keep it inside your head forever. I fear that as the language matures, this might also evolve into something as complex as Scala, but let's hope not so.
Go isn't a magic bullet though. It has its own downsides, but nothing w.r.t performance or similar. For the most part, it's awesome.
Once you go Go, you never go back.
P.s - I still love Scala as well ;)
- m0th87 13y ago> I think Scala is an Academic language Sometimes "academic" seems like a catch-all for stuff people don't like. Scheme has a strong academic history in its use and implementation, yet it seems to be described as "academic" only when someone is unhappy with how minimalistic it is, which is the opposite issue described here.
- neya 13y agoSorry, maybe like the other commenter mentioned below, the word I probably was looking for was 'industrial'. Or whatever refers to it as 'massive and complex'. Not necessarily a bad thing, for web development, most of it's depth is an over-kill.
- fsniper 13y ago"enterprise-y"? But I don't believe it is.
- winter_blue 13y agoHas anyone here used Haskell in a production environment? I want a language that is small, clean, and can provide a lot of static guarantees. I know many people find static guarantees and unacceptable curtailment of their "programming freedom", but frankly I think it's the answer to many of the problems we face in software today. Small is another thing. E.g. Go and Scheme are small. C++ and Scala are large. You know what I mean.. Now, static typing is just one kind of static assertion[1] I'd like to have. Side effect isolation (i.e. language-enforced purity) would be another feature I'd like to see become common. For example, the D programming language has a "pure" keyword that lets you mark a function as side-effect free. (In Haskell, all function are pure by default, and you escape the confines of purity via monads.) I'd like to do research into (inventing) other forms of static assertions. One thing that's been on my mind lately, has been static "complexity assertion" for programs. I don't know if this even possible, but it would be nice to be able to ascertain before running a program, certain time & space complexity bounds on it. This would perhaps require us to drop the programming language itself to some level "slightly below" Turing machines -- but this in itself could be achieved via a keyword like D's "pure" or something more elegant. (Note: my point is not that we're going to make the entire language non-Turing complete -- but rather that we'll have subsets of the language that are not, and this reduction of power would/could bring with it a greater possibility for statically asserting stuff.) [1] FYI I made this term up. Let me know if there's something better that describes this.
- scott_s 13y ago
- eranation 13y agoFor an academic language (which I assume is factually true as it was developed in a university) it is one of the most developer friendly academic languages out there IMHO, I rather write Scala than Java in terms of complexity, and if I would need to rewrite a Ruby code base, I would give it a shot in Scala before trying Go (feels more natural to me, they have way more similarities than I thought) I have the parts I need from Scala easily fitting in my head, which is perhaps just a subset, but enough for me to be very expressive in it. I think one of Scala's biggest issues is people being turned off by what sometimes feels as functional zealotry[0]. But people perhaps are not aware that it is also a great imperative language, you get no compiler warnings if you use a var or a mutable collection. I find it very close to Ruby actually and I think Ruby developers will feel at home with it [1] The other thing that holds it back IMHO is the compile time. (But this is improving from version to version) [0] https://twitter.com/wycats/status/372107196617592832 https://twitter.com/wycats/status/372107196617592832 [1] https://twitter.com/yukihiro_matz/status/372181477909200896 https://twitter.com/yukihiro_matz/status/372181477909200896
- winter_blue 13y ago> The other thing that holds it back IMHO is the compile time. Now that you mention compile time -- one of the biggest things that the Go designers cared about was compile-time. Go touts it as one of its major pros; and I do agree for personal experience that compile time matters. You can often cut down compile-time by making "run-time compromises". For instance, with C++ code, dyn-linking rather statically linking everything can speed up things significantly. This is because with massive C++ codebases, when you change a couple of lines, rebuilding the relevant objects only takes a few seconds - but the static linking stage can take forever. On memory constrained system (4GB) of RAM, I've seen a particular codebase that I've worked with take up to 28 minutes just to link. The same code on a machine with 8 gigs of RAM (just double) took less than 4 minutes to link. Due to the sheer number of objects that need to be linked, your system ends up thrashing (swapping pages out to disk). That being said, I read somewhere that Go doesn't support incremental compilation. I don't if this is still true, but that's a major problem that needs to be fixed right away. With interpreted languages, practically everything is done at run-time and you have no compilation stage -- but at a massive performance penalty. Tracing JITs do help though.
- dragonwriter 13y ago> But from my experience, I think Scala is an Academic language. Your complaints about Scala's size are more on point and oppose this; Scala is such a big language because it is designed to be an industrial language (academic languages tend to be small and focussed) specifically targetting the enterprise uses of Java. Academic functional languages that aren't designed to provide an easy glidepath for users of a particular large imperative OO language and provide access to that industrial ecosystem tend to be smaller than Scala.
- neya 13y agoThanks for the correction. I probably meant industrial when I said academic.
- ulisesrmzroche 13y agoFor real? That's cray. I didn't know the syntax was so hard to internalize.
- teddyh 13y agoFor a while I thought you meant Seymour Cray, or one of the supercomputers he designed and built. Was it so hard to type one letter in support of readability? Or is "cray" its own word now?
- deleted 13y ago[deleted]
- rthomas6 13y agoFor a while I thought you meant Vladamir Bro, father of the idea of pedantry. Was it so hard to type four letters in support of readability? Or is "bro" its own word now?
- ulisesrmzroche 13y agoSo are ya'll here to talk about Scala and Go or to pull some scrub trolls?
- munificent 13y ago"Cray cray" and by extension just "cray" are vernacular ways of saying "crazy".
- teddyh 13y agoI was aware of this, but was genuinely confused for a few moments, since I would have hoped that a reference to Seymour Cray was more likely on this forum than such, as you put it, “vernacular” forms of expression.
- marincounty 13y agoI think there should be a 500 page law. If you go over by one page, even if it's blank--the book is free?
- noelwelsh 13y agoI find your comment quite odd, as a web service is just about the most functional thing you can get -- it's just a function request => response as you note. I don't see where you'd need to make it "more functional."
- pkinsky 13y ago>Another downside of Scala is its HUGE syntax. Processing strings? Here's a ten million ways to do it.. (a bit over-exaggerating). Oh and if you chose this way, then you should use this syntax. No, not that one, THIS one. Oh no, not that one, this variation of that one that looks like this. On the other hand, Scala lets you deal with collections and Strings using the same enormous set of methods. "\"foo\"".drop(1).dropRight(1) is just List('"', 'f', 'o', 'o', '"').drop(1).dropRight(1)
- asdasf 13y ago>When writing algorithms and so forth, but otherwise, you are forced to fallback to this imperative model which sucks You don't need to fallback to imperative style. The fact that people write web apps in pure functional languages should make that obvious. >Once you go Go, you never go back. That depends where you came from. I really tried to like go, but went running back to haskell. Go is just way too primitive.
- cgag 13y agoYeah, I'd like to hear more about what kind of things make you fall back to imperative style.
- rybosome 13y agoI've historically been pretty pro-Scala 'round these parts, so my response to this should be considered in that light. So, with that disclosure out of the way... =) I have to admit, I don't agree with the assertion that the cognitive dissonance associated with programming in an imperative way versus a functional way is a major problem to Scala. I realize personal preference is a very big part of this, but there are many problems which are just easier to solve in a functional way versus an imperative way. Of course, the opposite holds true as well. This is the beauty of Scala; one can write performance-critical imperative code while exposing a functional interface; or, one can consume a fluent functional interface to produce imperative code. Frankly, I guess I've become something of a functional zealot, so my problem with Go is that it's so stubbornly imperative. This is why I can't get behind Go, as much as I want to. I feel like it doesn't consider many of the lessons that have been learned about FP making life easier. Set operations (map, filter, reduce) are insanely common, yet doing them imperatively sucks to the point of discouraging them. Excessive mutability is difficult to reason about. Nobody expects the nil/null/none inquisition. We tend to forget about side effects. Without an extensible language, which requires truly first-class functions, you're at the language designer's mercy. Hell, Scala probably isn't the be-all, end-all answer to all of this. I just don't think that a doggedly-imperative, non-composable, statement-oriented language is the future of programming "in the large", not when the past has shown us that we tend to produce buggy, unmaintainable software this way. I'm pragmatic enough to realize that pure FP isn't a solution, but I feel strongly that sticking to traditional imperative because it's familiar is a costly mistake. I can't argue with your take on the syntax, though, since that's personal preference. =) If you have any thoughts on why you feel productive in Go, I'd love to hear them; as I've said, I've been really struggling with motivating myself to learn and enjoy it.
- realrocker 13y agoHave ever tried programming in Go? Edit: Functional Programming in Go 1. http://stackoverflow.com/questions/4358031/functional-programming-in-go http://stackoverflow.com/questions/4358031/functional-progra... 2. http://golang.org/doc/codewalk/functions/ http://golang.org/doc/codewalk/functions/
- 13y ago
- djhworld 13y agoI liked Scala, but it's just the sheer weight of it that puts me off using it in my personal projects, and it still comes with JVM baggage. What it needs is some leadership. A few weeks ago Rob Pike and Andrew Gerrand (developers of Go) appeared on The Changelog podcast, which I recommend listening to, and one thing that Rob Pike said really intrigued me. He said that a policy they have when designing Go is to ensure that all members of the core team agree on any design decision before it gets put into the language. If one of them disagrees it gets tossed. That's probably one of the main reasons why Go is such an "opinionated" language and very small in nature. This probably infuriates some people as their favourite feature from other languages is missing in Go, but it keeps the language where it is and steers it on a path that the designers are maintaining complete control of.
- islon 13y agoI had more or less the same experience with Scala but I just jumped all the all way to functional programming and started using Clojure, never looked back =)