|
ScalikeJDBC looks promising. It wont be async, but it looks better than Slick for my needs.
|
# ? Feb 17, 2015 15:39 |
|
|
# ? May 11, 2024 09:31 |
|
Basically, you need to use MongoDB if you want true reactive DB access. The other option is to wrap your DB access in a Finagle service and then access that in an asynchronous way, although that's really just hiding the problem.
|
# ? Feb 18, 2015 01:12 |
|
I guess Hystrix might be another option for making blocking calls less blocky. You'd also get circuit breaking. On that subject has anyone had any experience with Hystrix/Akka circuit breaker/other things of that ilk?
|
# ? Feb 18, 2015 07:30 |
|
Slick can be very good, especially if you use it with the code generation features. The documentation is ... a bit of a mess. If you're looking for a typesafe query language that understands that SQL does not always map to objects, and your project will be around long enough to warrant you investing the time in understanding Slick, then it will stand up to the job admirably. If you need to hack together some queries and pretend to be scala-like with some functors or monads or poo poo in there and hey why not concatenate some strings to form queries before you interpolate them, I wrote a filthy little hussy cowl of a library around JDBC that hides all the JDBC awfulness away away from your pure, lifted functional programming hands here: https://gist.github.com/lazyvalue/09a72f1ac5461578a2ea It's served me well for many ETL jobs when I just need to quickly dump parts of a data base I barely know anything about. It's useful and fairly hackable, but strongly in the 'roll your own category'
|
# ? Feb 18, 2015 08:49 |
|
jpotts posted:Slick can be such a PITA, and isn't very friendly for Scala newcomers. I looked at jooq, but I couldn't find a reason to use it over an ORM. If I dont want an ORM (let's say memory constraints, or speed, or whatever other bullshit reason), plain jdbc works just as well.
|
# ? Feb 19, 2015 21:21 |
|
triple sulk posted:The shortest answer for this is that it isn't worth it for companies to bring on developers who don't already know Scala incredibly well. It's not a language worth using in 2015 and you'd be better served by sticking with C# or trying out one of F#, Haskell, or Clojure. I was hired to write scala having not written a line of it. Sedro posted:JDBC isn't async so slick can't be async (of course you can still wrap the code in Future { ... }). I'd be careful with that http://stackoverflow.com/questions/22169757/asynchronous-transaction-causes-illegalstateexception/27263242#27263242
|
# ? Mar 16, 2015 20:26 |
|
Steve French posted:I was hired to write scala having not written a line of it. Are you in the Bay area, or a more normal city/place? What did you do before? Lots of Java?
|
# ? Mar 17, 2015 00:19 |
|
Generally speaking if you're hiring developers of any decent tier the cost of them acclimating to your language is dwarfed by the cost of them acclimating to your codebase, product, and way of doing things. Not to mention the cost of not making the hire yet, or having to settle for a dumber developer. Programming languages and your basic standard library are simple and trivially easy to learn. What's not, relatively speaking, is, say, "web development," or "core CS knowledge," because you wouldn't want to just hire some database engine developer to start making rails apps (or Go apps in my case) especially if there's no institutional knowledge between them (because then the cost isn't dwarfed). But if you've got one product and if it's pretty big then that's how things work, also I'd expect a company using exotic languages like Scala to expect to bring in developers that haven't personally used it before, because they'd be giving up on huge swaths of talent otherwise. The Bay Area or NYC are the few places you might even get away with the insane idea of requiring Scala experience.
|
# ? Mar 17, 2015 00:44 |
|
If anyone has used ScalikeJDBC, is there a way to use prepared statements for stored procedures? Below is the only way in which I can figure out how to run stored proc:code:
https://github.com/scalikejdbc/scalikejdbc/issues/59
|
# ? Mar 17, 2015 20:25 |
|
scalaz ownscode:
|
# ? Mar 17, 2015 21:21 |
|
b0lt posted:scalaz owns The symbolic class name is nice because you can use use infix e.g. Int ==>> String. Or if you prefer: type KeyValuePair[A, B] = A ==>> B The symbolic method is just an alias for a named method: code:
|
# ? Mar 17, 2015 22:02 |
|
More on the Slick / SQL in Futures discussion, Sefan Zeiger is talking about Reactive Slick at Scaladays Tomorrow:quote:Scoping database sessions correctly and configuring a connection pool in an efficient way were already non-trivial in blocking JEE-style applications, but if you try to fit the inherently blocking JDBC API into a Play or Akka app, it gets even harder. In the newest version of Slick, Typesafe's database library, we provide a different way of sequencing database actions, based on the ideas of Haskell's IO monad. This talk will show you how to use this new API to safely compose and execute database calls, returning Futures and Reactive Streams from them. Bridging the gap between the blocking JDBC API and your non-blocking applications also requires a very different threading model and connection pool configuration than in a blocking app. http://event.scaladays.org/scaladays-sanfran-2015#!%23schedulePopupExtras-6554 I'm going to a different talk in the same timeslot though. Also if anyone else is at the conference it would be great to say hi
|
# ? Mar 18, 2015 08:15 |
|
Spark 1.3 supposedly has an R or Pandas like dataframe. Has anyone used it yet?
|
# ? Mar 20, 2015 13:48 |
|
Cryolite posted:Are you in the Bay area, or a more normal city/place? The Bay Area. Before this, a lot of ruby, and before that, a lot of C. Basically, what sarehu said. If you are working in a relatively obscure language and looking for language experts rather than very smart people who can learn, you are doing it wrong. If it is a popular language, then maybe you can afford to be picky and only look for experienced people because there will be a lot more of them to choose from. If my situation is unique to the Bay Area, it's because everywhere else has gotten it wrong, not the other way around.
|
# ? Mar 20, 2015 16:41 |
|
Steve French posted:If my situation is unique to the Bay Area... It's not. It is somewhat unique to tech companies though. When an airline hires programmers they tend to do it through an HR department filled with people who print out forms to fax to people and they like simple rules like "ten years of python experience."
|
# ? Mar 21, 2015 04:14 |
|
KernelSlanders posted:It's not. It is somewhat unique to tech companies though. When an airline hires programmers they tend to do it through an HR department filled with people who print out forms to fax to people and they like simple rules like "ten years of python experience." Steve French and sarehu I agree with you completely but I'm finding the above is true for at least some companies near me. I talked to a place recently that was excited I'm learning Scala (since, they told me, they have trouble finding people who know it), but because I haven't used JRuby on Rails I don't qualify -- not even Ruby on Rails, which I do have some experience with, but specifically because I haven't worked with JRuby on Rails I don't qualify. However after talking with them a little bit I think the common refrain is true: I wouldn't want to work there anyway!
|
# ? Mar 21, 2015 17:02 |
|
I wonder if that's their intermediate step toward getting off Ruby.
|
# ? Mar 24, 2015 01:04 |
|
Do they commonly hire H1B workers? Maybe they're just intentionally setting requirements that can't be met? JRuby On Rails isn't even thing. That's just the term for Ruby On Rails with JRuby as the interpreter instead of MRI. You will basically never deal with JRuby unless you're doing something very specific and essentially unrelated to rails.
|
# ? Mar 27, 2015 16:01 |
|
b0lt posted:scalaz owns scalaz stuff is so cool, but man, gently caress operators. Why did they have to port Haskell's worst parts along with its best? Just name your goddamn methods with letters. There's a whole bunch of them right under your fingers! And they mean stuff!
|
# ? Mar 30, 2015 22:18 |
|
good jovi posted:scalaz stuff is so cool, but man, gently caress operators. Why did they have to port Haskell's worst parts along with its best? Just name your goddamn methods with letters. There's a whole bunch of them right under your fingers! And they mean stuff! I guess they're imagining people who want non-symbolic names would use the IMap alias and move on with their lives?
|
# ? Mar 31, 2015 03:13 |
|
Virtually every operator has an alpha alias. I'm inclined to agree with you in that I don't particularly care for symbolic soup, but I think it's fairly subjective or contextual. I would rather see a method named ~> than naturalTransformation.
|
# ? Mar 31, 2015 03:36 |
|
sink posted:Virtually every operator has an alpha alias. I'm inclined to agree with you in that I don't particularly care for symbolic soup, but I think it's fairly subjective or contextual. I would rather see a method named ~> than naturalTransformation. Why use two characters when you can use one like ↝? def Σ(x: List[Int]): Int = (0 /: x) (_ + _) KernelSlanders fucked around with this message at 05:15 on Mar 31, 2015 |
# ? Mar 31, 2015 05:13 |
|
KernelSlanders posted:(_ + _)
|
# ? Mar 31, 2015 07:18 |
|
pigdog posted:I don't even know Scala but you sold me on that operator. + is indeed a handy operator; you may find however that it is hardly unique to scala.
|
# ? Mar 31, 2015 17:45 |
|
Steve French posted:+ is indeed a handy operator; you may find however that it is hardly unique to scala. Is there a butt emoji? It should expand to (_*_) the same way ⇒ does to =>.
|
# ? Apr 1, 2015 01:16 |
|
+ isn't really an operator in scala, just an infix notation method call. (_+_) is syntactic sugar for (a, b) => a.+(b)
|
# ? Apr 1, 2015 02:36 |
|
b0lt posted:Is there a butt emoji? It should expand to (_*_) the same way ⇒ does to =>. 🍑
|
# ? Apr 1, 2015 02:54 |
|
KernelSlanders posted:+ isn't really an operator in scala, just an infix notation method call. (_+_) is syntactic sugar for (a, b) => a.+(b) Also for what it's worth, Scala doesn't have a specific class of operators. Any method which takes a single argument can be called as an infix operator. Generally names are chosen so that they flow like a sentence. Function1 has a method called 'andThen' which takes a second Function1 and returns another Function1 which is the first andThen the second. PartialFunction's orElse calls an alternative PartialFunction if the first doesn't apply.
|
# ? Apr 2, 2015 13:09 |
|
KernelSlanders posted:+ isn't really an operator in scala, just an infix notation method call. (_+_) is syntactic sugar for (a, b) => a.+(b) I was mainly pointing out that the expression (_ + _) is not itself some single operator but rather a composite of multiple things. I know that scala doesn't have "operators" in the same sense as some other languages, but still in languages where "operators" are just methods with those names they're usually still referred to as operators. However, it is not quite the case as you imply that + and other "operator like" methods are just normal methods. Scala defines "operator characters". There are still special cases. Specific to your comment, there's a reason why 1 + 1 * 2 == 2 * 1 + 1 +, -, *, and the like are handled specially when periods and parentheses are omitted to maintain expected operator precedence. Some other special cases:
Steve French fucked around with this message at 16:33 on Apr 2, 2015 |
# ? Apr 2, 2015 16:30 |
|
edit: wrong ssl implementation
DholmbladRU fucked around with this message at 15:17 on May 5, 2015 |
# ? May 4, 2015 19:10 |
|
I've been a Java (and to a lesser extent a C#) programmer for awhile, and about two years ago I took a job programming in Scala. I liked Scala the language, but I got frustrated with a small but extremely vocal portion of the Scala community (among which were some of my co-workers), namely Haskell programmers who wanted Scala to be exactly like Haskell. For example, we'd have a bunch of big rear end thread-local objects, and every time we updated a field we'd have to copy the entire object because Everything Must Be Immutable Just Like In Haskell, and then we'd wonder why the garbage collector was running too often. Or during a code review I'd be criticized for using classes instead of using whatever the Haskell-ish equivalent would be. Another problem is that we couldn't just use a mature Java library for something (the library might return nulls!), we had to hunt for an alpha Scala library instead. When the startup eventually went bankrupt I went back to Java.
|
# ? May 5, 2015 06:59 |
|
A ha ha, yep, you got the cargo-cult functional programmer (as forums poster rjmccall put it) experience. Thes people have done a lot of damage to Scala and other new languages, it's one of the few good reasons for Go not to have generics.
|
# ? May 5, 2015 07:22 |
|
Smug Haskell Weenies
|
# ? May 5, 2015 07:24 |
|
loinburger posted:For example, we'd have a bunch of big rear end thread-local objects, and every time we updated a field we'd have to copy the entire object because Everything Must Be Immutable Just Like In Haskell, and then we'd wonder why the garbage collector was running too often. There's no reason to copy an entire object around just to maintain immutability. What kinds of objects were these? Deus Rex fucked around with this message at 07:48 on May 5, 2015 |
# ? May 5, 2015 07:45 |
|
These were usually plain old objects representing database records, so they might have a few dozen strings or byte arrays in them that were being unnecessarily copied when we modified a field
|
# ? May 5, 2015 07:49 |
|
Also even ideally you're going to have have a logarithmic multiplier on the amount of copying you do. Edit: But if they're strings or byte arrays and they're being used immutably, why do you need to copy them?
|
# ? May 5, 2015 08:02 |
|
Deus Rex posted:There's no reason to copy an entire object around just to maintain immutability. What kinds of objects were these? Yeah, usually it's done with magic like fully persistent data structures and the like. It's usually something that's very difficult or time consuming to redo as a programmer, and is best left as an actual language feature.
|
# ? May 5, 2015 08:08 |
|
sarehu posted:Also even ideally you're going to have have a logarithmic multiplier on the amount of copying you do. We usually wouldn't have copied the strings or byte arrays or whatever - that would have been bonkers enough for me to put my foot down (something I'm disinclined to do because it rarely works). What we were doing was a bit less stupid and wasteful. We'd get a JSON string with a record identifier and a bunch of fields that need to be updated, so we'd read the record into an object, iterate through the JSON and make updates to the object, then write the resulting object back to the database. Because Everything Has To Be Immutable, this means that instead of reading the object into memory and making in-place updates to it, we were making a copy of the object on each update, and given the number of fields in the objects this meant we were wasting at least a kilobyte and up to ten kilobytes on each copy. Granted, not the most egregious waste of memory I've ever seen, but still frustrating given how easily we could have avoided it just by using vars instead of vals.
|
# ? May 5, 2015 13:42 |
|
Currently I am implementing a web service with Scala using Spray i/o. Looking to use SSL to secure my requests.The issue is that when an HTTPs request is made to the api I get a tuncation attack error. code:
code:
code:
code:
code:
DholmbladRU fucked around with this message at 16:22 on May 6, 2015 |
# ? May 5, 2015 17:40 |
|
|
# ? May 11, 2024 09:31 |
Argh. I am trying to do a "manual install" of sbt, but it's still trying to reach out to the internet. What gives?
|
|
# ? May 6, 2015 21:06 |