Hacker Newsnew | comments | show | ask | jobs | submit | ovidiu's comments login

Awesome design, it's exactly what I am expecting from this kind of component.

Congratulations and thanks for releasing this!

-----


Thanks!! So glad to hear you find it useful.

-----


Can you please elaborate on why Romanians are an issue? I'm curios because I am one and I'd like to know more about your perception.

-----


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.

-----


Maybe it would also be interesting to have phones with e-ink displays on its sides, for things such as notifications, weather conditions and phone status.

-----


The form factor that makes the most sense for notifications is a watch. It's a lot easier to look at a watch than it is to dig out a cell phone.

-----


A little watch that I could program with Lua to do pub/sub to my phone events would be great.

-----


Not great conversation for a dinner party, but I'd buy one for $100.

-----


Maybe you would be interested in watching a discussion between the leaders of these two projects. I think Dart shouldn't be dismissed as a "ridiculous" ambition. I would also like to point out that Dart compiles to JavaScript the same way as TypeScript, so your remark regarding replacing the JavaScript runtimes in all browsers is an exaggeration

http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-a...

-----


I'm wondering how to make use of an existing object system. We already have a JS framework that simulates classes and inheritance in the Java-style OOP.

-----


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.

-----


No, we have not. Read John Carmack's posts on static code analysis to understand why.

-----


I've been writing large-scale JS applications with SproutCore since 2007, and not once have I been bitten by a bug that would have been caught by static typing.

Same with Objective-C and my iOS and Cocoa development (since the OpenStep days).

I do use Scala on the server side though, and it helps there. But application development is, IMO, hindered by static typing. It's a lot more work to set up, and provides essentially zero benefit.

And I love static type analysis (I use it with C stuff all the time). +1

-----


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.

Interesting times ahead I think.

-----


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.

-----


> I've been writing large-scale JS applications with SproutCore since 2007, and not once have I been bitten by a bug that would have been caught by static typing.

Common things such as access an undefined variable or property or trying to call a method of a null object would be detected by most static type checking algorithms.

-----


> 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).

-----


First, you're saying Go will be an excellent systems programming language, which is its main stated purpose. To me, it already means that it's something that's worth looking at.

Then, you claim it doesn't work like established alternatives, so it must be over hyped. Like anything new, it's normal to see hype, misinformed opinions, advertising and enthusiasm about it.

I haven't written a line of Go, but it's going to be the next programming language that I learn because I find its concurrency model very compelling.

-----


>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[3]' 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.

-----


    > Without dynamic linking it cannot replace C/C++ for 
    > lots of the intended use cases.
What use case requires dynamic linking?

-----


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 
    > applications.
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.

-----


> What use case requires dynamic linking?

Here's one: writing a plugin for AviSynth in Go.

-----


some I can thnk of:

- Using a GPL-ed library in a BSD project.

- using a LGPL library in a commercial project.

- keeping source code secret from customers who buy your library.

-----


It actually scales better because you're distributing the rendering effort on more machines.

You can serve client-side code on demand, the same way you're serving HTML on demand. There are multiple methods of running a rich client HTML application in a modular fashion. For example, you can load new JavaScript and CSS on demand, or you could do a hybrid approach, by reloading the complete page from module to module. Most MVC frameworks for JavaScript support dynamic loading.

-----


It's still not practical. some other reasons:

1. It doesn't perform on some browsers which people use (IE7,IE8). I'm not willing to tell these users to go away or stick Chrome frame in as it makes us look like arrogant assholes.

2. It requires a large memory ceiling even with dynamic loading on a client browser. That kills older browsers and mobile devices.

3. It's an absolute bastard to test properly with Selenium or Ranorex as paths through the application require navigating through anchors rather than HTTP endpoints.

4. The entire UI would be dynamically typed shooting a lot of compile time checks that we rely on.

5. Internationalization is a bastard, particularly with multi-currency support, international date support and multiple languages.

6. It would require more state. State is bad. State means bugs.

7. It shifts the security model to an untrusted zone i.e. the client.

8. We have no scalability problems (5% cluster utilisation) and we shift 100 million requests a day.

Sorry but it doesn't cut it. I'd rather shift a WebStart or ClickOnce behemoth than do this with a client side MVC framework.

-----


Yes, these are valid disadvantages of doing rendering code on the client. In your case, and many other similar to yours, using Go with abstract interfacing wouldn't be practical.

-----


This issue has been addressed in the FAQ. They say generics might get added at some point, but they don't want to rush it. C# 1.0 didn't have generics either. http://golang.org/doc/go_faq.html#generics

-----


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.

-----


Maybe they are afraid of introducing some features they would later regret. This is not a hobby project of some lone hacker, it's meant to compile Google's infrastructure.

I really don't see why user code has to have the same capabilities as the runtime. It looks more like a philosophical request than a practical one.

-----


I believe you are letting your raw feelings get in the way of making technical assessments and decisions.

-----


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.

-----


Kind of like arrays in C or in pre generics Java and C#. Definitely not ideal but not that unusual either.

-----


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...

-----


It needs to be addressed in the code, too.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: