Getting into Akka (and other Scala open source projects) by sbt

sbt once simple is Scala now (and simple, too?)

Once I reached a certain level of confidence in my understanding of sbt, I’ve looked around for open source projects that use sbt as their build tool in order to get more insight on how much we could help each other. I’ve found quite a few projects that made me sad how far their builds are from what I’ve been learning about sbt for the past months. That is not to say it’s these projects’ fault. Quite the contrary, sbt was once meant to be simple (I kept hearing it here and there for quite some time before I jumped on the sbt bandwagon), however expectations seemed to have been too high on both sides.

It should come as no surprise that people are bashing sbt for its name that once meant to have reflected simplicity (as in “simple build tool”), but finally got touted as THE “Scala build tool” to better reflect its focus on Scala as the build language (that might be a reason for losing sight of simplicity during the “transformation” to Scala as the language is far from simple for some). I think it needs to change and begs for more effort from the sbt community.

As Josh Suereth has said during his talk about sbt.next – “Lot of investments going on in the documentation.” That’s quite too often a sparse resource.

Once burnt, twice shy?

Given how much sbt has changed with 0.13 and the plans ahead, it’s now the sbt community’s turn to take the stage and do the due diligence which is to help these open source projects getting better in their use of sbt (that should ultimately help both sides – the sbt community as a whole with more appreciation from the projects for how much their builds got easier with sbt). sbt 0.12.x and previous releases should be deemed highly poisonous with sbt 0.13.x the recipe.

Let’s treat it a call for action for the sbt community (or we’re going to end up as endangered species very soon with our hope and love for sbt). I think it’s about time!

Akka and the sbt build

Konrad Malawski has recently joined the Akka team (that with Grzegorz Kossakowski gives two Poles in Typesafe! Woohoo!), and I decided to celebrate the (not-so-small) change in Konrad’s career by embracing Akka in my tooling. I’m sure Konrad will like it (don’t you?)

I usually get myself engaged in an open source project by the sources (starting with compilation and reviewing the docs) and books (if they’re available). Akka was no exception and since I’m interested in sbt I couldn’t resist doing both – reviewing the Akka sources with their sbt build as the first gig. I’ve also got three books about Akka on my shelf - Akka Concurrency, Effective Akka, and Developing an Akka Edge - and there are quite a few coming (to the press or my shelf) - Akka in Action and Akka Essentials (let me know if I’ve missed any).

To make the story short – there’s room for improvement in Akka build- and documentation-wise (which again should come as no surprise as it’s a sort of fate of open source projects that usually focus on the code with community and documentation as a second thought). I know far too many people who’d like to get into Scala and one of the big open source projects, and think with Konrad aboard, Akka might be a good fit (and since there’s the sbt build they’ll learn the tool, too).

See you on GitHub!

Frameworks, Languages, Tools , , Leave a comment

Comments about sbt 1.0 – The Interactive Build Tool by Josh Suereth

There’s a bunch of video recordings from the NE Scala 2014 and I couldn’t resist to comment on Sbt 1.0 – The Interactive Build Tool by Josh Suereth. It’s 23 minutes about what’s coming in sbt 1.0 and the future of sbt.next.

Josh is an excellent speaker and he’s the product owner of sbt at Typesafe so he’s leading the team who develops sbt. All in all, who else could have presented the vision of the team about sbt than Josh?! You gotta watch the video since it’s very concise.

The video starts with a wide smile of Josh when he’s asking about people’s feelings towards sbt. He started his journey with sbt as a hater (!)

What’s the good about sbt – tilde ‘~’ (triggered builds) and plus ‘+’ (cross-versioned builds).

2:11 “We’re already an IDE…almost.”

Features of sbt (as pointed out by Josh during the presentation):

  • diverse plugin ecosystem.
  • the core of sbt is a type safe key-value map…which is really pluggable (when you think about it) and plugins benefited from it.
  • we use Scala as the build language that’s the main reason we (= sbt) exist in the Scala ecosystem. Josh smiles :-)
  • the default build which is an open source standard of how you should make an open source project and you can customise as needed

What’s bad about sbt – unsurprisingly the Number One is…Ivy – still the best conceptual model for dependencies – it beats the hell out of Maven – Josh wouldn’t go to Aether. Replacing Ivy is not an sbt 1.0 thing. The sbt team acknowledged that this is a problem. And pretty poor documentation. It’s still terse. Lot of investments going on in the documentation.

