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

191–200 of 265 posts

Re: Scala Native

#191

Post by dsabanin »

cutler wrote: post #109
dsabanin wrote: post #63

Earlier quoted context omitted.

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

Can you elaborate on this OOP for big code bases argument as I've seen it wheeled out in defence of Java and PHP5 many times but I just don't buy it. Often classes in OOP languages are used not for instantiating objects, which I would argue is their raison d'etre, but simply to encapsulate some data and a bunch of methods. What advantage does this have over simply using your language's namespacing properly? In Clojur…

I'd just say that objects are more powerful constructs than structs, records and simple shapeless datastructure. They enforce structure on your data, and give you at least some clues what you can do with that data, among other things.

After writing and maintaining a bunch of code in Clojure, Erlang and functional style Ruby, I feel like OOP+FP gives me greater flexibility in my design options and allows to architect better solutions to my problems.

Re: Scala Native

#192

Post by airless_bar »

avita1 wrote: post #182
airless_bar wrote: post #51

Earlier quoted context omitted.

No, not really. Some people from losing ecosystems like to spin it that way¹, but the truth is people are happy, adoption is great, and companies see that pain-points get addressed. Of course there are companies which drop Scala, but often like in LinkedIn's case it's not caused by a dissatisfaction with Scala, but new leaders making different decisions like "we are using 10 different languages, we should consolidate…

I like Scala, and this is purely anecdotal: but with Java 8 becoming pervasive and large companies adopting Scala style guides that recommend most of the advanced features away [1], Scala becomes a less compelling choice. Sure, companies aren't dropping existing code in Scala, but I would be surprised if large organization were to push for new code to be written in Scala instead of Java 8. Edit: link [1] https://gith…

There are worlds between Java 8 and Scala and the gap is widening with every release.

Of course you can write Java in Scala and then the benefits over Java aren't that high (but are still there), but Scala is so far ahead in terms of language compared to Java that most current Scala libraries just _can't exist_ in Java.

Adoption these days seems to be great and accelerating, and given the growth of the library ecosystem there are more and more reasons to leverage the benefits of libraries written in Scala especially compared to legacy stuff written in Java.

Re: Scala Native

#193

Post by saosebastiao »

runT1ME wrote: post #174
saosebastiao wrote: post #82

Earlier quoted context omitted.

> It's pretty well known that Scala was heavily influenced by Haskell. Except that Martin Odersky himself has explicitly said that the primary influences were SML/OCaml and Java. > In particular, do notation (for comprehensions), I'll give you that one > pattern matching Which pre-date Haskell by nearly 2 decades in ML > lots of standard lib classes (ex Maybe (Option)), Also pre-date Haskell by nearly 2 decades, in a…

Given the fact that OCaml seems to be adding type class support and has support for monadic comprehension (do/for), it seems like these ideas are getting adopted in multiple places. As a Scalaz committer and as a developer working at one of the largest scala shops (that makes heavy use of Scalaz), we don't try to write Haskell on the JVM. We do try to write pure, functional code as much as we can, and so what we end…

> OCaml seems to be adding type class support

Funnily enough, Scala's implicit-based type classes were the inspiration for the coming modular implicits type classes in OCaml (as opposed to the Haskell approach). It wouldn't be the first time that two languages have mutually inspired each other (The Rust and Swift teams have both acknowledged certain design decisions inspired by the counterpart).

Re: Scala Native

#194

Post by jfoutz »

acjohnson55 wrote: post #189
airless_bar wrote: post #114

Earlier quoted context omitted.

Scala macros are compile-time. The Scala reflection library (that works at runtime) share most API with macros. Macros should always work, reflection is harder as some information needs to be retained at runtime (either via Java reflection or additional data – which can both be problematic in Scala.js).

And as the original author of Scala.js pointed out in a Scala Days talk today, unrestricted reflection means that it's impossible to do dead code elimination, which is a non-starter for real-world use.

I've got at least 30 enterprise applications that disagree with your "nonstarter" assertion. Dead code can only exist in real world code.

Re: Scala Native

#195

Post by [deleted] »

acjohnson55 wrote: post #189
airless_bar wrote: post #114

Earlier quoted context omitted.

Scala macros are compile-time. The Scala reflection library (that works at runtime) share most API with macros. Macros should always work, reflection is harder as some information needs to be retained at runtime (either via Java reflection or additional data – which can both be problematic in Scala.js).

And as the original author of Scala.js pointed out in a Scala Days talk today, unrestricted reflection means that it's impossible to do dead code elimination, which is a non-starter for real-world use.

[deleted]

Re: Scala Native

#196

Post by paulddraper »

acjohnson55 wrote: post #189
airless_bar wrote: post #114

Earlier quoted context omitted.

Scala macros are compile-time. The Scala reflection library (that works at runtime) share most API with macros. Macros should always work, reflection is harder as some information needs to be retained at runtime (either via Java reflection or additional data – which can both be problematic in Scala.js).

And as the original author of Scala.js pointed out in a Scala Days talk today, unrestricted reflection means that it's impossible to do dead code elimination, which is a non-starter for real-world use.

Well, Proguard does whole program optimization.

You have to specify the symbols to preserve explicitly.

Re: Scala Native

#197

Post by incepted »

airless_bar wrote: post #156
incepted wrote: post #106

Earlier quoted context omitted.

> Swift where things get added at a frightening rate. Things are always added at a frightening rate when a language is young. Happened for C#, happened for Scala, happens for all languages. Not really something to worry about.

The difference is that Scala devs didn't push for immediate adoption while they were still working things out. Apple's Swift message is more or less "Stop writing Objective-C if you can and start using Swift – oh and by the way – you will have to rewrite your code with every major Swift release which we will be releasing at a rapid schedule". It will be very hard for Swift to get rid of all the cruft they accumulate.…

> In Scala every major release addresses one or two pain points and migration is very smooth – no "rewrite all your stuff".

Yes, the Java way. Take ten years to implement basic stuff.

I much prefer Swift and C#'s approach to this: first major version bump, things get deprecated. Second bump, they get removed. It worked great for C#, it's going to work great for Swift, which has already seen incredible adoption on iOS.

Scala is moving at a glacial pace in comparison, really not worth bothering with.

Re: Scala Native

#198

Post by pfarnsworth »

kod wrote: post #172
pfarnsworth wrote: post #128

Earlier quoted context omitted.

I specifically said the Scala clients are being deprecated. Go ask Neha to confirm this.

No, you specifically said they're being deprecated because of maintainability issues inherent to scala, which is not true.

Nope. They were getting sick of having to maintain different versions of the Scala clients because of breaking changes, as per a Kafka committer.

Re: Scala Native

#199

Post by incepted »

dragonwriter wrote: post #164
bad_user wrote: post #163

Earlier quoted context omitted.

Scala.net didn't die because it was academic. It died due to lack of interest, as nobody cared about a Scala for .NET

ISTR a significant reason it died was the .Net platform's reified generics, which made making a language with generics and a type system more expressive than the underlying platform problematic, and especially made it difficult to have something that would be fully compatible with Scala-on-the-JVM.

Exactly.

It died for technical reasons because .net supports reified generics, which made it pretty much unable to support Scala's type system.

People who keep saying that erased generics is a stupid idea have no idea what they're talking about.

scala-native is facing insurmountable difficulties, the kind that will certainly not be conquered by a single student who will stop working on it as soon as he graduates.

Re: Scala Native

#200

Post by grandinj »

Given that Apache harmony is no longer being developed, you might want to coordinate with the Avian people, since they also reuse harmony.
Post reply on HN