6 ms·
Disclaimer : I'm nobody important, but I do have an opinion If scala team were to disavow sbt, that'd be the single best thing they could possibly do for the e
by jrq 8y ago
Disclaimer : I'm nobody important, but I do have an opinion
If scala team were to disavow sbt, that'd be the single best thing they could possibly do for the ecosystem.
I used to write a lot of scala, and working with sbt was enough to eventually get under my skin.
I really like some of the OOP aspects of scala, the left-to-right style of thinking matches how my brain works. Scala having a lot to offer can distract new learners, especially with just how overwhelming all the different features can seem for someone not coming from both sides. I had ocaml and ruby under my belt when I found scala, so it was an easier curve, but lots of guys struggle with it. I don't mind showing them, and of course I learn a lot from guys with different experiences and different backgrounds, but that's sometimes a complain I hear, also.
It's a language that doesn't compare very well. What is scala like? We don't know, there's only one language like it, it's a departure from many different paradigms.
I'm back to writing ocaml, all said and done. I enjoyed my time with scala, and interacting with my guys on the other side of the office still doing scala is always enjoyable. Smart guys! I'm not academic enough to grasp some of the new DOT stuff, but they are excited about it.
Anyways, I gave up hope a while back on scala getting rid of sbt. There are other build tools that exist, cbt, mill, maybe more, but without the blessing from lightbend or whatever they call themselves this week, it's not feasible, or responsible to deliver a solution to a client with an unofficial build setup. Of course, after five years of doing sbt I decided it's not ok to deliver sbt either.
Someday! Maybe?!
- gaius 8y agoThe thing with Scala if you’ve come from OCaml is there’s no substitute for real Hindley-Milner, and the Scala object system isn’t good enough to compensate
- throwawayjava 8y agoDoes anyone use Scala in cases where OCaml is a viable option? My impression has always been that Scala is "better than OCaml if you need the JVM"
- jrq 8y agoMainly Spark, but it really depends on the domain, what libraries exactly that you'll need, hell I look at what kind of deployment routine the client wants, what their maintenance crew looks like compared to what they want from me. There is plenty of scala in fintech, I can tell you that. But there's plenty of ocaml, f#, matlab, excel macros, r, kdb, cobol, fortran, c++, a vast array of different technologies. Most places that choose scala are choosing it over erlang or Java or c#, they USUALLY only choose scala over ocaml if they want to have some old ocaml code talk with new infrastructure that they want built in scala, ime. Because of how performance works and that multi core isn't working yet, ocaml is limited in application if they're willing to find or already have scala programmers.
- lmm 8y agoI don't like having to give up full type inference, but it's much better than having to give up HKT.
- yawaramin 8y agoYou can get close enough to HKT with OCaml that you don't really feel any pain there. We have our share of generic monad libraries.
- lmm 8y agoUp to a point. I had a look and an implementation of traverse is already getting pretty cumbersome, and something like recursion-schemes seems beyond what anyone's even attempted.
- YorkshireSeason 8y agoI've moved to Scala in 2012 (because I needed to work on the JVM) from over a decade of Ocaml. I found that the absence of full type inference was not a major problem. The JVM library ecosystem on the other hand ... lack of libraries (at the time) really hampered Ocaml.
- pacala 8y ago> If scala team were to disavow sbt, that'd be the single best thing they could possibly do for the ecosystem. Seconded. Between http://www.lihaoyi.com/mill/ http://www.lihaoyi.com/mill/ and https://bazel.build/ https://bazel.build/, there are plenty of alternatives.
- bearforcenine 8y agoThirded. There are some exciting things happening in the Scala build tool space right now. We're migrating everything to Bazel right now, including our Scala code. Bazel + Scala is not amazing yet, but so far I have enjoyed it much more than sbt. It's also very nice to use the same build tool across all our languages.
- ionforce 8y agoScala enthusiast Jon Pretty just announced `fury` as well!
- lomnakkus 8y agoIf you look at what they currently support in terms of plugin availability and stability these are nowhere near being viable alternatives at the moment. The only remotely viable alternative to SBT I've found is Pants. (I guess Maven and Gradle might qualify too, but it's been so long since I've used them with Scala that I can't be sure.)
- eweise 8y agoMaven works just fine.
- eeperson 8y agoWhat 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.
- jrq 8y agoMacros going wrong with complicated builds, implicits galore all over the place, just the usual complaints. The thing that makes sbt difficult in practice for me is twofold. I don't want to deliver hackedy shit to a client that I then have to defend if their quality control comes back complaining about it. Being able to use regular scala in sbt definitions is convenient but at the cost of making things expressable that should wisely be done another way. Which brings me to the second point which is getting a sbt definition from a client and then they don't want to change it, or they don't have quality control so it's just awful, or its so bad that someone has to rewrite it for the solution. The latter being the easiest to deal with, but that also costs time. For those looking, what things do you feel have most improved the sbt experience?
- eeperson 8y ago> Macros going wrong with complicated builds, implicits galore all over the place, just the usual complaints. I'm not sure I totally understand this. What do you mean by "macros going wrong"? It doesn't seem like there are that many implicits used. The mostly to add methods to strings to make expressing things more concise. Do you think implicits shouldn't be used at all? > The thing that makes sbt difficult in practice for me is twofold. I don't want to deliver hackedy shit to a client that I then have to defend if their quality control comes back complaining about it. Being able to use regular scala in sbt definitions is convenient but at the cost of making things expressable that should wisely be done another way. > Which brings me to the second point which is getting a sbt definition from a client and then they don't want to change it, or they don't have quality control so it's just awful, or its so bad that someone has to rewrite it for the solution. The latter being the easiest to deal with, but that also costs time. This seems contradictory. It seems like in the first paragraph is at odds with the second. In the first paragraph, it sounds like you are saying that you want to be able to write messy builds and not have anyone complain. In the second paragraph, it sounds like you are saying you don't want deal with other people's messy builds. Am I understanding correctly? If so, do you want messy builds or not? How is this related to the build tool? What build tool prevents people from writing messy builds? Are you thinking of something like maven that is very rigid? > For those looking, what things do you feel have most improved the sbt experience? Some things that may (since I don't know when you last looked) have improved: * SBT 0.13 greatly improved the .sbt build file syntax (no more line breaks between settings, multi project in one file) * SBT 0.13 also cleaned up the symbol soup. Now to define tasks/settings you only need to know 3 symbols that are fairly self explanatory ':=', '+=', and '++='. If you want to depend on another task/setting output you just have do `taskName.value` in your task/setting definition. * A new artifact resolver has been written[1] that fixes all of the issues with ivy. It can be used today and is currently in the process of being integrated in the default SBT install. * SBT 1 introduced a build server concept with language server protocol support that is starting to improve IDE/editor integration * This isn't strictly SBT but IntelliJ now natively understands .sbt files so you can autocompletion and code navigation. [1] https://github.com/coursier/coursier https://github.com/coursier/coursier
- aphexairlines 8y agoI've been using Gradle to build Scala projects for a while now without any issues.
- braindongle 8y agoPlease don't use "guys" this way. This is not PC nitpicking, It's important. "People" or "folks" may not have the ring you're after, but too bad.
- jrq 8y agoSome of my biggest stressors in the past came from trying to change people or believing that I was entitled to have people act and react the way I wanted them too. I don't give that privilege to others and I don't expect anybody else to. I say guys because my developers and analysts and quality managers are all men. The only women I work with are two secretaries, and they're not even in my department. What's too bad, friend, is that you have deluded yourself into believing you have the right of way over another person, for any reason whatsoever. Bless your heart!
- bitcharmer 8y agoHow is this not PC nitpicking. You really need a special kind of mindset to interpret completely harmless and generic term in this way. Please take your SJW-ism somewhere else. This is HN.
- dmix 8y agoOxford dictionary: 1.1 guys People of either sex.
- ionforce 8y agoI was in a meeting where this just happened. And as liberal as I am, it is exactly PC nitpicking. You can also choose to lead by example rather than correcting people. Despite all the good intentions in the world, people may not react well to this style, making your contribution locally ineffective. This is double if the person you're correcting doesn't think what they're doing is "wrong".
- lmm 8y agoI don't think SBT is in any way officially endorsed in the first place? Many popular libraries use it, but there are plenty of other options. If you're not maintaining a public library that has to cross-build against multiple versions of Scala, IME there's no reason not to just use Maven, which gives you simple and well-documented builds.