“The one thing people loved more than XML of Ant was the symbolic paths. So we got it right.”

“We improved the build format in sbt 0.13”

5:32 “The first API was all these applicative functors on tasks. We didn’t call it that because it still wasn’t cool. I think it’s ok here to call them applicative functors. I hope. Is it cool?” Josh smiles.

6:00 “The only thing that I’m noticing that’s kind of concern people don’t realise that this is still asynchronous. If you declare a dependency on key it’s not computed right where you wrote it – it’s actually computed asynchronously somewhere else.”

6:16 “We did a lot with Ivy – a lot of little stuff that you probably don’t notice besides I don’t have to delete the Ivy cache all the time, but only once in a while.”

6:33 “With 0.13 you’re seeing some new interesting stuff come out such as .previous to define incremental tasks.”

6:41 “Let’s talk about vision ’cause I don’t have much time on anything else.”

“We’re returning sbt into a server” and “We’re trying to clean up how plugins get implemented”.

And there’s more in the video, but you gotta watch it yourself to really appreciate what’s already available and coming up in 0.13.2 as well as 1.0. Have fun watching it!

Tools 1 Comment

Final thoughts on #ScalarConf = #Scala conference in Central #Europe

tl;dr It was the very first Scala-only conference in Poland. The conference was a massive success and with so many friends in one place and the good technical content with the incredible speaker’s line-up I wish it’d lasted longer for me. Kudos to the conference team, the speakers and the audience!

It’s hereby to thank SoftwareMill - the company that ran the conference for letting me sip the knowledge out of the best in the market in a very friendly and truly international atmosphere. I spoke to people from Netherlands, Italy (hey, @LuigiNoto), UK (hey, @propensive) and US (hey, @travisbrown and @xeno_by). I could talk to people I only had met on twitter or StackOverflow and managed to talk to so many Scalanians I barely had time to attend the talks.

I learnt a lot and got specially curious about pursuing my understanding of Scala macros that were today presented to implement…F#-like type providers. I really enjoyed the talk and am convinced to spend some time with them. Thanks Travis and Eugene for the excellent talk! I hope the talks were recorded so I can enjoy the presentation of yours few times more.

Jon Pretty is an mind-blowing speaker and when he speaks there’s so much fun as wisdom. He started his talk about Scala’s type system with few slides about yourself that themselves could’ve been the main theme. That was fun! Then, all of a sudden, he jumped in to Taylor series, addition, multiplication and derivative to explain Scala’s type constructors. That was the part where people were pretty much silent sitting in their chairs with open mouth while trying to swallow the enormous pill of math-heavy material. The comparison of Scala’s type constructors to an algebra with addition and multiplication was as much fun as mind-blowing. I heard a lot of “wows” everywhere! Thanks Jon for the excellent talk. I again wish the presentation was recorded so I can watch it again and again. See you soon on the Warszawa Scala User Group meetup!

The other presentations I could attend were Adam Warski about spray.io, Grzegorz Kubiak about Akka on Raspberry Pi, and Lukasz Kuczera with Scalaz—The Good, The Bad and The Ugly, a little bit of Tomek Nurkiewicz‘s The dark side of Scala, Konrad Malawski‘s Event sourcing with Akka-persistence and Grzegorz Kossakowski‘s Lambda implementation in Scala 2.11 and Java 8. I really hope they were all recorded as I’m gonna miss them otherwise.

I enjoyed the 30-minute chunks per presentation, that they were grouped to form 3-presentation one-by-one series and the breaks where I could talk to so many people who seem to fell in love with Scala in one place. The venue was enough to accommodate all the people and the location was in a lovely part of Warsaw - Mokotów Field – with green fields and trees (as if to remind us that Scala could bring many more green-field projects soon). A single track for the presentations and their variety turned Saturday into a long-lasting awesome experience that inspired me to learn Scala in ways I had not imagined would ever be possible.

Thanks all for the atmosphere and the topics! I really enjoyed the Scalar conference and am going to attend it next time.

Conferences 1 Comment

Go in Action from Manning and go installed

I’ve been hearing about the Go programming language here and there and when I’ve seen the freely available chapter from the upcoming book Go in Action from Manning I thought I’d give it a go. It’s an introductory material to Go and the why’s one could pick the language for the next project. What I liked about the chapter — yes, you’re reading it right, about the chapter not the language — were the questions to answer before picking a language, which in this case is Go. If a language wants to stand out it either has to offer a perfect implementation of an already-available-somewhere-but-not-so-elegantly-implemented feature or find its niche and hence face new challenges that lead to new criteria for a language. I have never considered quite a few before, and they do point out useful language features. It could only be for the additional features of how to select a language for a project that the chapter is worth your time.

