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

Towards Scala 3

scala-lang.org

Post reply on HN
Print view View original

341–350 of 383 posts

Re: Towards Scala 3

#341

Post by pjmlp »

eweise wrote: post #269
stusmall wrote: post #172

Earlier quoted context omitted.

Kotlin and Java 8. I started using Scala in Java 7 era and loved it. When Java was stagnating it seemed like an alternate language that targeted the JVM was the best option. Progress with the language has really picked up a lot. There is a lot that Scala has that Java doesn't, but now its not enough to make it worth it. Java is so much easier to work with on a large team.

The two languages though also have preferred libraries / frameworks. I code in Java again and the main thing that bugs me is being always in the Spring ecosystem. There is a mindset in javaland that every technology needs to be wrapped by Spring. Scala gave me the freedom to choose alternative libraries.

Depends where you work.

I know Java since the early days and only used Spring during one month as validation of an architecture proposal.

Re: Towards Scala 3

#342

Post by didibus »

joshlemer wrote: post #308
nextos wrote: post #300

Earlier quoted context omitted.

I don't think CL is attracting a lot of new developers or there's a lot of new libraries getting developed. But I would be glad to be proven wrong. Perhaps Racket will eventually become a CL replacement, now it's adopting a lot of Chez low-level stuff and it's multiparadigm efforts keep growing.

Do you have any ideas why Racket has not had the commercial success of Clojure for example?

My guess would be the JVM. Racket is an academic language, designed for academia. At least it markets itself as such. Made to explore the design space of programming languages.

Clojure was designed and marketed for the enterprise. Builds on the JVM, full Java interop, emphasis on pragmatism.

Re: Towards Scala 3

#343

Post by lmm »

yawaramin wrote: post #328
lmm wrote: post #298

Earlier quoted context omitted.

I don't like having to give up full type inference, but it's much better than having to give up HKT.

You 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.

Up 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.

Re: Towards Scala 3

#344

Post by lmm »

setr wrote: post #315
lmm wrote: post #192

Earlier quoted context omitted.

The reality is that a language lives or dies by its ecosystem - particularly when it comes to a language like Scala that's in a tightly symbiotic relationship with its IDEs (the next time someone tries to sell you a "visual programming language", look at Scala for a language that makes really effective use of the GUI for programming without compromising the things that make textual programming languages good - see e.…

I'm not sure I see anything in that post that's tied to scala in particular, or even really visual programming. Are you referring to the hints? The parameter names hints seem to be result of having functions in general, and type hinting look like a direct result of static typing; I like the idea, but it doesn't appear to me to be tied to Scala the language at all. It looks like its just tied to the jetbrains ide

