Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's Next for Scala

lihaoyi.com

Post reply on HN
Print view View original

171–180 of 203 posts

Re: What's Next for Scala

#171

Post by jnbiche »

11Di wrote: post #158
jnbiche wrote: post #141

Earlier quoted context omitted.

OK, here's my question then. You're embracing Option type and yet presumably avoiding monads, applicatives, and functors (avoiding "FP-crusader stuff"), right? So what happens when you are dealing with multiple option types, like you two optional ints you need to add together? Or you have an optional field in an optional object? This happens all the time in code that heavily uses Option types. So do you match on ever…

For comprehensions should alleviate the examples you have given with regards to readability. Although yes there are other more complex instances in which nested matches might come up. Generally I would think to handle them by creating a function that contains the next layer of matching instead of trying to come up with an uber function. Adds a bit more verbosity perhaps but I find it is fairly easy to follow and show…

My question was poorly phrased, since if you're using Option types, you're obviously already using monads, applicatives, and functors.

What I should have asked was: if you're using monads such as Option, then how do you use them effectively without using integral tools such as flatMap?

And you've answered: you can use for comprehensions. I primarily have used Haskell and OCaml, so I sometimes forget about Scala's very nice for comprehensions, which I agree is a great solution. But note that for comprehensions are just syntactic sugar for `flatMap`.

I agree that if you do use Option types in Scala, for comprehensions are a very elegant way to interact with them.

But I'll end with a question. If you're already using option types with for comprehensions, why not also throw in other useful monads like bifunctor IO, which is a great way to deal with async code? I understand the dislike for the tendency in the FP Scala community to use custom sigils, but I do think most people who are using options and for comprehensions would also be comfortable and happy using other useful monads with for comprehensions.

Re: What's Next for Scala

#172

Post by dominotw »

tasuki wrote: post #156
dominotw wrote: post #30

Earlier quoted context omitted.

Agreed. I switched from scala to python and oh man what a relief. Scala is a heavy weight languange. By heavyweight I mean, 1. Even intellij struggles to figure out the meaning of implicits in the given context. And then there are macros. 2. Way too many theoretical concepts, monads, monoids , isomorphisms ect that make you feel stupid. There is always a nagging feeling that you don't 'get it' when you program in sca…

> I switched from scala to python and oh man what a relief. I did a bit of Python, then did a bit of Scala, and now do both at work. Oh what a pain Python is! And what a joy Scala is! > Way too many theoretical concepts, monads, monoids , isomorphisms ect that make you feel stupid. Concepts are theoretical in their nature, aren't they? Perhaps these concepts are useful and you just haven't yet found out why? Wrt feel…

> Perhaps these concepts are useful and you just haven't yet found out why?

Or maybe they are not that useful? If they were really that useful we would see those concepts everywhere.

Re: What's Next for Scala

#173

Post by spir »

jmeister wrote: post #46
spir wrote: post #29

Earlier quoted context omitted.

I've worked with Dotty a bit and read about it a lot. I am very excited about Scala 3 :) Scala 3 isn't a python2/python3 situation. It will take years for large codebases to be upgraded to Scala 3. However, the tools to migrate code from Scala 2 to Scala 3 will be reliable and highly automated, due to Scala's strong type system. Most popular Scala libraries and frameworks will be available on Scala 3 right from the g…

Thanks for this info, very useful and exciting. I stopped using scala around 5 years back, want to get back to it. Would you recommend jumping straight to dotty? I’ve been doing a mostly python and a bit of Haskell in the meantime.

I'd jump straight to dotty! You may as well learn the latest 'n greatest.

Re: What's Next for Scala

#174

Post by spir »

tutanchamun wrote: post #97
spir wrote: post #25

Earlier quoted context omitted.

In my mind, GraalVM native compilation has superseded scala-native. GraalVM native compilation works really well. Many projects will compile to native out of the box. Many more with a bit of reflection config that's autogenerated. The native executables are slim, statically linked so they "just work", and startup instantly as one would expect. Scala is now a great choice for CLI tools.

> statically linked so they "just work" If I remember correctly you have to redistribute some .dll (VC something) file alongside your .exe on Windows since fresh Windows installations don't have the .dll. Did that change?

I haven't tried GraalVM native-image on Windows :(

Re: What's Next for Scala

#175

Post by lcall »

therealdrag0 wrote: post #120
lcall wrote: post #64

I wanted Scala to be my "better Java" for a long time, mainly because it seemed to have plentiful headroom as I seek to learn more. The community enthusiasm was also contagious. But: 1) the ecosystem makes it seems like I need to be a genius enough to learn a new DSL a bit too often, and everything is so...complex, which leads to... 2) It is hard to pitch to an organization because of the learning curve if you assume…

I don’t understand your comment about SQLite. Doesn’t the driver manage creating a standard SQLite file? This shouldn’t really be Scala related. Example connecting: https://github.com/tkawachi/sqlite-scalikejdbc-test/blob/mas...

Right, it's more of a JVM issue which affects scala. I did a search a while (couple years?) ago and maybe just didn't find the right materials, but they all (in my now-vague memory) seemed awkward and/or were not portable across platforms. Does this approach let you do every kind of sqlite operation, as completely as if from the interactive native client or as if calling it from C? Who maintains it and is it kept in sync with the C version? (Maybe I'll go look that up, but if you already know...) Thanks much for the info.

Edit: ps (maybe a note to myself as much as anything in case I go look up this stuff): And does sqlite run in the same process as the app? Can the app process control the db location?

Re: What's Next for Scala

#176

Post by lcall »

vvillena wrote: post #68
lcall wrote: post #64

I wanted Scala to be my "better Java" for a long time, mainly because it seemed to have plentiful headroom as I seek to learn more. The community enthusiasm was also contagious. But: 1) the ecosystem makes it seems like I need to be a genius enough to learn a new DSL a bit too often, and everything is so...complex, which leads to... 2) It is hard to pitch to an organization because of the learning curve if you assume…