The free chapter 1 “Introducting Go” is available at http://www.manning.com/ketelsen/ – a very useful and highly recommended reading! It seems so complete that I found no place to improve (except elaborating on Go’s features which I think is going to be a part of the other chapters). I thought it’s only about Go’s features without showing an example program, but section 1.3 “Hello, Go” does that — it offers the feel of Go by seeing a sample in action. It’s the hello.go from the website http://golang.org/, though.

Main points of the chapter and hence Go — some are exact copies of the sentences from the book:

  • Computers evolved yet programming languages not much
  • even your mobile phone is now smartphone with more cores than computers few years back
  • software developed by multiple teams spread around the globe
  • sharing code in Go is a built-in feature (whatever it means — I dunno)
  • use all cores with ease in Go
  • compilation in Go is lightning fast — you might not notice it at all
  • every programming language comes with a bunch of tradeoffs
  • static vs dynamic languages — a choice to make when picking a programming language
  • dynamic language suited for scripting
  • can’t verify the data in code is what’s on input
  • more code in dynamic language needs more tests (to verify correctness)
  • static languages give type safety yet can frustrate with repetition
  • productivity killer = code, compile, test…lather, rinse, repeat
  • deploying compiled code is a breeze
  • we can do better with the benefits of dynamic and interpreted languages with the speed and safety of static and compiled languages
  • passing thought to concurrency?
  • Ruby and Python use Global Interpreter Lock to ensure thread-safety and mitigate race-conditions => reducing performance due to one thread of execution
  • Java has concurrency primitives and often require tons of boilerplate for concurrent applications
  • We need a language with concurrency as a first-class citizen
  • a compelling feature of a language = how much done without using external libraries
  • hard to do much beyond simple text manipulation
  • Go a language with all the heavy lifting done?
  • developers make uncomfortable choice between rapid development and performance
  • fast execution vs rapid development? Can we have both? Go?
  • Go is a high performance language with development fast
  • Go has a concise syntax with very few keywords — not much to remember
  • Built-in concurrency features of Go — software scales to use resources available — one of the strongest feature of Go
  • Go uses a simple and effective type system
  • Go has a modern garbage collector — no need to manage memory yourself
  • Go uses a mart compiler and simplified dependency resolution algorithms
  • Go compiler look at the libraries you directly include
  • Many Go apps compile under a second
  • Entire Go source tree compiles under twenty secs
  • Goroutines are like threads but use less memory and less code to implement
  • Channels are typed memory queues to send messages between gorountines
  • Go facilities a model with data being sent to goroutines
  • Goroutines are functions that run concurrently
  • Many goroutines execute on a single thread
  • Writing a web server with web requests handled simultaneously? Use Go’s goroutines and net/http library
  • inbound requests processed on goroutine
  • Go runtime schedules execution of goroutines from a configurable pool of threads
  • Less development effort to achieve more
  • Goroutines run on one or more system threads
  • Keyword go to launch a function as a goroutine
  • It’s not uncommon to spawn tens of thousands of goroutines
  • Channels as a pipeline to enable safe data exchange between goroutines
  • channels as a shared memory access
  • channels enforce a single goroutine modify shared data
  • goroutine has exclusive control of data it receives on channel
  • Flexible hierarchy-free type system in Go
  • Simplicity of Go’s type system
  • Go developers embed types for re-use in Composition design pattern
  • Your types in Go are composed of smaller types
  • You don’t need to declare you implement interface in Go — let the compiler figure that out from the code
  • Many interfaces in Go’s standard library are very small with only a few functions
  • Go has built-in types like int or string and user-defined ones.
  • Go’s user-defined types look and operate similarly to C’s struct
  • Types may declare methods
  • inheritance vs composition
  • Go interfaces model small behaviours
  • Interfaces express capabilities of type
  • Duck typing when a type offers specific set of capabilities without specifying interface implemented
  • if it quacks like a duck, then it can be a duck
  • In Go, when type has methods of interface without specifying it explicitly, it can be used anywhere the interface’s expected
  • Go’s interface typically represents a single action
  • Most common interface – io.Reader
  • Go’s interfaces are smaller and single-action mostly
  • Go makes interfaces fun, elegant, and flexible
  • Go programs are packages
  • import enables external code
  • fmt package to format and print data
  • main() function is an entry point of application
  • You can use Go right from the browser – Go Playground at http://play.golang.org
  • Go developers use Go Playground to share code ideas, test theories or debug their code
  • Go Playground to solicit help
  • Project Kiev

