Earlier quoted context omitted.
I'm on exactly that kind of team now. They've been working on a very simple problem for several years now and have an enormous, sophisticated, but still buggy and unstable solution. They're really smart people, and they had to be extremely capable programmers to get this far, but the embarrassing question is, how would a team of mediocre developers have tackled this problem? They would have picked a mediocre language…
I am continually perplexed at the swallowing of exceptions in certain FP communities. Result types, Either et cetera make it extremely easy to swallow errors by flatMapping thoughtlessly losing the context of where they were - you typically /want/ the call stack when you hit into an exceptional flow.
From First Principles: Why Scala?
121–130 of 342 posts
Re: From First Principles: Why Scala?
#122> In contrast, cross-compilers for dynamic languages like Clojure tend to have a long-list of caveats and incompatibilites I don't think the author fully comprehended the linked resource (namely https://clojurescript.org/about/differences ). Perhaps he just noted the its size. A good chunk of the document lists things in common, not differences. The actual differences have nothing to do with dynamic typing and are de…
> - don't pretend the JVM and JS have identical runtimes when it comes to concurrency or numerics. Clojure is a language, not a platform abstraction. > - Emit efficient, optimally minifiable javascript code, at the cost of offering something less traditionally lisp-y when it comes to eval, macros, and other forms of code loading. Those are still possible, but some discipline is imposed. This is exactly the kind of th…
How can those possibly be abstracted away and unified? If doing so, what would have the solution have to do with type inference at all?
i.e., this is simply a difference in how one approaches platform interop (raw vs abstracted/unified). Clojure occasionally offers cross-platform abstractions (e.g. core.async) but it's not its main philosophy.
Re: From First Principles: Why Scala?
#123If I've said it once I've said it a thousand times: the day Scala kills sbt officially will be the day thousands of devs consider a return to it. Until then, I couldn't dare.
Re: From First Principles: Why Scala?
#124Earlier quoted context omitted.
Tell that to Amazon, Apple, Netflix, Cognitect and all enterprises that produce reliable and performant software with it everyday.
I don’t know of anyone at those companies using clojure and I haven’t seen any tech blogposts by those companies about using clojure. If clojure exists at those companies I imagine it’s a small very niche team.
Re: From First Principles: Why Scala?
#125Re: From First Principles: Why Scala?
#126I am a Scala programmer & think it's a great language. Here are some arguments for why not Scala: * Li's libs (os-lib, upickle, utest) have clean public interfaces, but most Scala ecosystem libs are hard to use, see the JSON alternatives for examples: https://www.lihaoyi.com/post/uJsonfastflexibleandintuitiveJS... * The Mill build tool looks a lot better than SBT, but seems like everyone is still using SBT * Scala mi…
Let's clarify some points for folks not so familiar with Scala. > * Scala minor version are binary incompatible, so maintaining Scala projects is a big pain. Upgrading Spark from Scala 2.11 to Scala 2.12 was a massive undertaking for example. Scala just chose a strange naming scheme. Other languages would have just increased their major version instead. The scala minor version is increased every few years and not eve…
values: DataValue
?Otherwise the decoder is incorrect and, I'm not 100% sure but, is likely to throw a runtime error.
Re: From First Principles: Why Scala?
#127I dabbled with Scala several years ago, but I've been using Kotlin for a JVM-based project and am happy with it. My main reason for choosing Kotlin is smoother interop with the JVM world. For example: - Scala adds an Option type, whereas Kotlin adds nullability checking for existing object types. - Scala has its own convention for getters and setters, whereas Kotlin automatically turns JVM getters and setters into pr…
And that is a huge benefit. Scala collections are really great.
In addition, Scala also has wrappers around Java collections for interop, or you can just use plain Java collections directly.
Re: From First Principles: Why Scala?
#128I loved Scala until a minor version updated somewhere around 2.9-2.11 destroyed all my hope. Eight years later I still refused to use it to build anything. Yet, with that said, IMHO, it can be fucking great _second_ language. If you haven't used a statically typed language before, i.e. you're from Ruby, JS, Python, et. al then it's one bangin' ass brain rodeo. I'd highly recommend spending a couple months trying to l…
Dang. I just checked in the Common Lisp I use and it's a bit higher. What's the reason for having to have at least 22 concrete function signatures like that?
CL-USER> call-arguments-limit
4611686018427387903 (62 bits, #x3FFFFFFFFFFFFFFF)Re: From First Principles: Why Scala?
#129Re: From First Principles: Why Scala?
#130Earlier quoted context omitted.
What newer hybrid languages besides Kotlin can cover the benefits you can get with Scala: a solid ecosystem (both for Scala and Java) for developing web applications, microservices, data processing, and good performance. Julia, Rust, and Elixir are all great, but popularity, ecosystem are not there yet.
F#
Scala and F# are sinilar enough to basically be the same language, though I found F# had a number of warts and idiosyncracies that made me move on to Scala. Scala didn't have all of these (though of course it had warts of its own!) and is what stuck with me for the long term