Scala dev here. "Having to learn Java" is not true at all, unless you interact with Java dependencies in special ways, or if you maintain a Java API for your Scala code. There are Scala libraries for almost anything, and it's easy to use some Java libs here and there. Creating wrappers is also simple. One of the coolest things about Scala it that it already contains lots of Java best practices. Case classes, singleto…

Another follow-up about my point #2 above: if scala had done this early on (in an armchair hindsight kind of way), I don't know what need there could have been for Kotlin, and we could be learning one language for both purposes (better java and lots of headroom to learn/grow), instead of requiring 2-3 languages or more. Edit: I would appreciate better thoughts to improve my view on that.

Re: What's Next for Scala

#177

Post by AzzieElbab »

tasuki wrote: post #155
AzzieElbab wrote: post #73

Earlier quoted context omitted.

I always thought scala native to be a bit of distraction after graalvm went mainstream. Don't know why people do not like working with language that can combine better parts of Java Haskell Ruby and Erlang. Having said that, Scala is Scala, and people who are writing Haskell or Java code in Scala certainly not writing Scala

> people who are writing Haskell or Java code in Scala certainly not writing Scala For me, one of the joys of Scala is that you can use different paradigms and mix them up as convenient. Haskell Scala is still Scala and so is Java Scala!

I do that too, but to a degree. For example, I avoid monad transformers, fully automatic derivations, pretty much anything that requires line long type signatures

Re: What's Next for Scala

#178

Post by therealdrag0 »

lcall wrote: post #175
therealdrag0 wrote: post #120

Earlier quoted context omitted.

I don’t understand your comment about SQLite. Doesn’t the driver manage creating a standard SQLite file? This shouldn’t really be Scala related. Example connecting: https://github.com/tkawachi/sqlite-scalikejdbc-test/blob/mas...

Right, it's more of a JVM issue which affects scala. I did a search a while (couple years?) ago and maybe just didn't find the right materials, but they all (in my now-vague memory) seemed awkward and/or were not portable across platforms. Does this approach let you do every kind of sqlite operation, as completely as if from the interactive native client or as if calling it from C? Who maintains it and is it kept in…

I don't really know the answer to those questions. But I know SQLite is heavily used in almost every ecosystem so I would be really surprised if there were real blockers.

I know Android uses it a lot, so I opened up an Android project at my company and it looks like the android SDK comes with a bunch of SQLite abstractions, and it's not clear what the underlying driver is. But the SQLite official website ships an Android AAR so maybe that is it? (https://www.sqlite.org/2020/sqlite-android-3310100.aar)

This seems to be the main general-purpose JVM lib: https://github.com/xerial/sqlite-jdbc and it seems to be keeping in lockstep with the official SQLite versions (within a couple months).

Edit: Also can you elaborate on the "in a multiplatform way"? Maybe I'm having a brain-fart or memory-hole but shouldn't you not have to worry about that at all?

Edit2: Looks like there is a nice blurb in the docs on that github page:

  Since sqlite-jdbc-3.6.19, the natively compiled SQLite engines will be used for the following operating systems:

  Windows (Windows, x86 architecture, x86_64)
  Mac OS X x86_64 (Support for SnowLeopard (i386) has been deprecated)
  Linux x86, x86_64, arm (v5, v6, v7 and for android), ppc64
  In the other OSs not listed above, the pure-java SQLite is used. (Applies to versions before 3.7.15)

  If you want to use the native library for your OS, [build the source from scratch.

Re: What's Next for Scala

#179

Post by lcall »

therealdrag0 wrote: post #178
lcall wrote: post #175

Earlier quoted context omitted.

Right, it's more of a JVM issue which affects scala. I did a search a while (couple years?) ago and maybe just didn't find the right materials, but they all (in my now-vague memory) seemed awkward and/or were not portable across platforms. Does this approach let you do every kind of sqlite operation, as completely as if from the interactive native client or as if calling it from C? Who maintains it and is it kept in…

I don't really know the answer to those questions. But I know SQLite is heavily used in almost every ecosystem so I would be really surprised if there were real blockers. I know Android uses it a lot, so I opened up an Android project at my company and it looks like the android SDK comes with a bunch of SQLite abstractions, and it's not clear what the underlying driver is. But the SQLite official website ships an And…

I think I had found that one, but didn't actually try it. By multiplatform way, I meant avoiding native libraries (sounds like more maintenance and debugging over time) and still being able to run on OpenBSD (or any BSD), linux, windows, and mac, at least.

Edit: yes, I think it does not currently run on OpenBSD, etc. One could contribute that library, but in that case, I'm more inclined to learn Rust and not deal with the JVM at all. Then I also get convenient access to things like pledge() and unveil(), and other OS-specific system calls, when I want. :) I will be grateful, however, for further correction & enlightenment... :)

(Edit2: I have been reading "the book" in Rust, but probably should write a test to confirm that it will make calls to sqlite and pledge() as directly as I think, using the tools I found.)

Re: What's Next for Scala

#180

Post by maddening »

cutler wrote: post #150
sideeffffect wrote: post #144

Earlier quoted context omitted.

https://index.scala-lang.org/

Great. I stand corrected. How long has that been up? Last time I started with Scala it didn't exist.

More than 3 years. I've been using it for that long but it was pretty functional and full even 3 years ago.
Post reply on HN