After having reading the book, I installed the Go binary distribution for Mac OS X from https://code.google.com/p/go/downloads/list. It takes few seconds to install.

jacek:~/sandbox/golang
$ cat hello.go
package main

import "fmt"

func main() {
  fmt.Printf("hello, world\n")
}

jacek:~/sandbox/golang
$ go run hello.go
hello, world
Languages 1 Comment

WarszawScaLa UG coding session = Scalania 13 in Javart

I’ve been publishing my sentiments on the coding sessions called scalania under WarszawScaLa User Group on my Polish blog, but the ideas that are inspired by or spring out of them are worth spreading to wider audience and hence this one is here, in English (hoping that new ones come up or current ones got improved here and there).

20140305_201337The coding session took place in Javart – a Polish software house that supports the Scala community in Warsaw, Poland offering their venue and food, drinks as well as access to Internet during the meetings. I’m so happy the group found so pleasant home for the sessions.

We’re streaming meetups on Google Hangouts on Air and there are usually few remote attendees in a session.

What I liked about today’s meeting was that the number of participants (8 people) made it a nice collaborative environment where we spent most of our time on two presentations about Lift and Scala as an alternative to bash, and discussing the future plans. We’re going to have a 1-day-long hackathon soon (!) There was too few coding challenges today, but since the people who made it to the meetup today were almost from the day 1 we could discuss where we’re heading and what we want to achieve in the future.

Before we closed the session, we did two exercises from S-99: Ninety-Nine Scala Problems - P03 and P13. It took as few minutes to solve them even though we did them during the past sessions.

As a closing assignment, I asked the attendees to explain the goal(s) of the method aggregate[B](z: B)(seqop: (B, A) ⇒ B, combop: (B, B) ⇒ B): B from the List type. I asked people not to read the scaladoc or googling for the answer, but rather guess the purpose of aggregate from the signature. We spent almost half an hour in Scala REPL to have a few working examples yet we couldn’t figure out why and where we’d need the method. It’s our home work and googling is strictly prohibited. It’s gonna be a mental challenge for me to have a complete understanding of the purpose of the aggregate method. Did you know the method before? What were the use cases? Please advise.

We’re meeting up in Javart and streaming online via Google Hangouts in two weeks and if you could drop by and explain the aggregate method WarszawScaLa UG would appreciate. Understanding of the method is not needed to attend the session, though. Feel invited.

Languages , Leave a comment

What a pleasant experience – reading Pro Git book in Readmill on Samsung Galaxy S3

I keep trying out different approaches to absorb knowledge. I’m on GitHub to learn git and get skilled in a new way of software development which I call social development with people and projects I would’ve never been part of otherwise. Same for StackOverflow or twitter - yes, you’re reading it right – twitter – that can be as inspiring and offering an unabridged wealth of (implicit “linked”) knowledge when used appropriately as time devastating and without purpose.

I must admit I couldn’t have gotten used to one thing that seem so prevalent – using the many different kinds of devices to read books, articles or simply browsing the web. I seemed to have lived with paper books for so long that I couldn’t have stopped reading them on paper. It was part of me. Even when I had ebooks I couldn’t simply read them in that format, but was printing them out and was walking with paper sheets – the books – everywhere. It was very tiresome.

It has all changed once I bought my first smartphone – Samsung Galaxy S2. Then few months with Apple iPad 2 and I promised myself that with Samsung Galaxy S3 I’m gonna give book reading on a smartphone a serious try. And so I did. Something clicked. I was testing different ebook readers and got curious about Readmill on Android.

That’s not much git in my team in Citi. I wish we moved to git already, but it’s something we will do one day. There’re few attempts to work it around and practical knowledge of git is in growing demand.

There’s the Pro Git book, written by Scott Chacon and published by Apress available in Readmill. I couldn’t resist giving it a read. The reading went so well that I think I nailed it down. I may have become a ebooks-reading-on-smartphone convert.

The book was one of the very few books I’ve read recently that so easily introduced me to the topic of using Git as a common end user as well as showing its internals so I could feel more comfortable with the tool later on. Narrative was engaging and it was hard to get bored or overwhelmed with details. The book seems to have showed all I needed to become git power user. Highly recommended reading!

“Next book?” you asked? Functional Programming in Scala by Paul Chiusano and Rúnar Bjarnason from Manning has just been updated in chapters 1-15 with more updates to 7-15 soon. That’s what’s on my reading plate now.

Tools Leave a comment

project and projects commands in sbt

While reviewing the source code of sbt, I stumbled upon sbt.CommandStrings. I’d swear I’d been looking at the class so many times yet it was only today when I noticed how powerful the commands – projects and project – are. Even the official documentation of sbt is almost silent on the commands.

I simply couldn’t resist let the #scala twitterland know how mind-boggling the news was to me.

tweet-about-sbt-project-command_2014-01-06_2203

So to let you gain a little wisdom about sbt, I’ll let their detailed help speak for themselves.

[root]> help project
project

  Displays the name of the current project.

project name

  Changes to the project with the provided name.
  This command fails if there is no project with the given name.

project {uri}

  Changes to the root project in the build defined by `uri`.
  `uri` must have already been declared as part of the build, such as with Project.dependsOn.

project {uri}name

  Changes to the project `name` in the build defined by `uri`.
  `uri` must have already been declared as part of the build, such as with Project.dependsOn.

project /

  Changes to the initial project.

project ..

  Changes to the parent project of the current project.
  If there is no parent project, the current project is unchanged.

  Use n+1 dots to change to the nth parent.
  For example, 'project ....' is equivalent to three consecutive 'project ..' commands.

[root]> help projects
projects
  List the names of available builds and the projects defined in those builds.

projects add <URI>+
  Adds the builds at the provided URIs to this session.
  These builds may be selected using the project command.
  Alternatively, tasks from these builds may be run using the explicit syntax {URI}project/task

projects remove <URI>+
  Removes extra builds from this session.
  Builds explicitly listed in the build definition are not affected by this command.

Questions? Comments? See you on StackOverflow.

Languages, Tools , Leave a comment

“What if I had” vs “As I have” – “observables” on data streams before the kid falls asleep

It has just struck me when I was putting my 2-year kid to bed…

My professional career as a software developer was mainly zoomed in on what I’ve already had here and now with little to no use cases where I’d have had to compose computations that’d be realised at a moment in the future when I’d have what I wish I had. It was back then when I was a mere Java software developer (and thought that the only right programming approach/paradigm is imperative, object-oriented one).

These times went by and am now more often exposed to a variety of problems that are considered the domain of functional languages like Scala, Clojure or F#. The concepts of the languages are often in opposition to what I already learnt and are causing severe mental pains that only the moments of putting my kid to bed can offer relief to.

I know what I can do in my program here and now, but had no idea what I’m gonna do when an event occurs or when a thing gets available in the future, say a task completes.

In other words, I can easily develop an application that would process a sequence of elements, but am short of experience with use cases where I’ve got an infinite stream of elements that I may or may not want to process at some point in time not necessarily at the exact line the expression is defined. I got used to the procedural/imperative thinking a lot. It became me.

It doesn’t then help me much when I face use cases with streams where you compose functions lazily and only when you call a function that does the processing they all get called and have their effect on the stream. I tend to consider streams (= infinite and lazy sequences) eager ones. I tend to consider problems as working with bits already in my memory space.

The idea behind composing computations lazily and be able to apply them to infinite and lazy data streams is to think what you’d do with them once the right moment occurs that is quite often not the moment they’re composed together. I need to wait and observe, and that’s something I haven’t mastered yet. Time to change it (as the moment to make resolutions is approaching fast – a mere couple of days away – it however is one already).

Funny enough, it appears that the blog post may’ve been an example of an infinite stream of loosely coupled thoughts that have been passing through my head while putting my kid to sleep. One of the very few moments where I can tune in to a steady continuous sound of his breath and…think harder. Thanks, kid!

Languages , Leave a comment

Mastering Scala, sbt and Play, and having fun on GitHub and StackOverflow

I’m a strong believer and big proponent of using social development platforms as a highly productive means of rising my own programming experience and expertise.

Quite recently I’ve decided to be more visibleactive on StackOverflow because 1) sbt’s users mailing list moved to the platform, 2) as a way to learn the Scala build tool as well as Scala and Play, and 3) compete with some of my colleagues.

At the same time, I’ve been using GitHub to master git and a variety of collaborative development practices (I could apply to my personal and commercial projects), esp. the concept of pull requests.

