https://github.com/airbnb/hypernova
http://thenewstack.io/netflix-uses-node-js-power-user-interf...
> if I'm server side and using something dynamic, I might as well
> use something nicer like ruby or python.
The code is pretty much identical between Ruby, Python, and Javascript once you have a yield/await abstraction in the latter.
A) Types are low level
B) C++ and C are the only competition to JavaScript
C) Not having to worry about types makes you faster or in any way better
A) is simply refuted by looking at java or SQL. SQL is a very high-level language compared to other stuff, yet it's heavily typed simply to ensure that data is either valid or the query fails (SQL Injection is still valid data in this case)
B) Take a look at Go. It's blazing fast. It beats Node.js in all benchmarks but Regex matching -> https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
Furthermore, Go is statically linked which means deploying to production is a simple scp operation to drop the binary.
Lastly, Go is opinionated on how you write programs, you will write programs that are scalable simply because of how simple goroutines are, using channels you can utilize asynchronous execution as you would in node.js but also utilize all available cores without having to think about threads or synchronization. Just pipe data through the channel!
C) Is a red herring, depending on who you ask it's either opinion or static typing being "better". http://danluu.com/empirical-pl/
Some studies indicate that it does not matter, some indicate faster development but more bugs for no types and others indicate less bugs and slightly longer development for types.
IMO Types are good. I want to worry about the types because when I receive user input I can be sure that once parsed it's 100% an int or a float or it fits in a certain struct. For the same reason I think relational databases are better than document stores, they ensure that my data is valid.
I don't have to write as much validation logic. It is sufficient to know that my function has been passed an int-type, I don't have to check if it's nil or a string.
Types keep things (except for database column names or JSON import...) from blowing up the very first time you try to run it, rather than stopping the compile. That's useful, as far as it goes. (as long as it saves me more time not fixing a typo and rerunning than it does generating stupid cluttered code)
We have bigger problems (not that JS really addresses them, either).
Mutable data, cyclic update graphs and temporal coupling. (at least JS makes it easier to do FP type programming and to freeze objects to force immutability if you need to). This is a paradigm change we probably won't see until after most of us raised in the C/Algol era are dead, sadly.
Pet peeve: infix operators, and precedence rules. I have seen this bite badly in subtle ways, but it's a sacred cow of computing that you MUST have algebraic expressions. Lisp had it right - parens first, now you are trained.
Now that we have effective garbage collection, can we please STOP writing (thinking) in Algol/Simula 67 dressed up with curly braces??? (which really isn't that much higher level than COBOL/CICS, especially when you look at most Java dreck)
If you can make type inference scale, then I would be all for it. If I'm restricted to a small LoC count, might as well use a dynamic language.
Static typing is a scalable tool. It lets me avoid an entire category of bugs and unit tests. It make refactors easier as I just have to change my thing and then fix all of the obvious compile errors once. It helps me define parts of API contracts in code vs documentation and unit testing. And when a project gets large, the automated nature of static typing helps a lot!
FWIW, I mentioned that I think even the built it infix operators are a bad idea, rather than functions, such as variadic add(...), multiply(...), or(...), and(...). (subtract() and divide() really should only have 2 arguments, and not() just one)
If the compiler can safely infer a type, it should do it, that's a no-brainer, modern compilers are very capable of doing just that. This is why I like languages like Rust or Go.
For FP to some extend, I imagine Rust would be nice since mutability is opt-in rather than opt-out.
Cyclic Graphs are always complicated, they're hard, some languages just do the hard part easier while others just gnaw their teeth out.
Also agreed on LISP, LISP is probably the only good language ever, it becomes what you need it to be, if you want it's purely functional and in the next line it's object oriented.
Modern Compilers will probably coerce languages into a superposition of types, tho there will still be two sides to it, some people will always prefer explicit (as in: type is forced and checked) typing and some will prefer implicit (as in: type is fluid) typing.
SELECT *string* foo, *string* bar FROM banana A INNER JOIN beer B ON *int* B.id = *int* A.id
My problem with Go and other languages is that you have to be verbose like str = string = "string"; Where the compiler could probably figure out it's a string because of the quotes. And use a default numeric type when dealing with numbers. A compiled language also has the advantage that the compiler can thoroughly analyze the program, optimize and chose the optimal types if they are not explicitly set. My biggest issue though is the inferior module system compared to NodeJS (commonJS) module system that makes it possible to not write complexed code, because it's lexically scoped and do not have hidden globals.
I'm aware that an imperative low level language that can talk directly to the hardware will beat NodeJS and JavaScript in performance. But for the most part I'm willing to sacrifice that for increased productivity and simplicity. What do you think about languages that compile to JavaScript ? And do you think adding types to JavaScript would make it more simple ?
Which completely misses the point, this is called a file system btw, but a SQL Databases is designed from the ground up to have a validation schema.
You simply cannot put data in a SQL database that is not conform to the schema on which the table is defined. You can't simply put a string into an int column but this also means that any data you may read from this column will always be an int no matter what.
It means that if your transaction completes, including large scale database upgrades, at no point where types violated and you can be sure that all data is valid (or deleted because you forgot the WHERE clause)
>In ES6 you can now go very low level and deal with raw bit buffers.
I doubt you can write to registers and manipulate memory allocation, that is actually low level.
Manipulating bits is something every turing machine emulator can do.
>My problem with Go and other languages is that you have to be verbose like str = string = "string";
Which shows me that you haven't bothered to actually look into any statically typed language because I know of no common language that uses this syntax.
Go actually infers the type if possible, you simply write `str := "string"` or `var str = "string"` and go will use the correct type.
You can do this even with complex objects no problem. You only need to define the type if it's non-obvious, like you want to use an interface but the assignment uses the raw type, but this is something now compiler can do (it would be guess work)
Furthermore, there is no sacrifice in productivity, actually the opposite.
You don't have to wonder if the parameters you receive will have the correct type. If your function signature is `func (int) int` you can only ever receive an integer and you can only ever return an integer.
>NodeJS (commonJS) module system that makes it possible to not write complexed code, because it's lexically scoped and do not have hidden globals.
Go actually has a very neat module system. It's rather simple; all uppercase fields and funcs are exported, everything else is private.
The architecture of the standard library in Go and the language itself discourage globals and encourage default global states which can be exchanged for user defined states seamlessly.
Check out logrus or any of the popular logging frameworks in go. You can either use the default logger which is globally exposed or you use a custom one and pass the variable.
>I'm willing to sacrifice that for increased productivity and simplicity.
If simplicity and productivity is your goal you should use one of the LISP variants like ClojureScript. Nothing beats a language which you can program to be more efficient for you.
And you probably should check out some Go code too, it's easy to understand even without knowledge of the language as long as you know some basic CS101 stuff.
I mostly agree with what you're saying, but note having a channel doesn't mean one stops worrying about synchronization. If two goroutines both started waiting for data from a channel they'd be deadlocked.
Which means well-designed services will remain available even if only with degraded performance.
If all go routines are deadlocked, the runtime will terminate the service.
It's a kind of graceful and somewhat safe degradation.
I must have missed the memo that proved that Java / C# / C++ / Simula 67 are the one true path to productivity.
Async I/O is clumsy on the server side, though.
Then next, a hair-brained XML configuration scheme (with reflection) will be used to work around the inevitable deficiencies, which an IDE plug-in may or may not parse accurately.
Tragedy ensues. (Or hilarity, if I get to stand back while somebody else has to support the monster)
YMMV.
In Javascript you're not ensured to have an error, your program might continue working based on wrong data because some type has been randomly converted to a float.
In Go or C# you'd get an overflow error if the type is an int or you know it's a float and you get inaccuracy, if you need the accuracy you use a decimal type which will also ensure that any result is always of it's type.
Typed languages mean I cannot loose data accuracy without explicitly doing so. I have to tell Go that I want this uint64 as uint8 otherwise it's an error.
Performance? That is a good reason, but again if you actually pay attention to defining (and testing) your APIs that is in most cases a solved problem - use a fast language for performance sensitive endpoints.
Team's lack of knowledge? That's the only real argument. But that works both ways. If you have a team of experienced Node/JS developers then it would be foolish to implement your backend in Java (given no other constraints).
Regarding performance, your solution means that in order to understand your site, you need to understand another language and javascript now. At which point, why swap between languages and mindsets when the other language can already do everything javascript does, plus gives you a performance edge?
With the knowledge pool, it really does depend on the sort of application you're making, and how much code is reused and where. If your application has a web-based, and desktop/mobile app, you may very well be better off coding the entire thing in a language more amenable to native compilation.
Knowledge-wise, and long-term developer comfort-wise, Javascript's fast churn is problematic. When big packages' idea of long-term support is three years or less, you're going to be spending a lot of engineering time rewriting your code just to keep things from collapsing into a bug-ridden insecure heap. Examples like Angular.JS show just how brittle the javascript environment is, and how difficult it's going to be to keep a site maintained.
Regarding performance, why don't we write our web applications in C++, Rust or Go?
There is a lot of churn in front-end frameworks, but for back-end frameworks the ecosystem is more stable (I like ExpressJS, which is like the Rails for NodeJS).
If you factor your architecture correctly (e.g. separate your domain model from your views), you can also switch a bit easier between front-end frameworks.