10 ms·
Brand new Scala-lang.org
- rtpg 13y agoNice to see the language page be as easy on the eyes as the language itself. There's almost no excuse not to use Scala if you're deploying on the JVM. On a related note, does anyone else see the Scala logo and confuse it for a symbol representing databases or hard disks? It just doesn't click with me
- frou_dh 13y agoCuriously, the Scala logo is reminiscent of the stairs in the photo at the bottom of the linked page. The ubiquitous "segmented drum" database icon has had me wondering before. Presumably it's a depiction of some big old vintage hardware.
- moondowner 13y agoThe logo actually resembles the stairs @ EPFL :) https://secure.flickr.com/photos/gilles_dubochet/7327041044/ https://secure.flickr.com/photos/gilles_dubochet/7327041044/
- noelwelsh 13y agoScala means "stairs" in Italian (and perhaps Spanish; I forget.) As another person noted, the logo is based on the stairs at the birthplace of Scala, EPFL.
- kaoD 13y agoIn Spanish it's "escalera", close enough :P
- omaranto 13y agoMaybe this varies from country to country, but in Mexico "escalera" means ladder, and "escaleras" means stairs (or the plural, ladders, with context disambiguating).
- kaoD 13y agoIn Spain (or at least where I live) "escaleras" means stairs, and "escalera" means both depending on context. "Escalera de mano" is the ladder-specific word. "Voy por la escalera" sounds fine to me if you're taking the stairs. EDIT. Another example: when a building is divided in two stairs (left and right) we mark it as "Escalera Izquierda" and "Escalera Derecha".
- deleted 13y ago[deleted]
- Dewie 13y agoIt also means "scale able language".
- kaoD 13y ago> There's almost no excuse not to use Scala if you're deploying on the JVM. Well, there are many excuses. Scala is a messy language* and I have Clojure which IMHO is a better alternative for JVM development. I used both Scala and Clojure and settled with Clojure since it fits functional programming better. Scala is OOP with a bit of FP. Clojure if FP with OOP in case you need it desperately. * "messy" as in "let's throw every feature we can think of into the language!"
- dinduks 13y agoScala is statically typed while Clojure is dynamically typed. Comparing them is irrelevant. > There's almost no excuse not to use Scala if you're deploying on the JVM. s/deploying on the JVM/a Java developer/
- fiatmoney 13y agoIt's a bit of a simplification to say that Clojure is dynamically typed - for instance, all of the builtin data structures conform to particular interfaces (for instance Seq) and operations over those abstractions are resolved statically. You can even make it into a parens-y Java with raw method calls, and tell it to warn you if it can't resolve a call statically (albeit you usually have to hint the initial input). There's also things like protocols, and Typed Clojure.
- chc 13y agoProtocol method references being resolved statically is just an optimization — it is not at all the same thing as a static type system like Scala has. There is no easy way in Clojure to say "This function takes an Address and a PhoneNumber" and have the compiler throw an error on compilation if Insufficiently Caffeinated You accidentally passes an integer in place of the PhoneNumber. The typed module implements a static type annotation system and type checker on top of the dynamic language, which is nice, but that still doesn't mean Clojure is statically typed.
- shadowfiend 13y agoI would take some issue with that. I think if you see the dual goal of creating a very strong, pervasive type system and trying to maintain OO compatibility, the features that are “thrown in” make a great deal of sense as a cohesive whole. It's certainly a complex language, but there is a coherent vision behind the features it has, IMO. That said, Scala certainly ain't perfect. It's certainly got its warts. And I'm not going to compare it to Clojure, as I haven't played with Clojure enough yet ;)
- pron 13y agoI agree that the website reflects the language, but my take is the opposite to yours (and allow me to be a little mean): The new Scala website perfectly embodies the philosophy of the language which says that if you squish together many concepts and elements, each of which is good on its own, then the result simply must be good as well. ;)
- eropple 13y agoThere's almost no excuse not to use Scala if you're deploying on the JVM. Lots of garbage generation. I like Scala a lot, but the space where I can really use it is smaller than I'd like. I do really like it and Play for one-offs, though.
- mark242 13y agoWha? In practice, we have seen much much _less_ garbage created by our Scala code. The use of objects in Scala encourages static method creation, and there's so much boilerplate Java junk that your Scala code just doesn't need.
- trailfox 13y agoAfter learning and using Scala there is no way I would ever voluntarily choose to use Java over Scala. Simply put it's a better Java than Java. I really like the new site design, not all that bothered about the logo. Maybe Scala needs a mascot too :)
- RyanZAG 13y ago"There's almost no excuse not to use Scala if you're deploying on the JVM." There is one incredibly good reason - possibly the most important reason. How easy is it to find a Scala developer if you need to expand your team compared to a Java developer? I'd put it the other way around: what excuse do you have for spending more per developer? (There are some excuses here, but they're far from clear cut.) In addition, Scala tends to run slower than Java which can have a further cost if you're scaling to many servers. Porting Java code to Android is also far easier than porting Scala code.
- eranation 13y agoSomeone had this argument (can't find the link) - for every ace Java developer out there you have hundreds of companies with a relevant position to compete over her / him. For a Scala developer position, you are competing with less companies, so you might as well be able to fill the Scala developer position faster than the Java one. Regarding speed, I don't mind about the runtime speed as much as compile speed, runtime speed is getting very close to Java, and is much faster than popular dynamic languages, I think it's a great alternative to JRuby, Jython or Clojure in that aspect.
- fecak 13y agoAs a recruiter, I think I'd have an easier time filling a Scala position because the demand for Scala jobs (primarily among those with little professional experience) has outstripped supply in the past couple years. If I post a Scala or Clojure job, I will get applicants from across the country. My Java job postings don't get nearly that much attention on a national level, because they are more common. People generally don't have to move for a Java position, but many are willing to move for a Scala/Clojure job.
- Qerub 13y agoI've heard that argument here: http://2013.flatmap.no/simen.html http://2013.flatmap.no/simen.html
- happy_dino 13y ago> How easy is it to find a Scala developer if you need to expand your team compared to a Java developer? How easy is it to find a GOOD developer? Much easier with Scala. It's not like wading through hundreds of Java resumes and interviewing them is free. > In addition, Scala tends to run slower than Java which can have a further cost if you're scaling to many servers. This depends on so much different factors in both Java and Scala that I'm happy to dismiss this claim as “not true”. > Porting Java code to Android is also far easier than porting Scala code. Really? Is there anything more to do than ProGuarding and dexing the existing code, both in Java and Scala?
- laureny 13y ago> There's almost no excuse not to use Scala if you're deploying on the JVM - Poor tool support (refactoring regularly broken on both IDEA and Eclipse). - Terrible backward compatibility story (want to use CoolLibrary v1.0, which was compiled with Scala 2.9 and you're using Scala 2.10? You're out of luck, you need the library to be compiled with the same version of the compiler). - Very slow compilations, and getting worse at each version. - The language is big (as big as C++) to the point where you must agree with your team on which subset to use. - It's so big that nobody can agree on which idioms actually to stick to: pure immutability? Functional style? OO only? Use scalaz or not? Shall I go on? I like Scala, I use it every day on personal projects but putting it in production at work would be a terrible decision right now.
- rybosome 13y agoWe used Scala in production at my previous job. It was great for the most part, but upgrading from 2.9 to 2.10 was a massive, massive pain. I think I spent nearly a week on the refactor. We didn't even have that much code (relatively speaking); the majority of the time was spent on finding substitutes for the libraries which were irreparably broken, and rewriting client code against the new API. That's pretty damning, but we could have avoided the upgrade if the team had better communication, so I see this also partly as a human issue. That being said, I would be willing to use it again. I didn't have an issue with compilation speed, and the size/flexibility of the language wasn't really a problem; we wrote in what I believe is the idiomatic Scala style (immutable objects, FP). Going back to Java now, I SORELY miss lightweight lambda expressions, pattern matching, native Option type (that people actually use), and the emphasis on immutability.
- trailfox 13y agoVersion compatibility is definitely a pain point, but as painful as that is I'd still pick that over using regular Java.
- happy_dino 13y agoCan you give some details what caused the issues in your the 2.9 -> 2.10 migration?
- coolsunglasses 13y agoOr Clojure.
- sam-mueller 13y ago"There's almost no excuse not to use Scala if you're deploying on the JVM." There's a good reason, actually - library maturity, especially when trying to get data in and out. Try and do some inner joins with typesafe slick and you'll know what I mean when you see the SQL it generates. Or try and use Play Framework's json de/serialization, and be prepared to punch your monitor in the face. I think these critical libraries can get there, but the lack of resources on these projects has me thinking we'll be waiting awhile.
- virtualwhys 13y agoI built ScalaQuery 0.10 against Scala 2.10.2, not touching Slick until the library matures. Think Scala Pickling by Sara Miller at TypeSafe looks excellent for serialization needs.
- phaller 13y agoFind out more about scala/pickling at: http://lampwww.epfl.ch/~hmiller/pickling/ http://lampwww.epfl.ch/~hmiller/pickling/ (It's Heather Miller from EPFL, though.)
- rtpg 13y agoFor libraries: if push comes to shove, you can just use Java libraries. The bridging is extremely easy (invisible in most cases"
- coopdog 13y agoI've definitely felt the pain of Play JSON serialization, it's infuriating. There's a macro that will take an entire object, generate the converter and do the conversion in one line of code, but it won't let you choose which fields not to send. So your list of users get their password hashes sent too. For deserialization I just do it manually by pulling the fields out of the objects sent.
- shriphani 13y ago>> There's almost no excuse not to use Scala if you're deploying on the JVM. The dev could be a lisper.
- sultezdukes 13y agoThere's almost no excuse not to use Scala if you're deploying on the JVM Do you really believe that or just being flippant?
- z0r 13y agoThe page loads quite slowly on my macbook air. I wonder how many 'reactive' Scala web technologies went into the creation of it! Scala is wonderful and all the hard work put into it is greatly appreciated. However, every Typesafe product targeting the web that I've tried has given my browser indigestion.
- jetti 13y agoIt must be something with safari as it is very slow on my iPhone running iOS 6
- bru 13y ago> The page loads quite slowly on my macbook air The 3771 DOM elements composing the front page may be the cause.
- felipehummel 13y agoChrome in OS X here and it all seems fine.
- asdasf 13y agoA billion useless nested divs will do that.
- chaffneue 13y agoIt's quite a pretty site, but the home page loads very slowly on my quad core I5. Something about this page is hanging up the dom onload event pretty significantly - Network tab showing about 7 seconds. Got a screenshot of the network tab here: http://farm4.staticflickr.com/3769/9399721127_a63086e535_o.jpg http://farm4.staticflickr.com/3769/9399721127_a63086e535_o.j... Luckily the api docs and tutorials are unaffected and load quite quickly.
- TylerE 13y agoAnyone else find this hard to read? The light blue/cyan is about 3 shades lighter than ideal. Especially for links.
- girvo 13y agoI recently installed Scala. I'm a PHP Dev, who plays around with Clojure on the side, but wants to be converted into the static typing camp. I also wanted to keep things functional (hence my love of Clojure, and my PHP code keeps things as immutable as possible), but also have a language that is usable if I were to go and get another programming job. Scala seemed a perfect fit. Until I looked at job boards for Brisbane :( For those that use it regularly, what sort of things do you build in.it? I really want to replace PHP with something, but between Enterprise Language Java and just-as-dynamic-as-PHP Ruby and Python, Scala looks like the only language that might fit... but then Play as a framework looked very heavy for my usage.
- shadowfiend 13y agoOn lightness, you'll have to evaluate. But Lift is an approach to web development that is relatively different from most out there, and which I've found tremendously refreshing, taking some really awesome approaches to separation of content and behavior and other stuff. It also embraces the benefits of static typing throughout and makes real-time stuff stupid easy. You can usually tune how many of Lift's more advanced features you use fairly easily—using it as a simple REST-based server is easy and still extremely pleasant, but going beyond that is also awesome. Disclaimer: I found it so refreshing and awesome that I'm now a Lift committer.
- dinduks 13y agoWe use Scala and Play to build (almost) any sort of web applications. The main reasons IMO are type safety in the code, the templates and the routes. The actors model allows doing side processing pretty easily too. Not mentioning the elegance of Scala itself. > Play as a framework looked very heavy for my usage What do you exactly mean by heavy? Actually I think it's quite simple since you only have to download an archive, unzip it, and start writing code as you would in any MVC Web framework. Spray.io is great for building API. It usually has better performance than Play. Scalatra is Scala's Sinatra, but the compiling times take out all the joy in using this kind of frameworks. Another Scala Web framework is Lift, but I don't know much about it.
- SkyMarshal 13y ago>but then Play as a framework looked very heavy for my usage. The terms "lightweight" and "heavyweight" and variants get thrown around alot describing frameworks, but can mean different things to different people: - size of framework codebase - size of app codebase - amount of code it takes to accomplish common tasks - memory footprint - deployment system - learning curve - feature list (barebones vs kitchen sink) etc etc. If you could elaborate a little on what heavy and lightweight you're referring to, the Lift/Play/Scalatra/etc experts might be able to better address that.
- adam_lowe 13y agoBeautiful. Glad to see another open source project with a solid site.
- justinmk 13y agoThe sbt site ( http://www.scala-sbt.org/ http://www.scala-sbt.org/ )is still impenetrable to anyone trying to understand wtf it does in under 15 minutes. (Why do I need this? How is it different than the scala compiler? Is it a package management system? Is it a REPL?)
- bronxbomber92 13y agoThe first words of the website: "sbt is a build tool". I couldn't understand not grasping the benefits/differences of sbt in comparison to other build tools, especially if you're new to the JVM world, but I don't think the website leaves any doubt to what it is.
- JonnieCache 13y agoBuild tool is a very broad category though. It could be improved by drawing a comparison, such as "sbt is a build tool, like make/bundler/whatever in scala" Part of the problem is probably that sbt is basically every build tool combined into one.
- deleted 13y ago[deleted]
- SkyMarshal 13y agoYou basically use it instead of Maven or Ant to build Scala/Java projects, but it's ridiculously comprehensive and extensive. I'm not sure calling it a mere "build tool" does it justice, more like "Recursive Extensible Project Management Tool" or something along those lines. And yes, it has both package management system and a REPL, among other things.
- ericax 13y agoIt's beautiful! The original one is good enough, this is even better. Good job!
- poweribo 13y agogreat design but some text are hard to read. dark color or dark background and no scrollbar on chrome.
- cyberroadie 13y agoThe staircase in the picture down the page is mirrored compared to the Scala logo. I've added some css to 'correct' this ;-) Pull request here: https://github.com/scala/scala-lang/pull/75 https://github.com/scala/scala-lang/pull/75
- neya 13y agoThe new homepage gives Scala a very classy feel! Nice!! This comes as a (personal) advise to all my fellow startups here. Dear dudes and dudettes, I've been a long and hard fan of the 'Get shit done' mentality and I still am. From my past experience running Rails and Scala, I'm going to tell you what exactly you should do for your startup: 1) If you KNOW FOR SURE your startup will face a lot of page views, requests etc. before hand (Example - Real estate portals like Airbnb, Trulia, etc), then you should not make the serious mistake of ignoring high performance frameworks beforehand. This could literally be anything, but the alternative I personally recommend is something Scala based [Read section 4 for WHY]. 2) As usual, use Rails (or django/similar) ALWAYS to build your v1 prototype. I say always because you will be incredibly surprised to see how much rails gets stuff done for you. While this is a huge advantage initially, this can also become a nightmare, later. Hence, I suggest you use rails only initially and not forever. When you build your app with rails initially, you're overcoming the most irritating pain point (or I'm just too lazy) - Building the database. Building the database with the required fields manually can be tiresome, if not slightly dangerous (assuming you are inexperienced). So, I suggest you install devise: gem install devise And implement authentication through it. Why? Because Rails+Devise will create some useful columns for you auto-magically - created_at, updated_at, sign_in_count, etc. (to name a few). 3) Now, you NEED to understand what's happening underneath devise as this is one of the core portions of your app. For this I suggest this rails cast: http://railscasts.com/episodes/250-authentication-from-scratch http://railscasts.com/episodes/250-authentication-from-scrat... Now that you understand how the most important part of your app works, you should start to build a clone of your v1 on your desired high-performance framework of choice. I use Scala personally (and I would recommend you too). 4) So, Why Scala? #Scala has a decent minimal syntax compared to Java, PHP and the rest. Scala: def test = {"hello world"} PHP: <?php echo "hello world; ?> Java: class HelloWorldApp { public static void main(String[] args) { System.out.println("Hello World!"); } } # Generally, on an average, 1 line of Scala = 10 lines of Java. That's less maintainable LOC (it can be argued otherwise, but just assume it's a good thing) # Performance. Now this is where Scala really shines. Scala's base performance is almost near Java's in most real world scenarios. You get the benefit of Java without actually using it. How fast is Scala in contrast to Ruby? Well: 1 JVM = 10 thins ("Rails is meant for a toy blog engine" - Soundcloud) Source: http://www.slideshare.net/pcalcado/from-a-monolithic-ruby-on-rails-app-to-the-jvm http://www.slideshare.net/pcalcado/from-a-monolithic-ruby-on... Approximately 20-40x faster: http://www.techempower.com/benchmarks/#section=data-r5 http://www.techempower.com/benchmarks/#section=data-r5 #Inter-operability with JAVA. This is a HUGE plus. While everyone loves to bash Java, you should not forget that it's a tried and battle-tested enterprise backed language. It's horrible (arguable), but reliable. So, this means, you can use that high performance image-processing function written in Java you always wanted by calling it from within your scala code NORMALLY. Now that's why I prefer Scala over newer languages like Go (It's really good, but the library support is still growing). Don't under-estimate this use case. Some secure functions used for authentication are available on various implementations on the Java land, compared to Go, etc. --------- 5) So if you use Scala, there's a lot of alternatives for frameworks out there. The most popular ones are Play, Lift and Scalatra. Play - Claims to be Rails like, but not even close to it. You need to work out everything on your own. Some stuff is still buggy and some are still scary (implementation of security functions). Stateless. Scalatra - Sinatra for scala. Minimal, super-fast, awesome. (I personally recommend this). Stateless. Lift - Tried and battle tested, used in production by so many popular guys (Foursquare for example). HUGE learning curve and too heavy for a framework. A hell lot of stuff is done automatically for my taste (like generating it's own login boxes with forgot password links, for example). Performance comparison of all three frameworks here: http://www.techempower.com/benchmarks/#section=data-r5 http://www.techempower.com/benchmarks/#section=data-r5 Note: Scalatra is the fastest (for most use cases) of them all. 6) Now, write a clone of your app in your framework of choice. Use the v1 Rails prototype initially to get your investors, clients, etc. But, by v2, ship out the code on Scala. This means, #Reduced costs (1 app server vs 10 app servers) #More time to focus on business activities and a LOT more time before you need to start worry about scaling (the framework) Pls note: The above point isn't true if your app is db constrained. Database suggestions: Please ignore the noSQL hype. noSQL is DAMN GOOD for prototypes (use it for your v1) and for specific production use-cases. 99% of the use cases are covered by SQL. And the noSQL hipsters have created a terrible image for SQL databases that they don't scale, etc. But it simply isn't really true. Even something as basic as MYSQL scales pretty well. As documented by Quora's founder here: http://www.quora.com/Quora-Infrastructure/Why-does-Quora-use-MySQL-as-the-data-store-instead-of-NoSQLs-such-as-Cassandra-MongoDB-or-CouchDB http://www.quora.com/Quora-Infrastructure/Why-does-Quora-use... Also, noSQL isn't a golden solution: http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb http://blog.engineering.kiip.me/post/20988881092/a-year-with... Some popular questions: 1) Scala engineers are difficult to find and hire This is partially (in)correct. If you face issues with your Scala code OR if your scala code is the bottleneck (highly unlikely), then you can always hire a good Java developer and have that particular function/code module re-written in JAVA. Java developers aren't difficult to find. Also, If you made the transition from Ruby to Scala, so can anybody else. 2) The productivity gain vs Performance gain If you write your app in rails, you get a lot of productivity benefits, at the cost of performance. If you write your code in Scala, you lose your productivity at the gain of extra performance. So which one should you choose? There is no doubt that Rails scales really well. But, out of the box, it is slow. Imagine it this way: There are two ways to make a sculpture - Using plastic (Rails) and using metal (Scala/Go/etc). Sculpting a metallic structure is hard (ignore molding techniques). Sculpting plastic is easy. But if you stress the plastic sculpture, it simply breaks out. There are lots of commercially available metallic coatings for your plastic sculpture that will promise you of no breakage etc. (SOA, Scalable PaaS like Heroku, etc.) But they are expensive, and they don't eliminate your pain points as promised. At some point you or an engineer is going to worry about the code. Better be it you and now than someone else, later. It is important you understand what goes under a framework's Magic (like authentication, database calls, etc) than just blindly believe it to be magic. This will not only make you a better developer, it will also help you from being taken advantage of by your outsourced companies or your engineers. -------- I just poured out everything from a personal stand point. Frameworks are a matter of personal choice - You choose whatever that resonates with your philosophy. So, at the end of the day, be sure to go with whatever makes you happy (and confident). All the best.
- gus_massa 13y agoThe page is nice! But it doesn't have snippets. They are very useful to get the feeling of the language at a glance.
- seanmcdirmid 13y agoThe ribbon as a brand logo is still not working for me. In its red colored form, it has an ugly faux 3D shine applied to it. In it's flat form, it is just a bunch of white waves, hardly recognizable or interesting.
- zoowar 13y agoVery nice, but this still sucks ass => http://www.scala-lang.org/api/current/#package http://www.scala-lang.org/api/current/#package
- ragatskynet 13y agoScala took the hipster way. I hope it will catch some new peoples attention because it is a lovely language.
- andyhmltn 13y agoI've always been intrigued by Scala as everyone says it's super fast but I was put off by the fact it had 'Java' in the description. But, looking through the new site (looks brilliant!) I think I'll take a look as it's got a nice syntax :-)
- kushti 13y agoPlay Framework is as good for v1 prototype as RoR/Django/Grails/PHP frameworks. But it's better in the whole project development process as you can easy go from v1 to v2 with it )
- disputin 13y agoVery nice, except for the typesafe blue that crept in at the bottom. That site needs an overhaul.
- dksidana 13y agoSummary: Object Oriented Programming: Everything is an object Function Programming: Everything is a function Scala: Everything is a function and an object both