The macro expansion is more tightly tied to Scala itself, as are things like showing implicit parameters. To a certain extent the things you mention are generic things, but Scala pushes type inference further than other languages that that IDE supports and makes more use of static types in general, so the IDE might well not have bothered with the type hints without Scala. Likewise Scala makes fuller use of named parameters than many languages (in Java parameters have names but you can't pass them with name=value syntax).

Re: Towards Scala 3

#345

Post by YorkshireSeason »

philipwhiuk wrote: post #304
YorkshireSeason wrote: post #227

Earlier quoted context omitted.

What is your main complaint with implicits? If you don't like them, why don't you add "Use of implicits forbidden" to your coding style guidelines, and check in code-reviews, and add a "grep implicit" check to your CI setup that refuses to commit Scala code with implicits? Let me paraphrase M. Odersky's PLDI 2017 keynote: The essence of Scala is implicits You can find it at https://www.youtube.com/watch?v=br6035SKu-0

> If you don't like them, why don't you add "Use of implicits forbidden" to your coding style guidelines, and check in code-reviews, and add a "grep implicit" check to your CI setup that refuses to commit Scala code with implicits? Because Scala libraries that do useful stuff are infested with them. Akka loves the things. > main complaint They obscure complexity, pretending that complex stuff is simple. It makes simp…

> Akka loves the things.

So? Treat Akka as a black box. You can always explicitly pass implicit arguments.

Re: Towards Scala 3

#346

Post by YorkshireSeason »

ionforce wrote: post #284
YorkshireSeason wrote: post #190

Earlier quoted context omitted.

> Have you spent any time at all using them? Sure I have used both. Default arguments and implicits both have the same key idea: you can omit arguments to functions, and the compiler, guided by type information, synthesises the missing arguments during compilation. In order to understand the difference between both, it is crucial to realise that this compile-time synthesis of missing arguments has two related but dif…

Maybe a disagreement here is fueled by the power level difference in these two features. Beyond the superficial injection examples, Scala implicits also support injecting values constructed dynamically and also recursive/derived implicits.

> injecting values constructed dynamically

You can also do this with default arguments, e.g. like so:

   let f x y = 
      let g (a = x+1) b = ...
      ...
For example the following is valid OCaml:

   let bump ?(step = 1) x =
     let waa ?( a = step+17 ) b = a * b in
     x + step + waa 666;;
Here the function waa has a default argument whose default argument depends on bump's default argument.

> recursive/derived implicits

Recursion is quite restricted, for example this is not valid Scala:

    def f ( x : Int ) ( implicit y : Int ) : Int = {
      implicit val a = 17
      f ( x+1 ) }

Re: Towards Scala 3

#347

Post by YorkshireSeason »

lmm wrote: post #296
YorkshireSeason wrote: post #190

Earlier quoted context omitted.

> Have you spent any time at all using them? Sure I have used both. Default arguments and implicits both have the same key idea: you can omit arguments to functions, and the compiler, guided by type information, synthesises the missing arguments during compilation. In order to understand the difference between both, it is crucial to realise that this compile-time synthesis of missing arguments has two related but dif…

> Default arguments and implicits both have the same key idea: you can omit arguments to functions, and the compiler, guided by type information, synthesises the missing arguments during compilation. Saying implicits are a generalization of default arguments because they're both synthesized during compilation is like saying steam trains are a generalization of pipes because they're both made of metal. It elides too b…

I'm not saying implicits and default parameters are the same thing. I'm saying the key idea behind implicits is the realisation that default arguments merge two ideas that should be kept separate, if we want context dependent defaults. Some of implicit's other features can (and have been) added to default arguments, see my other reply.

Re: Towards Scala 3

#348

Post by YorkshireSeason »

gaius wrote: post #148
jrq wrote: post #122

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 n…

The 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

I'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.

Re: Towards Scala 3

#349

Post by jvican »

threeseed wrote: post #310
lmm wrote: post #297

Earlier quoted context omitted.

I 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.

Not quite so simple to just use other options. ScalaJS for example mandates the use of SBT.

Not really. https://github.com/random-maven/scalor-maven-plugin

Re: Towards Scala 3

#350

Post by AsyncAwait »

Cyph0n wrote: post #265
AsyncAwait wrote: post #252

Earlier quoted context omitted.

> Both me and the parent were referring to Native. I know. So they are charging for a Kotlin Native debugger, no? No, Kotlin Native can interface with GDB or LLDB, they're charging for CLion which provides a GUI interface atop of these. > Do they provide a GDB fork or something that can use without CLion? No need to fork, you just won't have the frontend that Clion provides.

> I know. So why did you refer to Kotlin on the JVM? > No, Kotlin Native can interface with GDB or LLDB, they're charging for CLion which provides a GUI interface atop of these. Cool, thanks for the response.

> So why did you refer to Kotlin on the JVM?

Because I was trying to explain that the only reason Kotlin/Native is tied to (paid) CLion is because that's the only IDE where JetBrains have native GDB/LLDB integration, not that they charge for a debugger, which is demonstrated by the fact that where there would be the most potential customers, (JVM Kotlin users), they don't charge anything. The only reason they charge here, is because Clion is primarily a C/C++ IDE, (which explains why they have the GDB integration there) and they want to sell that, (the C/C++ IDE), but given the debugging integration, it's also the best IDE to integrate with Kotlin/Native, (which is free, but the C++ IDE is not), where they have a free offering, (Intellij CE on the JVM), they charge nothing even for the debugging GUI for Kotlin. This is further demonstrated by the fact that their Rust plugin doesn't require CLIon for its IDE features, (even open-source IDEA will do), only if you ALSO want the debugging GUI, you have to go with CLion, a paid C++ IDE.

In other words, I am trying to get this idea across that:

1. The Kotlin/Native plugin is free. 2. The only IDE Jetbrains have with GDB integration is CLion. 3. CLion is a paid IDE for C/C++, not Kotlin. 4, Kotlin/Native plugin can only work with CLion for technical reasons, see 2. 5. Because CLion is paid and Kotlin/Native plugin work only with CLion, it happens to come out to you having to pay for CLion to get the Kotlin/Native plugin working. 6. That does not mean that Kotlin/Native or the Kotlin/Native plugin themselves are paid products, they're not, nor are Jetbrains charging for access to the debugger itself.

Post reply on HN