Hacker News Reader

Comment by ungzd | Hacker News Reader

Another sign that it's designed for enterprise Java camp: old Angular was very popular in such shops because of IoC and service factories. Now it requires java-like language on top of javascript, with type system designed primarily for autocomplete in IDE to work (even unlike Java in which type system is primarily intended to make runtime do less computations).

View on HN

The angular core team from Google even has technical PM that handles business relationships. I've recently been to AngularConnect in London - from what I've gathered their future focus is also very much about ease of use. They try to establish angular-cli as the de facto toolchain by incorporating best practices from the community, similar to ember-cli. There are a lot of nice features with the new compiler infrastructure (AOT with lazy loading support from the router) and types obviously help here.

As a counter point, with ngrx/store being so popular in Angular2 land I doubt Angular2 is as friendly to the Enterprise as you make it sound. On top of Redux you have Rx, many people will have a hard time wrapping their heads around this.

ngrx creator (and ng core team member) here - you'd be surprised at the uptake on ngrx/redux in enterprise I think - a lot of the constraints / guarantees redux offers are really attractive to big teams, and pretty much every big enterprise team I've spoken to in the past few months are using or at least investigating using it.

That's a common misconception about the JVM. Although the language features allow type-erasure, the JVM actually stores the types with the data and uses tracing for optimization. This keeps the compiler output smaller and allows classes to be compiled independently.

Still it doesn't have to check overloaded arithmetic operators each time and to look up class instance properties in hash table.

The operators are converted to methods, however methods are 'looked-up' at run-time. Not in a hash-table though, think C++ style vtables. So int + float isn't compiled to int.addFloat( float ) but to int.add( float ) and then uses polymorphism at run-time.

If you do try to eliminate all of this work at run-time, by creating type-specialized versions of every method, you have the problem that code that tries to narrow a type by either casting, or doing an instance-of check on a supertype (like Object) needs special treatment.

All these choices were made long before they implemented 'generics', so most code was doing manual narrowing and casting all over the place, including the standard API's. Type-erasure would not actually improve the performance by much since it could hardly be used.

They solved the performance problem, without actually considering the type system. Your code runs just as fast, as if you used the Object type everywhere, and just cast on the fly to what you expect it to be. Which would be equivalent to a dynamically typed language.

Reply on news.ycombinator.com