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

Scala Native

github.com

Post reply on HN
Print view View original

61–70 of 265 posts

Re: Scala Native

#61

Post by airless_bar »

the_af wrote: post #55
hibikir wrote: post #34

Earlier quoted context omitted.

Because all the other languages mentioned are better only from very specific perspectives. Scala's strength is precisely that it's a mutt: Want to write imperative code? Sure. Functional? No problem. How about a type system that far more featureful than Go? That works too. Scala gets a bad rap precisely because people are big fans of their own way of writing code, call it better, and think that anyone that wants some…

Note: I use Scala in my day job. I consider it better than Java, but worse than other languages. I definitely agree that all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable. That said, in my opinion Scala's blunders are many. You can find out about many of them from Paul Philips, ex committer of Scala, but if he sounds too bitter to you (he does to me; at this point he sounds lik…

> all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable.

Scala devs deprecate and remove things that haven't worked out well. They have an established track record of making these migrations easier with each release.

> Null

Upcoming versions will make references non-nullable by default. If you want things to be nullable, you will have to opt-in explicitly with T|Null.

> - Type inference

Type inference is not a huge priority, because people think that it's a good thing that declarations require type annotations (just like it's recommended in Haskell, too). One of the last pain-points, higher-kinded unification of type constructors, has been fixed recently which will make type inference "just work" in exactly those cases where the lack of type inference was most annoying.

> - Tooling

I think tooling is pretty amazing. Sure, Java has still some advantages in some places. But the tooling is superior to almost all other languages out there. SBT is amazing. IDE support is getting vastly better, not only have Eclipse and IntelliJ improved vastly, but also IDE support for Emacs, Vim, Sublime, etc. is coming along at a rapid rate, and it's just amazing to use. There are so many tools in the Scala ecosystem which just don't exist in this combination anywhere else.

Re: Scala Native

#62

Post by kbenson »

int_19h wrote: post #44
kbenson wrote: post #28

Earlier quoted context omitted.

val label = "The width is " val width = 94 val widthLabel = label + width I really wish more languages would distinguish concatenation from addition, especially when they do type coercion. There's a very specific reason Perl opted for '.' to concatenate strings instead of +, which is that it disambiguates the following: val first = "2" val second = 3 val together1 = first + second val together2 = second + first Not t…

'+' works great as a concatenation operator, so long as you don't ever try to implicitly convert the values. Case in point - Python: >>> 1+2 3 >>> "1"+"2" '12' >>> "1"+2 Traceback (most recent call last): File " ", line 1, in TypeError: Can't convert 'int' object to str implicitly

Those are literals, not variables. My whole argument is about the ambiguity introduced when you are implicitly coercing variables. But yes, if the language does not coerce between string and numeric types, it's a non-issue. I'm specifically talking about supporting coercion but continuing to use '+' for concatenation of strings (and ==/!= for equivalence testing of strings as well).

Re: Scala Native

#63

Post by dsabanin »

the_af wrote: post #47
dsabanin wrote: post #27

Earlier quoted context omitted.

Haskell seriously lacks mature tooling, like IDEs, and also libraries. It's still a niche language and it suffers from that. I think it's pretty clear it's not going anywhere close to mainstream any time soon.

That's debatable. Some tooling is needed, some (like IDEs) are mostly unnecessary; crutches we're used to because some languages are unbearable to use otherwise. IMO it's a niche language because, unlike Scala, it requires a clean break from the way the mainstream industry sees programming languages. But don't mistake that for lack of practicality!

I don't subscribe to the point that IDEs are crutches any more. I don't rely on IDEs to generate code for me, I use them to explore code and refactor it efficiently.

Good refactoring support in IDE can save you a lot of time and errors, especially in the statically typed languages. It has nothing to do with language being unbearable, but a lot to do with the size and complexity of the code you have to work with.

I have nothing against Haskell, and before sticking with Scala I've seriously considered it. However, having things like Akka in Scala, an actor/OTP framework that is the only one that is even remotely comparable to what Erlang has, was a huge benefit.

Other tools like Play, Spark also made choosing Haskell an unpractical decision for me.

