Towards Scala 3 • Hacker News Board

Re: Towards Scala 3

#371

Post by lomnakkus » Sat, Apr 21, 2018, 5:19 PM UTC

stephen wrote: post #370

lomnakkus wrote: post #367

Earlier quoted context omitted.

The models of SBT/Gradle/Maven are broken, or at least, that's the premise for writing these build tools. The model of Mill, Bazel, Buck, Pants are fundamentally different in very important ways which allow e.g. using a shared build cache across all the developers in a team (or even all the developers in a whole company if one takes the monorepo approach for absolutely everything). This is not something that can be r…

Gradle does have a build cache, which can be local or remote: https://docs.gradle.org/current/userguide/build_cache.html It is a newer feature, so that might be why you're unaware of it. Also, I get that the models of Bazel/Buck/Pants are fundamentally different, because they are inherently cross-language / "sit on top of other compilers" systems. And are best for mono repos. But Mill doesn't fit in that camp AFAICT.

Ah, right I wasn't aware of that. Still, AFAICT Gradle isn't nearly as 'ambitious' in tackling the hard problem of hermetic/reproducible builds as e.g. Bazel, so who knows how reliable that build cache actually is.

You may well be right about Mill, but it's probably too early to tell exactly where it'll land in the design space.

(Btw, I think it's entirely right to be wary of yet-another-build-system, especially when it doesn't seem to do anything that other systems don't already do.)

Re: Towards Scala 3

#372

Post by dang » Sat, Apr 21, 2018, 7:26 PM UTC

_Codemonkeyism wrote: post #58

realusername wrote: post #31

Earlier quoted context omitted.

I know on HN people like Scala but it's by far one of the language I hated the most when I worked with it. It's the complete opposite of Go, every time the Go team said no to a random feature, the Scala team said yes to that random feature. Scala feels to me like a kind of functional Perl.

Scala is not for development, it's a research project.

Please don't post flamebait to Hacker News.

Re: Towards Scala 3

#373

Post by pjmlp » Sun, Apr 22, 2018, 1:34 PM UTC

nikolay_igotti wrote: post #158

pjmlp wrote: post #56

Earlier quoted context omitted.

More than that, if you want Kotlin/Native debugging support, you need to either buy Clion or AppCode, as it is not available on the community edition.

It is not correct, debugging via lldb is available.

Which is quite primitive experience versus having a GUI debugger.

Something that other languages that compile to native have available without additional costs

Re: Towards Scala 3

#374

Post by AzzieElbab » Sun, Apr 22, 2018, 1:45 PM UTC

ivan_gammel wrote: post #305

AzzieElbab wrote: post #301

Earlier quoted context omitted.

Why would you expect this to work? In fact given that API a map from another java library(say guava) would have crashed you just as well

Well, I wouldn't even try to have a source code written in two different languages in the same component. But I've seen this problem in someone else's real code, which was probably caused by a not really well-thought migration of Java code to Scala. Basically, a developer replaced one Map with another, fixed all the places where API was different on source code level and a number of tests. However, interoperability i…

You are right, this particular example is more of case against reflection rather than anything else. Having said that, Scala maps actually are tricky to use from java. In general scala does a better job in compatibility when it comes to reuse of java code from scala, but not the other way around

Re: Towards Scala 3

#375

Post by lmm » Sun, Apr 22, 2018, 3:37 PM UTC

YorkshireSeason wrote: post #347

lmm wrote: post #296

Earlier quoted context omitted.

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

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

This isn't true though - that's not what implicits are for and not how they're used. Indeed the clearest proof is that Scala still has default arguments, and they still have the behaviour given in your OCaml example. They're different things.

Re: Towards Scala 3

#376

Post by lmm » Sun, Apr 22, 2018, 3:49 PM UTC

pron wrote: post #329

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 understand your strategic motivation, but to convince people your language is best, saying "my language is better than X" can be a very bad tactic. The reason is that most programmers aren't big PL fans, and that, to be honest, language choice (among various more-or-less suitable options) has a negligible -- if any -- effect on a business's bottom line. The biggest effect is on programmer enjoyment, as there are (p…

> language choice (among various more-or-less suitable options) has a negligible -- if any -- effect on a business's bottom line.

That's just, like, your opinion, man.

(By which I mean: I disagree, and we both know there's no clear evidence one way or another)

> To increase the appeal of a language, the best things you can do is create great tooling, lots of useful libraries, and a friendly community.

I do what I can, but a bad language can do those just as easily as a good language - tooling and libraries are much more a function of big-corp backing than they are of good language design. It's remarkable how much Scala has managed to achieve in those areas without having a big name behind it, but there's no competing with the amount of programmer-hours the likes of e.g. Google can pour in. The only way Scala can hope to win is on actual language design merit (and maybe winning popularity on that is impossible, but given how well Scala has managed to do so far, I remain hopeful).

> In addition, an argument for "my language is better than X" can usually be easily countered with an argument for the opposite, creating a net result that doesn't help your goals. Debates are sometimes interesting and informative, but they're not effective marketing.

A genuinely better language should have at least a slightly better chance of winning a debate over which language is better. If we don't believe that then we have no hope of ever learning truths, and may as well pick languages to use at random (or I guess go with whatever Google picked).

Re: Towards Scala 3

#377

Post by pron » Sun, Apr 22, 2018, 7:08 PM UTC

lmm wrote: post #376

pron wrote: post #329

Earlier quoted context omitted.

I understand your strategic motivation, but to convince people your language is best, saying "my language is better than X" can be a very bad tactic. The reason is that most programmers aren't big PL fans, and that, to be honest, language choice (among various more-or-less suitable options) has a negligible -- if any -- effect on a business's bottom line. The biggest effect is on programmer enjoyment, as there are (p…

> language choice (among various more-or-less suitable options) has a negligible -- if any -- effect on a business's bottom line. That's just, like, your opinion, man. (By which I mean: I disagree, and we both know there's no clear evidence one way or another) > To increase the appeal of a language, the best things you can do is create great tooling, lots of useful libraries, and a friendly community. I do what I can…

> I disagree, and we both know there's no clear evidence one way or another

I think that the lack of evidence in favor of a strong effect is normally counted in favor of the null hypothesis. It may not feel fair, but the burden of proof is solely on those who claim a strong effect exists, not on those who don't.

> but a bad language can do those just as easily as a good language

Again, the burden of proof is solely on those who claim there is such a thing as a good language with a strong effect. If you can't display an effect, or claim that others can also induce it by other means is a win for the null hypothesis. If you claim there is such a thing as a "bad" language, and there is no evidence this is true, doing so will harm your cause.

> A genuinely better language should have at least a slightly better chance of winning a debate over which language is better.

I just don't think that a debate is the right way to establish an empirical claim. It's ok to engage in a debate - even a heated one - but the lack of evidence should at least encourage humility. My point is just that an imagined "win" at a debate only harms your mission. If it convinces anyone, which is highly doubtful, it's probably not the people you want, anyway. An approach that says, "I think this is cool. I like it and it helps me and may help you, too" is so much more effective at marketing than "my way is best" especially if the evidence is not on your side.

Re: Towards Scala 3

#378

Post by YorkshireSeason » Wed, Apr 25, 2018, 10:07 AM UTC

lmm wrote: post #375

YorkshireSeason wrote: post #347

Earlier quoted context omitted.

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.

> 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. This isn't true though - that's not what implicits are for and not how they're used. Indeed the clearest proof is that Scala still has default arguments, and they still have the behaviour given in your OCaml example. They're different things.

I did not say implicits and default arguments are the same thing. I said that implicits improve upon default arguments in various ways, the key realisation being the split between providing elided values in a context-dependent way, and permitting the elision of values.

I should not have said the key idea, but a key idea.

Default arguments are convenient if you don't need context dependence of elided arguments. I'd probably have remove defaults in order to have a smaller and more simple language.

Re: Towards Scala 3

#379

Post by YorkshireSeason » Wed, Apr 25, 2018, 10:08 AM UTC

lptk wrote: post #361

YorkshireSeason wrote: post #360

Earlier quoted context omitted.

> does not correspond to what derived implicits do I did not claim it did. The first example disproved ionforce's claim that default values cannot be constructed dynamically. > Define `a` as `y` to shadow the function parameter, Whoops, yes that's correct. I didn't realise this was possible.

> The first example disproved ionforce's claim that default values cannot be constructed dynamically. But I don't think that is what they meant. I think they meant something along the lines of what I said above: > an expression with an arbitrary number of subexpressions may be synthesized, the shape of which depends on the types involves

OK, maybe I misunderstood ionforce. I don't deny that type-driven synthesis is a core element of implicits.

Re: Towards Scala 3

#380

Post by _Codemonkeyism » Wed, Apr 25, 2018, 12:49 PM UTC

_Codemonkeyism wrote: post #58

realusername wrote: post #31

Earlier quoted context omitted.

I know on HN people like Scala but it's by far one of the language I hated the most when I worked with it. It's the complete opposite of Go, every time the Go team said no to a random feature, the Scala team said yes to that random feature. Scala feels to me like a kind of functional Perl.

Scala is not for development, it's a research project.

Foursquare lib migration to Scala 2.12, open since one year, we can't upgrade to 2.12 because of that dependency,

https://github.com/foursquare/fsqio/issues/37

They don't upgrade the open source version because their internal version depends on that open source version and they don't can't upgrade internally to 2.12.

They can't upgrade because of several dependencies of their own, the last one Finagle.

All of those although "cross compiles are no problem" as the default answer from the Scala development team on these issues.