eeperson

What problems did you have with sbt? Depending on how long a go you used it, those problems might have been fixed. In the last couple of years, a lot of simplifications have been made to how sbt build scripts are written.

This is part of the reason that I highly recommend compile time dependency injection (Macwire[1], Dagger 2[2]) over runtime dependency injection (Spring, Guice). It is generally much faster. Also, if it does slow down compilation, it is a price rarely paid due to incremental compilation.

[1] https://github.com/adamw/macwire

[2] https://google.github.io/dagger/

I agree. That is why I prefer to use compile time dependency injection like Macwire[1] or Dagger 2[2]. At least in the case of Macwire, it is super simple to reason about at compile time.

[1] https://github.com/adamw/macwire

[2] https://google.github.io/dagger/

What tooling do you think is missing due to erasure?

That is correct. There are 2 separate APIs (that come from a single project). This is because Scala can support a bunch of functionality that Java (and Kotlin) can't support (type classes, higher kinded types, etc.). So your options are to hamstring the API for Scala or have 2 separate APIs.

There is only one for play as well

This hasn't matched my experience.

> Calling Java from Scala is awkward at best (in many cases) and sometimes impossible. Scala was never engineered with a smooth Java/Scala mixed mode in mind.

I assume you meant calling Scala from Java here. With that in mind, writing an API that is easy to use from Java isn't that difficult. It is basically down to limiting the feature set you make use of in the interface and converting to Java collections. These are both pretty easy to do. Granted some Scala features are expressed in ways that are not easily used from Java. However, this just because Scala is significantly more expressive than Java. I'm not sure why you consider this to be a problem.

> In Scala almost everything from Java gets reinvented sooner or later.

I'm not sure what your point is with this. Scala wrappers for Java code are common but not because of issues with calling Java code. These are written because Scala can expose a much richer and much safer interface (again because Scala is much more expressive).

Really? I haven't tried setting that up but here is an example from 3 years ago of some one successfully setting up this exact combination [1]. Have things gotten worse sense then?

[1] https://groups.google.com/forum/#!topic/scala-on-android/0y1...

> As it was designed for complete interoperability with Java, Android devs can migrate piecemeal. You can use the same libraries, the same build system, the same IDE.

This is all true for Scala as well.

Why wait: https://chisel.eecs.berkeley.edu/

Chrome doesn't appear to default to process per tab either. See: https://www.chromium.org/developers/design-documents/process...

Sorry,I should have been clearer. The GP post mentioned 2 ways to implement a LINQ to execution plan transform. The first way would be to do it on the client. This is problematic because the client doesn't have enough information to generate an efficient execution plan. That makes sense to me. The second way would be to do it on the server. This is the part I don't understand. Why can't we do it that way? This is how it is done for SQL.

How is implementing LINQ on the database any different implementing SQL on the database?

> SQL is still in widespread use 43 years later because of how good it is. It's not a legacy weighing us down.

I'm rather dubious of this claim. This is kind of like claiming the reason we use Javascript is because of how good it is. The awkwardness of SQL is not because it is declarative, otherwise LINQ would have the same awkwardness because it is also declarative. I think the real reason SQL is because database vendors have not made an effort to add support for other languages.

Why would you need a decompiler to write a debugger for Groovy? The groovy compiler supports including source code line numbers and variable names in compiled jar files (just like Java). As a result you can use any Java debugger to debug Groovy.

Also, why would you expect that Groovy can be compiled and then decompiled to Java? This doesn't even work 100% going from Java to Java, and Groovy is going to have idioms that doesn't map easily to Java idioms.

Yes, Groovy does have a debugger. It is just the Java debugger. I use it nearly every day to work on a Grails project. Also, yes, you can attach it to an existing process. As far as I can tell, that comment doesn't make any sense.

You can do this with user level systemd instances: https://wiki.archlinux.org/index.php/Systemd/User

Looks like I was wrong. You do have to enable lingering[1].

[1] - https://wiki.archlinux.org/index.php/Systemd/User#Automatic_...

Yes, but you can use 'systemd-run' to do something similar[1]

[1]-https://github.com/systemd/systemd/blob/master/NEWS#L29

Wouldn't that kill off anything started by init as well?

I don't think the 'lingering' option is necessary. That controls the default behavior for processes. Systemd-run basically makes a one off user level service.

You wouldn't have to write service/unit files for one off commands. The release notes mention that you can use 'systemd-run' to start these[1].

[1] - https://github.com/systemd/systemd/blob/master/NEWS#L29

> Does anyone know if there's any precedent for a UNIX init system to behave like this?

My guess is that previous init systems didn't do this because it wasn't really possible before cgroups. I'm certain that this behavior would be desired on multi-user systems to ensure that logged out users don't leave old processes lying around.

Yes, it can also support local sockets as well as network sockets.

I think socket activation makes sense as part of the int process because of the 'activation' part. That's basically what you rely on init systems to do.

For more details about the advantages of this can be found here[1] and here[2].

[1] - http://0pointer.de/blog/projects/socket-activation.html [2] - http://0pointer.de/blog/projects/inetd.html

IntelliJ doesn't have the Scala plugin installed by default. However, that is true that you could combine the 'Install IDE' and the 'Install Scala IDE plugin' steps by installing the Scala IDE.

Even if you do combine those steps, there are still further steps a user would have take after they install everything. You described the set up as just being as simple as "Push the button, choose the scala template, give it a groupId and artifactId, done". However, I don't think it is that simple. As far as I'm aware, no IDE will give you a Scala project with a Maven POM. You can choose to create a 'Scala project' or you can create 'Maven project'. You can't create a 'Maven Scala project'. So you will have to figure out how to add Scala support to Maven manually. Also, you may have to figure out how to let your IDE know that your project is both a Maven project and Scala project.

> Sounds horribly magic/incomprehensible

How is compiling everything in a given directory any more magic/incomprehensible than any other build tool?

> I don't think the work of doing it in Maven with an IDE could be called substantial. Push the button, choose the scala template, give it a groupId and artifactId, done

What IDE comes with a 'scala template' out of the box? What if you are not already in the JVM ecosystem? With SBT, the set up is:

- Install SBT/Activator

With your suggested equivalent, the steps are:

- Install Maven

- Install IDE

- Install Scala IDE plugin

I think the SBT option sounds like they would be much less imposing for a beginner.

I can think of some very good reasons to suggest SBT to beginners. Probably the most useful features, in this regard, is that a folder with some Scala files in it is a valid SBT project. You don't even need a build configuration file. This is substantially less work than setting up a Scala project through Gradle, Maven, Ant or an IDE.

Also, if you use SBT through Activator[1] you get project templates and an automatically configured IDE.

[1] - https://www.lightbend.com/community/core-tools/activator-and...

You can do the same thing in Emacs too. For example, this[1] supports that for Scala (and I think Java now as well).

[1] http://ensime.github.io/

That makes sense. I actually never use daemon mode because I don't want to share buffers. If want a faster start up time but don't want to share buffers you may want to look at use-package[1] which will lazy load plugins. Also, if you want a easy way to cycle through buffers that also works in the terminal I recommend iflipb[2]. When you start cycling, it shows a list of buffers in the mini-buffer. Both of those are available as packages in Melpa.

[1] - https://github.com/jwiegley/use-package [2] - https://github.com/jrosdahl/iflipb