Live data from Hacker News

Scala Native

github.com

221–230 of 265 posts

Re: Scala Native

#221
post #217
post #204

Earlier quoted context omitted.

This thing that each Lisp developer writes its own DSL library is one of the reasons why the enterprise isn't so found of Lisp. It is always a steep curve to dive into other developers code.

Wouldn't LISP become more popular if students started with LISP at school/university rather than C/C++, Java or Python? How can a young developer compare or choose if he/she had never been exposed to LISP?

It would help, but it isn't sufficient.

I had a very good CS degree in the mid-90's.

We got to use Pascal, C, C++, Prolog, Caml Light, Smalltalk, Oberon(-2), Component Pascal, Lisp, SQL, PL/SQL, x86 ASM, MIPS ASM, Java, across the 5 years it used to take (nowadays thanks to Bologna is no longer the case).

It doesn't mean we got to use many of those languages afterwards.

But Lisp is a special case, if Lisp Workstations hadn't failed in the market or if Sun and others hadn't picked UNIX as their Workstation OS, maybe it would be different IT world, in spite of all DSLs I was referring to.

Re: Scala Native

#222
post #40

Earlier quoted context omitted.

Clearly they added a bunch of new stuff that the JVM can't understand. So it is either "Scala like LISP" or It is a superset of the Scala language. Meaning all existing stuff will work with it, but if you use new secret keywords it will work "better". Which seems not quite ideal, because that means most Scala libraries will not be "tuned", and you will need all new libraries.. just like ScalaJS made you need entirely…

The language is already a nightmare compared to a nearly syntaxless lisp so I'm not surprised that the ecosystem follows suit.

It's pretty light on syntax compared to C/ALGOL-family languages. Function bodies are just another block (or expression), as are things like try. Operators are just method calls (except for precedence, and the precedence table is much shorter than C/Java/etc.).

Re: Scala Native

#223
post #14

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 would argue scala' main selling point is making the jvm palatable to people who hate Java. However, it's entirely unclear without the jvm why I would choose it over, say, rust, Haskell, go, c++, etc.

Over rust/go/c++: more powerful type system, more concise code. Over Haskell: explicit about lazy-or-not, support for traditional OO inheritance when you need it.

Re: Scala Native

#224
post #182

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…

A teaching page will naturally recommend away from advanced features during the teaching phase. Twitter's style guide for first-class scala code is http://twitter.github.io/effectivescala/ and code written in that style has huge advantages over Java.

Re: Scala Native

#225
post #65

Earlier quoted context omitted.

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.

If your limiting factor is how fast you can type you are either an amazing person that should be studied or you need to take a typing class.

My limiting factor is usually how fast I can comprehend other people's code, and the extraneous crap some languages require can often be the biggest contributor to that.

Re: Scala Native

#226
post #185

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…

Please don't start programming language flamewars on HN ("Go is utter shit", etc.) Those are all the same, and we're hoping for thoughtful discussion. We detached this subthread from https://news.ycombinator.com/item?id=11678317 and marked it off-topic.

Does anyone have a browser extension or similar that will reattach subthreads that get moved like this? Or maybe a user preference similar to showdead?

Re: Scala Native

#227

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.

To my mind writing off Go is table stakes for having an interesting discussion about modern programming language choice - anyone who takes Go seriously is coming from a position so different from mine that it would take many pages (all of which would be rehashing of old discussions) to bridge the gap, and I honestly can't be bothered. While I would try not to be so rude about it, I think GP is right to dismiss the language without going into detailed reasons; there are any number of threads about Go that cover the case for and against already.

Re: Scala Native

#228

Earlier quoted context omitted.

'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?

Go doesn't have the facilities that let you handle real-world concerns in a nice way. All the examples of bad, enterprisey Java - Spring AbstractSingletonProxyFactoryBean, XML config for everything, reflection-based JSON serialization, annotation-based transaction management, JavaSpaces - they weren't written by idiots, they were written because they were the best way to solve real business problems within the limits of the language - limits that go also has.

People don't like writing hundreds of lines of repetitive boilerplate the way go's lack of generics forces you to. They'll look for a better way, and they'll come up with hacks, just as they did in Java.

Re: Scala Native

#229
post #2

Really excited about this. This is another reason why Scala is an extremely valuable tool these days. With Scala JVM, Scala.js with React Native and now with Scala Native (LLVM), there'll be literally nothing you can't do well with it.

Does Scala.js with React Native work well? I avoided it because I didn't want to complicate my stack or have to jump through hoops when reading the react docs. If it all works well I might make the jump to scala front & back...

Reportedly, it works really well. Have a look at https://github.com/chandu0101/sri

Re: Scala Native

#230

Earlier quoted context omitted.

There have been so many successful projects started by one person. Shooting it down before seeing what will be done is a bad idea. I'm interested in it breaking away from the JVM to become more performant, since that has been one of my concerns about Scala; there is a lot of good about JVM-based languages, but when in the ring with other languages like Go, you need to be quick to win. I hope that others join him, but…

Note that I am not concerned about the fact that the project was started by one person, nor am I dismissing it altogether. The author of this project is most definitely a smart and capable individual. However, at some point this project will reach a point where it requires more work than one individual can achieve, hence the question regarding official support - is there any financing, plans for new contributors, etc…

I understand your concern, but, as I said, a number of authors have not have financing, plans for new contributors, etc. in the beginning and have been successful; these are not requirement for success in the beginning.

For example, here is the story of how Python got its start from Guido van Rossum (quote from 1996):

"Over six years ago, in December 1989, I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. My office ... would be closed, but I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately: a descendant of ABC that would appeal to Unix/C hackers. I chose Python as a working title for the project, being in a slightly irreverent mood (and a big fan of Monty Python's Flying Circus)."

And the history of how Ruby got its start by Yukihiro Matsumoto (quote from 1999) is similar:

"I was talking with my colleague about the possibility of an object-oriented scripting language. I knew Perl (Perl4, not Perl5), but I didn't like it really, because it had the smell of a toy language (it still has). The object-oriented language seemed very promising. I knew Python then. But I didn't like it, because I didn't think it was a true object-oriented language — OO features appeared to be add-on to the language. As a language maniac and OO fan for 15 years, I really wanted a genuine object-oriented, easy-to-use scripting language. I looked for but couldn't find one. So I decided to make it."

Denys Shabalin is working under the author of Scala and corresponding regularly with the author of Scala.js, so he has more support than either van Rossum or Matsumoto did, and neither of them had the plans you spoke of- they just wrote the language because it is what they wanted to do.

Post reply on HN