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

Reasonable Scala Compiler

github.com

Post reply on HN
Print view View original

151–160 of 161 posts

Re: Reasonable Scala Compiler

#151

Post by simon_o »

majidazimi wrote: post #60
iLemming wrote: post #53

Earlier quoted context omitted.

> even though that's not difficult Turns out to be quite arduous: - You ask for reasonable support for both object-oriented and functional programming, this already contradicts with the notion of state (that objects suppose to contain in OOP) and "stateless" ways of FP, let's ignore that for a moment - FP means different things for different people - some would argue it has to have well thought type system, but what…

I would argue Scala already has all of them but the last one. However there are shit load of absolutely unnecessary features in the language. As the parent link states, twitter just removed shitty features and there you go: An easy to use Object/Functional language which runs fast and has awesome concurrency features.

Which ones would you remove?

Re: Reasonable Scala Compiler

#152

Post by simon_o »

dtech wrote: post #149
simon_o wrote: post #96

Earlier quoted context omitted.

There are also specs for later versions, it's just that they are pretty outdated and unmaintained. (Like pretty much everything related to documentation.) I think Jetbrains has some experience using that spec to implement the IDE's Scala typechecker. Long story short: years later, it still doesn't work. I would be kind of concerned about the esoteric new features they added to Dotty, looks like the lesson has not bee…

They removed the esoteric features because they could not be theoretically proven sound, not added them.

Just off the top of my head, esoteric additions:

- "Numeric harmonization" which makes some of the existing issues with implicit numeric conversions even worse.

- Multiversal equality, which adds even more special rules to the implicit resolution algorithm, complicates the mental model of the language, is either extremely invasive or severely limited when applied to real-code, and falls apart when dealing with existing language features of Scala like variance.

- Addition of inline, which has absolutely no reason to be a new keyword.

- The tentative idea of adding T? for T|Null (as it appeared on some slides) which makes it obvious that no thought has been given to how the lessons of handling nulls apply to Scala.

Then we have enums, which are just poorly designed and executed, repeat the mistakes made with both case classes and scala.Enumeration, do not address the problems it is supposed to solve, fail to address actually valid existing problems, all while introducing not one, but two additional syntactic constructs which are unlike anything we had before.

On top of that we got incompatible additions in minor releases of 2.12:

- Additional places where commas can be added, which ignores one of the most common complaints about Scala: Too many syntactic variations to express the same thing.

- The addition of @showAsInfix which is a solution in search of a problem.

But at least unsound type projections got restricted, I guess. (That's the only major thing I can think of that will have a larger impact...)

Probably the removal of forSome and cleaning up existentials?

Re: Reasonable Scala Compiler

#153

Post by AzzieElbab »

needusername wrote: post #17

I'm a bit confused. I have been told multiple times by Scala users that Scala compile times are a non-issue.

One of the huge benefits of strongly typed language is the ease it introduces to managing large code bases. Now imagine google size monorepo and scala compilation speed

Re: Reasonable Scala Compiler

#154

Post by carlosdp »

alexandercrohde wrote: post #8
carlosdp wrote: post #4

Earlier quoted context omitted.

That's... not true. You mention Kotlin, that was developed by JetBrains as a better language to develop Intellij and plugins. Hack/HHVM was developed by Facebook to modernize PHP. There are plenty of cases where organizations successfully developed their own languages/compilers that gave them advantages. It's insane only if you have no good reason to do it. This sounds like they have a need: compile times are slow.

you think compile times are so slow that they're saving time by writing a whole language? I'd like to see the numbers on that...

We're talking about a large organization that probably does 1000s or 10000s of builds a day, so yea it might

Re: Reasonable Scala Compiler

#155

Post by mhh__ »

majidazimi wrote: post #35

This truly means we still lack a programming language with: 1. reasonable support of object oriented programming. 2. reasonable support of functional programming. 3. solid concurrency features. 4. runs comparable to native code. 5. simple to learn. Even though it is not difficult to create such a language but we see a new language poping out every now and then and none of them try to solve these issues.

dlang.org? :)