Being on StackOverflow and GitHub is fun and with enough patience and care will surely rise your expertise. They both could eventually become an integral part of your public CV (with Twitter, LinkedIn, and SlideShare amongst the other useful social development sites…if used wisely).

I’ve really been enjoying this kind of professional development. You can socialise with people you may never see in person yet be guided by their expertise and feel an integral part of a developers community.

There’re plenty of ways to gain knowledge on the sites – simply reviewing questions, changing their title and content to make them more relevant and useful on StackOverflow or review changes and pull requests on GitHub – are just a few ways on their practical use. It doesn’t require much – just patience and care.

Few days back, I ran a scalania meeting where I was encouraging this kind of personal development and as an example pointed at the issues labeled “community” in the Play Framework project on GitHub and picked one – Rewrite play start to use play stage and run the start script from that. I hardly understood what the issue was about so I commented it to seek help. The answer came the next day and was very welcome to further collaboration. What I really liked was the sentence “Doing this issue would more be an introduction to SBT than an introduction to Play.” Since I’m currently more into sbt than Play Framework it was exactly my wish and I couldn’t believe how right my random choice was! Inconceivable.

Another example, just a few days back I opened the recent version of IntelliJ IDEA 13 Community Edition to learn sbt by reviewing the source code of the sbt-updates plugin that “can check maven repositories for dependency updates”. I’ve been using it for some time now and found it very useful. I knew it’s pretty small code-wise so with one hour free time I decided to give it a go. The journey ended up with two pull requests – one to README.md file using GitHub’s approach where a file once changed may eventually become a pull request with a few mouse clicks and the other on a separate feature branch I then pushed to the repo as another pull request. Easy and so much fun!

While on the sbt-updates plugin, I learnt how to configure sbt so libraryDependencies are different per sbtVersion in sbtPlugin (see the Files Changed for the pull request). I wasn’t sure whether or not it’s the right way to do it so I asked a question and answered it at once at StackOverflow - How to specify different libraryDependencies per sbtVersion in sbtPlugin with sbt-cross-building and sbt 0.13?. A StackOverflower liked it so I scored additional points for the question and the answer! With the answer of Daniel C. Sobral I learnt some more about sbt and Scala. That’s exactly the way to master different tools while having so much fun!

Check it out and see yourself how much the different social development platforms can do to improve your professional development. They’ve been working so well for me for the past couple of months and am sure they will in days to come.

What’s your take on using the many social development platforms? How are you finding StackOverflow or GitHub as a way to pursue your professional career? What other social sites would you recommend that would help me becoming a better software developer?

Uncategorized , 1 Comment

Trying out different development environments for Scala – Sublime Text 3 + REPL in iTerm

I am still unsure about the right development environment for my Scala developments.

At work it’s the very latest version of IntelliJ IDEA 13 with the Scala plugin (Windows 7) while at home I’m trying out other setups (Mac OS X). IDEA’s too much at times. I can’t seem to get fully up to speed with Sublime Text 3 either, perhaps because I’m not fully convinced it’s going to be my only development environment any time soon. People are using it with a great success, but the same may be said about Emacs or even Scala IDE.

Emacs is what many call the most powerful IDE, almost an operating system, but that is exactly what scares me a lot. Scala itself consumes a lot of my time, and with Emacs I’d have it less (or more when I’d learn it?). Let’s stick with something simpler. If however I could find a well written step-by-step document on how to get up to speed with Emacs and Scala, I might give it a try. Anyone?

Scala IDE is the IDE used by the author of the Scala language – Martin Odersky – while he’s teaching the courses on Coursera. It seems a de facto reference IDE for Scala development, but it’s Eclipse under the covers and I lost interest in using it (after I left IBM). I’m certainly sold to IDEA when picking up a full-blown IDE (I know nothing about the Scala support in NetBeans IDE).

With these mixed feelings I’m with Sublime Text 3 and sbt (console).

doing-exercises-fp-in-scala-sublime-repl

It’s however not a very productive environment for Scala newbies – no intellisense for Scala in Sublime Text gives very hard lessons. While there’s the excellent continuous relaunching a command, say test, with tilde (~), I haven’t yet learnt to have them upfront and often end up with just a bunch of Scala files that I load to REPL with :load completely overcoming SBT features that would help me upon saving.

What’s your development environment for Scala? I’d appreciate comments so they could help me find it and eventually focus on Scala rather than looking around for an development environment.

Languages, Tools Leave a comment