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.