You can write (compiler enforced) pure functional code, and the standard library is somewhat monadic.

Re: Reasonable Scala Compiler

#156

Post by ece »

danarmak wrote: post #116
ece wrote: post #112

Earlier quoted context omitted.

They are working on AOT compilation: https://www.youtube.com/watch?v=Xybzyv8qbOc&index=241&list=W...

IIUC, this is about AOT but still using the JVM. This is a fix for slow warm-up, but in longer running processes the eventual behavior isn't different from JIT. Which is important in its own right, but very different from a hypothetical 'Java native' in the sense of 'Scala native', without a JVM at all.

I believe you are right. Azul has released a JIT compiler based on llvm: http://www.infoworld.com/article/3193078/java/azul-introduce... Also: https://www.excelsiorjet.com/

and there seem to be open source projects like vmkit, https://github.com/ReadyTalk/avian that are somewhere in between.

Re: Reasonable Scala Compiler

#157

Post by speedkills »

wpietri wrote: post #150
_lbaq wrote: post #139

Earlier quoted context omitted.

SBT always runs Scalac in the same VM, so it will be hot and JIT compiled after a few passes. Intellij implemented a SBT Shell in 2017.1, so it will keep the same SBT session going between passes also.

That's a good start, but won't the compiler still be batch-oriented? By which I mean doing a ton of I/O and activity only when I hit go? I'm talking about something much more real time. I want the parser to keep everything hot, updating every time I hit a key. And whenever I get to anything that the parser approves of, downstream stages, which also keep everything hot, dynamically update all of their structures, revi…

The Dotty compiler is going down the route you are looking for.

Re: Reasonable Scala Compiler

#158

Post by afghanPower »

adamnemecek wrote: post #14
addisonj wrote: post #12

It will be interesting to see what the subset is. I have been writing scala for 2 years, mostly in spark and flink and as much as I love parts of it, overall, the language is just not the most approachable. Some of the features are super valuable every once in a while, but I might gladly give some of them up for a streamlined language that is easier to get people started on (while not just writing imperative style Ja…

Check out Kotlin. I picked it up in like half a day. It wasn't idiomatic Kotlin but w/e. It can compile to JS and you can use just about any JS lib from Kotlin (which is insanity). You'll be able to write ios apps with it soon enough. Scala can be too hard sometimes.

Clojure(Script) can do the same.

Re: Reasonable Scala Compiler

#159

Post by yawaramin »

hota_mazi wrote: post #6
yawaramin wrote: post #5

Earlier quoted context omitted.

It's not a new language, it's a reduced subset of the same language.

You're playing with words. They are creating their own language which is a subset of Scala, and they decide which features to keep based on whether they are fast enough to compile. The point is: developing your own language to ship your apps is crazy.

Is http://asmjs.org/ a new language?

(Hint: no. http://asmjs.org/faq.html )

Also,

> The point is: developing your own language to ship your apps is crazy.

It's crazy until you get to Facebook (PHP -> Hack) / Google (Go/Dart) /Twitter scale, then it starts looking like a really good idea.

Re: Reasonable Scala Compiler

#160

Post by Matthias247 »

lmm wrote: post #102
Matthias247 wrote: post #99

Earlier quoted context omitted.

Imho they are about the same, or maybe TS is even a little bit better, since you can really have freestanding functions (C# has either (static) member functions or delegates). The Javascript ecosystem probably also leans a bit more towards FP style in the mainstream (with lodash, ramda, redux, etc.) than C# does. What are you missing in particular? I guess the main thing for both is tail recursion.

Does TypeScript have any kind of "do notation" or "comprehension" syntax? LINQ is not the best by any means but it does seem like a big improvement over nothing.

No, it doesn't. I guess that's because monads are not considered idiomatic typescript. And for the special case of async programming there's async/await support.
Post reply on HN