Unlike Ruby, I'm stilling waiting for the one framework to stand out and dominate others, like Rails.
As of now, there are too many little web frameworks in Go. Most of them are inactive. People still have a hard time selecting which one to use for their project and not regret their decision in the future.
Ruby has Rails, Python has Django, what does Go have? Just name one, not a list.
Why are people so quick to dismiss Yahoo Mojito?
All these frameworks only run inside the browser. A little ehh to me, nothing revolutionizing. Yahoo's Mojito is a game changer. It can run in the browser and on the server. And it's SEO friendly!
Really wish Yahoo does a better job at marketing their own framework.
I love static typed language. With a proper IDE, code navigation, completion work like magic. I end up doing less typing than the dynamic typed language.
Have you ever tried to auto complete the 'init' function in RubyMine? It will ask you which one of the 100 init functions do you mean. :)
Not with static typed language. There is only one init function to choose from because the IDE knows the exact type you are working with at all time.
I do too but I'm finding that a lot of the time there are so many untyped inputs to a system that the static typing doesn't buy you that much. There always seems to be a ton of xml configuration data, incoming JSON from web services, databases with different type schemes etc.
As soon as you receive an untyped input, make it conform to a typed data structure, and throw some kind of error if you can't. That way you catch any issues in your input data long before it bubbles through your app and causes a problem which is super-hard to track down.
I'm also starting to find that a language with static typing and generally an enforced structure is easier to deal with.
With dynamic languages, you have to hold a lot in your head. Having an enforced structure offloads some things off your brain so you have more mental space to think clearly and not panic or get burned.
Static typing also makes overloading your f.unctions on return type instead of just arguments types possible. Not a lot of languages do this, though. I only know of one, but it's invaluable there.
Perl's a dynamic language, but return type can vary based on context. I once saw this really bite someone where the presence of parentheses on the left-hand side of the expression changed the behavior of the function being called on the right-hand side. Not fun to debug that one.
It only "sucks"(causes problems rarely, and can be quite useful regardless) in dynamic languages. Languages like Go, Rust, and Haskell provide the same flexibility with static guarantees. All you must do is define type specific implementations to satisfy the interface(or typeclass). For example in Haskell, I can so something like:
class Stream s where
read :: s -> (a, s)
write :: a -> s -> s
and extend it to any type:
instance Stream [Int] where
read s = ...
write a s = ...
instance Stream File where
...
and so on, and I can now pass any type that is a member of Stream, to a function that expects one.
The haskell code is — as far as I can see anyway — nominative typing. It can be post-implemented, but you still need your type to be explicitly made into a Stream instance.
Contrast OCaml, an object type is represented as a set of (method, types) tuples and type-checking is a subset check (if type A has all the methods of type B, then it's a subtype of B regardless of anything else from visibility to semantics):
# let x =
object
method foo = 42
end;;
val x : < foo : int > = <obj>
# let y =
object
method foo = 63
method bar = 12
end;;
val y : < bar : int; foo : int > = <obj>
# x = y;;
Error: This expression has type < bar : int; foo : int >
but an expression was expected of type < foo : int >
The second object type has no method bar
# type simple = < foo : int >;;
type simple = < foo : int >
# (y :> simple) = x;;
- : bool = false
#
Anyway, there's been quite a few proposals to add extensible records to Haskell, which would allow row polymorphism, similar to what you just showed in OCaml:
> You're comparing ad-hoc polymorphism with subtype polymorphism.
No, I'm comparing structural typing, which is what Go implements, to nominative typing.
But that may very well be due to me having stayed in context of an other sub-thread where this was the subject, and using that as a filter for the current one.
IntelliJ is the best IDE out there. It might be pricy, but it will save you so much time in the long run. Since time is money, you will end up saving money too. :)
If I ever develop a program language, the first action I will take is the clang approach and make it a library based architecture. That way, people can build tools for the language including IDE integration without having to reinvent the wheel.
Yes, this has been invaluable for us in Rust. One cool thing we've been able to do with this architecture is to write a fuzzer -- a tool that uses the Rust compiler itself to generate random Rust programs to test the compiler's correctness.
I think GHC does something like that. At the very least, it exposes an API that lets you do all sorts of fun things. There are projects like Scion[1] that let you integrate that into an editor.
However, there is simply less drive to develop tooling like that for Haskell than there is for Java. Haskell is a much easier language to use given just a moderately intelligent text editor and a REPL than most others. Java, on the other hand, it verbose and annoying even with a very good IDE.
So Haskell can have good support, but since it isn't terribly necessary it isn't anything like a top priority.
I know of it, but haven't used it, yet. That's why my comment was a bit more guarded than it would have otherwise been. (Though re-reading that line, it doesn't come across as such to me now.)
IntelliJ's Python module (Pycharm) does a as decent job as you might expect based on code and your type annotations (i.e. if your docstring says that foobar is a BlahManager, it will complete foobar methods based on that and warn you if you are calling something foobar doesn't have).
We worked so hard over the past decade to separate the presentation code from the business logic code. And moving away from SOAP/RPC to simple REST protocol. Then come nodejs and friends like Meteor/Derby/SocketStream/Firebase now trying to undo that separation. Have we gone backward?
There is nothing stopping you from separating presentation from business logic in node. The difference is that with single page apps, we're returning to a true client/server model. The server is very basic and easy to write, the server becomes more complex.
Now, while it is true that the goal of meteor is the sharing of code between client and server, that is business logic code (ideally) separated from the presentation code on the client. (Further, we're still a ways away from truly sharing that code.)
