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

161–170 of 265 posts

Re: Scala Native

#161

Post by densh »

pacala wrote: post #38
densh wrote: post #4

Hi all, I'm the author of the project and would gladly answer any questions.

Fantastic work! * Any plans to strengthen the Scala core lib so one doesn't have to reach out to JVM for mundane tasks like I/O or threading? * Is there a simple way to use raw C / C++ libraries from Scala native? * Is there a http://search.maven.org/ equivalent?

1. That's our long-term goal, but don't expect that to happen overnight.

2. @extern objects are an easy way to call C code. There is no C++ interop at the moment.

3. Not yet.

Re: Scala Native

#162

Post by munificent »

kbenson wrote: post #28
badminton1 wrote: post #17

In a way, simple Scala code resembles Swift, as commented by this person: https://leverich.github.io/swiftislikescala/ Now the type system of course is entirely different.

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…

> There's a very specific reason Perl opted for '.' to concatenate strings instead of +

I don't see making string concatenation ambiguous with property access being a real improvement. At least use `..` or some other unused punctuation.

Re: Scala Native

#163

Post by bad_user »

incepted wrote: post #134
danellis wrote: post #121

Earlier quoted context omitted.

It's worth noting that there was an LLVM-backed Scala project that was abandoned and died, so I definitely hope this avoids the same fate.

There was also a Scala.net project that was abandoned and died. That's very common for academic projects.

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

Re: Scala Native

#164

Post by dragonwriter »

bad_user wrote: post #163
incepted wrote: post #134

Earlier quoted context omitted.

There was also a Scala.net project that was abandoned and died. That's very common for academic projects.

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.

Re: Scala Native

#165

Post by azinman2 »

runT1ME wrote: post #113
azinman2 wrote: post #104

Earlier quoted context omitted.

Agreed, but that said I'm a recent convert from Scala to Go. Not sure I'd go backwards (no pun intended), boilerplate aside. Having standardization on things like channels in the language makes for a much nicer consistency in the language. Scala has 8000 ways to do anything, half of which involve an exotic DSL. I'll take plain and simple please over esoteric and unmaintainable.

'plain and simple' languages encourage and often necessitate 'esoteric and unmaintainable' applications. Look at Java for examples of this, and Go is basically java without generics and a much worse garbage collector.

How so? You can find examples of poor engineering in any language. What's specific about go?

Re: Scala Native

#166

Post by bad_user »

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…

- I've never experienced null problems in Scala. There's theory and there's practice. In practice if a NPE does happen, you treat it as a bug and wrap it. I don't experience problems, because Scala libraries are well behaved and for Java libraries I read the docs.

- Being a "jack of all trades" means Scala has the superior module system. In Scala you can have abstract modules, the way you have in Ocaml. In Scala type-class instances are lexically scoped, whereas in Haskell they are global. Haskell's type-classes are anti-modular, which is why there are people avoiding type-classes. A big part of what makes Scala so good is OOP. Haskell needs extensions to achieve similar functionality in a half-baked way and modularity is the main complaint of people coming to Haskell from Ocaml.

Btw, if you ask a C++ developer to describe OOP, he'll say it's the ability of having structs with a VTable attached. Most people think OOP is about state. That's not true, OOP is about single (or multi) dispatch and subtyping (having a vtable), hence it's not at odds with FP, unless you want it to be ;-)

- SBT is amongst the best build tools ever available. I could rant all day about the clusterfuck of Javascript (npm, Bower, Grunt, Gulp, Brunch.io, etc.) or Python (easy_install, setuptools, virtualenv) or .NET (MSBuild, Nuget, dotnet) or Haskell (cabal). For all its quirks, SBT is by far the sanest dependency and build management tool I've worked with. In fact, amongst the best reasons for preferring Scala.js is being able to work with SBT and avoid Javascript's clusterfuck completely.

- I've been working with IntelliJ IDEA with the Scala plugin for the last 3 years. I've had some problems with it, but all minor and it's amongst the best IDEs available, giving you everything you expect out of an IDE. Other platforms either don't have an IDE (Haskell), or require extra commercial plugins to behave like an actual IDE (Visual Studio).

And let me give an example: in IntelliJ IDEA I can click on any identifier in any third-party dependency and it automatically downloads and shows me the source code and I can set breakpoints and debug any third-party dependencies that way. Such a simple thing, yet it's a tough act to beat. Try it out in Visual Studio sometimes.

Re: Scala Native

#167

Post by saryant »

pfarnsworth wrote: post #30
spriggan3 wrote: post #3

Just saw this on twitter. Scala, you have my attention. There were a lot of talks about "the tools of yesterday" and "the tools of the future" lately. Scala getting closer to the metal, without the JVM is a significant step toward "the tools of the future".

I've heard a lot of the early adopters of Scala are moving away, including LinkedIn, Twitter, etc.

Twitter is not moving away from Scala.

Source: I work there.

Re: Scala Native

#168

Post by kbenson »

munificent wrote: post #162
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…

> There's a very specific reason Perl opted for '.' to concatenate strings instead of + I don't see making string concatenation ambiguous with property access being a real improvement. At least use `..` or some other unused punctuation.

In Perl, '.' is not property access. I'm not trying to imply '.' is the best solution for a language where it's already in use, but that a separate, unambiguous symbol would be better. For example, Perl 6 moved to using '.' for calling methods, and uses '~' for concatenation. It's not like just changing '+' is sufficient anyway, there is still string equivalence to consider (outlined in my other replies).

Re: Scala Native

#169

Post by PeCaN »

airless_bar wrote: post #151
PeCaN wrote: post #127

Earlier quoted context omitted.

Regarding Go... perhaps the parent was harsh, but not wrong per se . I think a strong argument can be made for Go being a very poorly designed language with an excellent community. Scala certainly doesn't have high development overhead either. Build system more or less just works, plenty of libraries, minimal ceremony to do much. Don't get me wrong, I kinda hate Scala¹, but compared to _many_ languages it does have l…

Scala has been vastly improved since 2.8. If the experience you stated comes from Scala 2.8 I think you will love the way things are working currently. I wouldn't want to go back to 2.8 even if people paid me a ton of money. I love ML, but think OCaml is a poor ML. That's why I love Scala. It's extremely consistent, and design decisions are very considerate. It's an amazing language and I can express my intentions mu…

I'll check it out again!

Thankfully I'm no longer working with the JVM, so I doubt I'll use it much, but it could be fun to take another look at.

Oh, and OCaml is possibly getting typeclasses (via modular implicits—not unlike Scala actually, for better or worse). It's not very painful if you use an alternate standard library (i.e. Core) that actually takes advantage of OCaml's amazing module system.

Re: Scala Native

#170

Post by haldean »

codygman wrote: post #100
dragonwriter wrote: post #86

Earlier quoted context omitted.

> It's pretty well known that Scala was heavily influenced by Haskell. In particular, do notation (for comprehensions), Is it documented anywhere that this was inspired by Haskell? To me, Scala for comprehensions seem syntactically more like a generalization of Python comprehensions than Haskell's monadic do notation.

Python's list comprehensions are a specialization of Haskell's list comprehensions[0]. I think Scala was influenced by Haskell's list comprehensions. 0: needs citation, though I remember reading something semi official about pythons comprehensions being influenced by Haskell. Maybe Python.org's page on Haskell.

Well at the very least, Haskell's came first; they were part of Haskell 98 (finalized in 1999) and Python 2.0 (the first version with comprehensions) was released in 2000.
Post reply on HN