Besides, after a couple years of excursion into pure FP-only approach to development, I've understood to myself that OOP is not in any way in opposition to FP, but can be a rather welcome addition. Especially when you work with big code bases and you plan to maintain them for many years to come. And that is an area where Scala really shines.

Re: Scala Native

#64

Post by edko »

kbenson wrote: post #60
edko wrote: post #32

Earlier quoted context omitted.

You can also use: s"The width is $width"

Which is good, but interpolation is really just a specialized case of concatenating string literals and variables, not variables to other variables, which is where some ambiguity is introduced.

You can also do s"$varOne$varTwo" and that concatenates two variables.

Re: Scala Native

#65

Post by kod »

lauriswtf wrote: post #50
airless_bar wrote: post #42

Not the author: > - Can this reuse existing Scala code? I think that's the plan. Would be a pretty pointless exercise without that, right? :-) > - How does it compare against Rust/GO/Swift? Why use this over them? Rust: Scala and Rust have different niches. Rust is more focused on low runtime overhead, while Scala is more focused on low development overhead. This means Rust can be potentially faster to run, but Scala…

A small side note: Scala has several great features, but "low development overhead" just isn't one of them. Also why so harsh on Go?

If by low development overhead you mean amount of crap you need to type in order to get things done, Scala absolutely does have low development overhead.

As for Go, I'd say that's the most honest description of the language I've seen in a while.

Re: Scala Native

#67

Post by jjuel »

abc_lisper wrote: post #49
airless_bar wrote: post #42

Not the author: > - Can this reuse existing Scala code? I think that's the plan. Would be a pretty pointless exercise without that, right? :-) > - How does it compare against Rust/GO/Swift? Why use this over them? Rust: Scala and Rust have different niches. Rust is more focused on low runtime overhead, while Scala is more focused on low development overhead. This means Rust can be potentially faster to run, but Scala…

> Go: Go is utter shit that only survives due to the devs name-dropping "Google" every 5 minutes Woah!

Clearly people either love or hate Go. There is a lot of hate I've seen on HN. I personally love it, but who am I to say what is a good language and what isn't.

Re: Scala Native

#68

Post by lauriswtf »

whateveracct wrote: post #53
lauriswtf wrote: post #50

Earlier quoted context omitted.

A small side note: Scala has several great features, but "low development overhead" just isn't one of them. Also why so harsh on Go?

Why do you say low development overhead isn't one of them? Outside of the one-time cost you pay to learn the language (which is higher than Go and most languages), Scala makes it super easy to write correct code quickly. The developer workflow of incremental compile + REPL + unit tests is great.

Probably depends on the code base, but having worked with Scala for a few years, there are a lot of things that causes development overhead. First things that come to mind: slow compile times, there are usually several ways to do one thing and also docs/guides are inconsistent, overused operator overloading in libraries (almost have to learn new DSL syntax for some libs), and it is not always easy to comprehend code by other developers.

Re: Scala Native

#69

Post by placeybordeaux »

airless_bar wrote: post #42

Not the author: > - Can this reuse existing Scala code? I think that's the plan. Would be a pretty pointless exercise without that, right? :-) > - How does it compare against Rust/GO/Swift? Why use this over them? Rust: Scala and Rust have different niches. Rust is more focused on low runtime overhead, while Scala is more focused on low development overhead. This means Rust can be potentially faster to run, but Scala…

>Go: Go is utter shit that only survives due to the devs name-dropping "Google" every 5 minutes.

Making blanket statements like that without any substantiation makes me want to just write off everything else you have said.

Re: Scala Native

#70

Post by kbenson »

edko wrote: post #64
kbenson wrote: post #60

Earlier quoted context omitted.

Which is good, but interpolation is really just a specialized case of concatenating string literals and variables, not variables to other variables, which is where some ambiguity is introduced.

You can also do s"$varOne$varTwo" and that concatenates two variables.

Yes, as an alternate syntax, interpolation works well to disambiguate your intent, which supports my point. It's really just a highly specialized form of a different operator, which says I work on strings, so anything I see that isn't a string coerce to a string. For example, in Perl

    $varOne . $varTwo
Is entirely equivalent to

    "$varOne$varTwo"
The question is why Scala chose to use + when it had other, non-ambiguous options, like above.
Post reply on HN