Hacker News Reader

Hacker News

Comment by guard-of-terra | Hacker News Reader

Full thread

guard-of-terra

The JVM is extremelly useful after you consider that all other foundations for higher gen languages are either:

- Can't get threads really right.

- Have some lousy pausing single-thread mark-and-sweep GC.

- Is proprietary and bound to one dying platform.

- (Bonus points) has 3rd party libraries that are not thread-safe or segfault from time to time.

WRT "making language not unlike Scala but with better interop", Kotlin and some other projects seem to do that but they can't get themself out of the door :(

View on HN

Rust is the anti-JVM.

- Proper task isolation with pointer ownership.

- No global GC. Task-local GC when needed, and explicit ownership otherwise.

- Mozilla.

- No NullPointerExceptions. Unsafe code is convenient when you need it.

I personally am really excited by Rust, but it's also still a fairly fast-moving target. Lots of work is still being done on the semantics of the language.

It's an industrial research project, basically. When the semantics stabilise I reckon it'll be a technical winner in its chosen domain.

Yes, certainly -- it's annoying to be working on some code, then update to a day-newer compiler and suddenly have a screen full of errors (as is currently the case).

But in the long run, it'll be worth it, and I have no doubt that Rust will become an amazing language worth using.

And now you can browse Wikipedia in Servo (which is written in Rust): https://twitter.com/metajack/status/346822553089761281/photo...

Servo is a good idea because it helps show the pain points of Rust on a real world project. But it doesn't show that Rust is ready for general use yet because that's really what it is -- another facet of the Rust project.

True. It is nice; however, to see a big project being developed side-by-side with the language.

Absolutely. The obvious historical parallel is the co-evolution of Unix and C.

I wouldn't say all other foundations for higher-order languages -- F# runs fantastically on the CLR (or Mono) and doesn't have any of those problems you listed.

F# and the CLR aren't proprietary?

Mono isn't proprietary.

In my experience Mono is a bit like the OpenJDK was a few years ago:

Most things work, but there are a few things that are broken in unavoidable ways. Similarly, the performance isn't terrible, but the optimization is not quite at the same place as the original platform.

Xamarin's rapid work suggests that there will be a 'production-ready' CLR for most platforms (they've got it down for iOS, Android, and recently OSX) soon enough.

I feel like Xamarin is in the uncanny valley of language / tooling features. Close enough to working to make the brokenness feel so much worse. If it was more raw, less IDE friendly (ala Go) that would be fine... or was more polished and had a better Xamarin IDE and plugin system, that would be fine as well.

Right now, they are stuck in the odd middle, but it is still an amazing value if you are building common code cross platform apps.

Yes, but it can be a patent trap: https://www.fsf.org/news/2009-07-mscp-mono, https://en.wikipedia.org/wiki/Mono_%28software%29#Mono_and_M...

This patent trap commentary is 4 years old. I don't think this is on anyone's radar anymore. Otherwise Xamarin would not even exist.

Microsoft has open sourced F# http://fsharp.org/ and the fsharp.org community is very proactive. As for the CLR, it is an ECMA and ISO standard http://en.wikipedia.org/wiki/Common_Language_Infrastructure

F# is licensed under Apache 2.0: https://github.com/fsharp/fsharp/blob/master/LICENSE

The Windows-based implementation of the CLR is proprietary, but as other posters have mentioned, it's built around an open, standardized specification (ECMA-335). Xamarin has been making big strides in improving Mono over the past year, and it'll only continue to get better.

I would rather say that the mentioned problems are typical of languages that use their own VM instead of basing on an established platform like JVM or CLR.

JVM and CLR are not very different. What would be the reasons to want to avoid JVM, but still consider CLR as an acceptable choice?

Well, one of the things that hurts Scala on the JVM is the lack of tail call elimination, which the CLR supports. Reified generics and value types are probably also significant improvements.

People should be investing time in Scala (compiler and tooling, e.g. IDE support) instead of designing their own language that probably won't get a lot of traction.

I'm not sold on Scala and my colleagues aren't either.

For an outsider it looks like a C++ for JVM: A language of endless short-sighted features that's going to bury yourself under it.

It's not even Haskell because Haskell strives to be elegant.

Actually C++ looks simple compared to Scala. E.g. C++ iterators seem complex and tricky compared to say Lua's.

But let's just look at one element of Scala's truly byzantine iteration logic collection: Iterable

Inherited: Iterable IterableLike Equals GenIterable GenIterableLike Traversable GenTraversable GenericTraversableTemplate TraversableLike GenTraversableLike Parallelizable TraversableOnce GenTraversableOnce FilterMonadic HasNewBuilder AnyRef Any

Implicitly: by traversable2opsby MonadOpsby any2stringaddby any2stringfmtby any2ArrowAssocby any2Ensuringby alternateImplicit

Source: http://www.scala-lang.org/api/current/index.html#scala.colle...

..and now explain what all these aspects actually do! And that's just one small element!

And look at the method set of that thing.. Whoa! Again C++ suddenly seems minimalist.

Scala is one of the best languages out there if your job is to write code. If you spend a non-trivial amount of time reading it, it depends on which of the sublanguages the original writers used.

If Scala is used as "ML with OO features when really needed but not otherwise" it's quite nice, but I would not advise using Scala without a style guide for a multi-developer project.

What happens is that every single bit of functionality is split up and abstracted away, so that code duplication is kept at a minimum.

Considering that Scala ships with BOTH tons of collection types AND tons of useful operations, this seems to be a sane thing to do.

Scala manages ...

- to make both adding a new operation AND adding a new type not suck too much

- to retain the “best” collection type through operations, without duplicating code left and right

Most other languages fail already at point number one. No other language has managed to achieve point number two, let alone both.

To be fair, this is a list of everything inherited, not just one level up, but the full transitive closure. All of the Gen* classes arrived with 2.9 when parallel collections were added.

Also, the implicits shown are any implicits which can be invoked on Iterable, which includes all implicits which can be invoked on Any.

Am I supposed to be intimidated by a list of 100 things you can do with an Iterable? Each one seems pretty reasonable. The C++ stdlib has 100 things you can do with iterators, too.

To be honest, neither am I. I've done small projects in Scala (+libraries) and the amount of clever small features makes for short (maybe sometimes even elegant) code, but readability is a nightmare.

Front and foremost, though, I found tooling to be lacking. Reading a stack trace is horrible, the compiler is slow and the two most mature IDEs (IntelliJ IDEA and Eclipse) both have problems highlighting/checking and completing code.

For now, I'll probably stick with plain old Java.

For now, I'll probably stick with plain old Java.

You should consider Clojure. The community is evolving in a way that compensates for some of the tool chain problems, and Leinengen is definitely more intuitive than SBT.

My traditional bias favors static typing, but I think Clojure might beat Scala because for most web applications, runtime typing (you can implement similar guarantees as in compiled languages; however, checking isn't at compile-time and therefore your testing will be less performant) is good enough.

Been there and done that. However, designing languages to push the state of affairs forward is more my cup of tea (working on Scala helped with a lot of ideas though).

Writing tooling is incredibly difficult, especially when Eclipse isn't really designed to support new JVM languages. It is easier to write an IDE for your language than to plug into Eclipes.

Reply on news.ycombinator.com