It's not "perception". Recent studies have shown that about half the Romanians in the Netherlands are here illegally, and most of those are criminals. And those that are here legally don't always work under legal conditions.
This royally sucks for Romanian developers that want to work here, because despite being EU members they still need a work permit. The government basically assumes that the odds of Romanians coming here with good intentions are pretty low.
This guide is nice as it provides a short introduction into Angular's features.
I would kindly recommend you to read the Conceptual Overview section of the AngularJS Developer Guide (http://docs.angularjs.org/guide/concepts). This covers the heart of the framework and also parts of its philosophy. If you want to understand WHY AngularJS works the way it does not only WHAT it does then this page will really help you. You will also understand why this is a masterpiece of engineering.
If you have a small sample, you could try it out in the playground (http://www.typescriptlang.org/Playground/) and see what TypeScript can recognize. Generally, I've seen TypeScript plays well with other OO forms and gives you intellisense on quite a lot.
I noticed you mentioned scala on the server side. Does your comment about static typing being a hindrance apply to scala?
I would also argue that static typing provides a self-documenting benefit that is easy to forget, making it easier for someone unfamiliar with the codebase to understand what is going on. When I'm doing maintenance work I often start at the point of failure and work backwards, and it is very helpful when I can immediately identify what a variable is supposed to be representing.
"I would also argue that static typing provides a self-documenting benefit that is easy to forget"
Ditto. For me that's by some way the biggest advantage of typing, with refactoring/navigation being the next biggest.
I do wonder if some of these newer languages are going to make the self-documenting aspect even stronger though. I'm speaking here of optional typing and/or implicit implementation (Greeter implements IGreeter if it has the correct methods). For me this will let me put type information and abstractions (interfaces etc) only where they make sense.
Compare that with what you get in current static languages, where projects I've worked on that also use IoC have so many interface-implementation pairs that it becomes difficult to spot the important abstractions.
I haven't used Scala for application development (I'm talking about apps with a UI here). I really like it on the server -- easy to refactor, self documenting, great implicit typing so it feels like a "safer, faster" ruby or python.
I'm just really happy with Scala. Highly recommended, and the Akka library (Erlang for Scala, essentially) is fantastic.
> Common things such as access an undefined variable
That does not require static typing, unless you're developing in elisp maybe.
> trying to call a method of a null object
Unless there's support from the type system, that one only works on very short code spans within the same scope, which is the least useful it can be (as opposed to type inference which is most useful locally).
>you're saying Go will be an excellent systems programming language, which is its main stated purpose
It will be, when it is finished. Without dynamic linking it cannot replace C/C++ for lots of the intended use cases.
>Then, you claim it doesn't work like established alternatives, so it must be over hyped.
No, I claim that it lacks most useful features of the powerful languages it is constantly being compared with. Rob Pike says you don't give up much expressiveness moving from Python/Ruby to Go. This is absurd. Go has a different way of doing things yes, but for many things, that different way is to write more code.
I think in real usage (in my experience), this is very rarely the case. The only thing Generics are really extremely useful for is writing data structures that you can re-use with multiple data types.
Also, I tend to appreciate Go's approach of writing more code in these situations, because in general the code is still far more readable than a C++ Template (for example).
The Go creators have not ruled out adding Generics, they are simply being very careful about how they implement it. I would rather have this situation than something like a generic Java/C#/C++ style generics implementation rammed in because it is demanded by people who have hardly touched the language (or refuse to touch it until said feature is added).
"I think in real usage (in my experience), this is very rarely the case. The only thing Generics are really extremely useful for is writing data structures that you can re-use with multiple data types"
When working in .NET on framework-y code I use generics with reflection a lot because it makes it easy to remove a whole swathe of repetitive code. Mapping from one object to another using a Mapper<TFrom, TTo> with generic constraints, reflection and some over-ridable conventions springs to mind.
Not an argument for adding generics in Go, or against Go itself as I haven't yet found the time to play with it. However I do think generics can be more useful than people give them credit for.
The thing is that Go has generics already for the most common data types: slices (vectors, what Python calls 'lists', others call them 'arrays'), channels (iterators, generators), and maps (dictionaries, hashes). Since there's already a built-in map[T1] T2, so you wouldn't need to build it yourself, which saves even more work.
If what it has are a handful of special cases baked into the language, saying the language supports it is probably overselling (similarly, having types like `float' doesn't mean we consider C as supporting dependent types).
"The only thing Generics are really extremely useful for is writing data structures that you can re-use with multiple data types." Take a look at C++'s STL: a large set of generic algorithms that work with any data structure (built-in or user-written) supporting the standard iterator protocols. Many people think of STL as "a bunch of container classes", and ignore the algorithms.
... it cannot replace C/C++ for lots of the intended use cases
Does Go need to replace C/C++ in all use cases to be a "worthwhile" language? If not, then is there some required percentage of use cases that Go must be better at than C/C++? If not, then what is the point in arguing that there are some things Go is not as good for? Of course, knowing what those deficiencies are is important but it sounds like you are trying to convince people to not use Go. Why?
Yes there is a lot of Go hype around here and I understand your desire to counter that hype.
Choosing programming languages and other technologies and skills is an unfortunately subjective and messy process.
Loadable modules like the way Apache/nginx do, or Nagios or quite a few other basic infrastructure applications.
Another related issue (though not specifically dynamic linking) is with client libraries for server software. For example say you wrote something like Redis in Go. You write a Go client, then you want to start porting client libraries. You will be starting over from scratch because you can't expose your Go code through any kind of native interface. If you write client libraries in C it is pretty easy to create language bindings in all other popular languages. So if I wrote a server in Go that I wanted to distribute widely, I think I'd have to write the reference client in C.
> Loadable modules like the way Apache/nginx do, or
> Nagios or quite a few other basic infrastructure
I agree this style of composition is not currently possible in Go, but I do not agree that it is necessarily a good (in the engineering sense) solution to the requirement(s) it solves. There are lots of other ways to communicate between dynamically dispatched blocks of code, and dynamic code loading is by any account fragile.
Or, to put it another way,
> you can't expose your Go code through any kind of
> native interface
I'm not convinced this restriction is anything but good.
It actually scales better because you're distributing the rendering effort on more machines.
I meant that if they use generics in some built-in classes, they should also give that possibility to users. If they cannot give it to users, they shouldn't use it in built-in classes. It feels like they think users are too dumb to implement their own, so they give some created by them.
Should all languages also allow users to define flow control structures?
Yes, some languages do this, but there is (as almost always) a trade of between simplicity and flexibility.
I think Go strikes a very nice spot there.
In go the built in datastructures are very carefully selected, and are extremely useful, while when you need to build your own datastructures is both simple and powerful (you have direct control over memory layout), you just can't build magically generic datastructures, but that always comes at a cost, and Go's interfaces also provides ways to write generic code that are quite powerful.
I'd argue that C# didn't become an interesting and enjoyable language until it gained generics.
Generics certainly aren't essential to a language, but once you're used to them it does feel a touch chafing not to have them, as well as it feel a touch strange for them not to be included in a new, statically typed, language. My opinion naturally...