4 ms·

You seem to assume that 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

by tscs37 10y ago

You seem to assume that 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?lang=go&lang2=node 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/ 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.

life_is_short 10y ago
> without having to think about threads or synchronization. Just pipe data through the channel! 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.
- tscs37 10y ago
  True, on the other hand, go will take care of that to some extend and terminate if all go routines have been deadlocked. Which means well-designed services will remain available even if only with degraded performance.
  - life_is_short 10y ago
    I didn't know go can do deadlock detection. Thanks for this, I learned something new today.
    - tscs37 10y ago
      it's not a 100% detection. You can certainly pile up deadlocked go routines, but the way most libraries (including the standard library) are setup, if you were to write some server, you'd only deadlock on the request but the app keep running. There is no way to reliably detect that but the service will probably service most requests if you didn't plain deadlock everything. If all go routines are deadlocked, the runtime will terminate the service. It's a kind of graceful and somewhat safe degradation.
z3t4 10y ago
SQL is also a leaky abstraction, it would be much more simple if the database could just take any value and store it optimally. But at least you do not have to write: SELECT *string* foo, *string* bar FROM banana A INNER JOIN beer B ON *int* B.id = *int* A.id I want to correct myself though. In ES6 you can now go very low level and deal with raw bit buffers. 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 ?
- tscs37 10y ago
  >it would be much more simple if the database could just take any value and store it optimally 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.
Roboprog 10y ago
Compile time types are nice to have, if they stay out of my way (type inference, the ability to easily opt out for certain "tricky" code...) 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)
- tscs37 10y ago
  I mostly agree, types are nice but they should not clutter code like in C++ or C. 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.
- mahyarm 10y ago
  Type inference is horrible. Mostly because as soon as your project gets large, type inference eats inordinate amounts of time during compiling and indexing and developer experience degrades. Combine that with operator overloading and generics and it gets even worse. Right now I'm suffering through it with swift with a +100k LOC project. The obj-c equivalent compiles and indexes 5-10x faster. 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!

by tscs37 10y ago

life_is_short 10y ago

> without having to think about threads or synchronization. Just pipe data through the channel! 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.

tscs37 10y ago
True, on the other hand, go will take care of that to some extend and terminate if all go routines have been deadlocked. Which means well-designed services will remain available even if only with degraded performance.
- life_is_short 10y ago
  I didn't know go can do deadlock detection. Thanks for this, I learned something new today.
  - tscs37 10y ago
    it's not a 100% detection. You can certainly pile up deadlocked go routines, but the way most libraries (including the standard library) are setup, if you were to write some server, you'd only deadlock on the request but the app keep running. There is no way to reliably detect that but the service will probably service most requests if you didn't plain deadlock everything. If all go routines are deadlocked, the runtime will terminate the service. It's a kind of graceful and somewhat safe degradation.

z3t4 10y ago

SQL is also a leaky abstraction, it would be much more simple if the database could just take any value and store it optimally. But at least you do not have to write: SELECT *string* foo, *string* bar FROM banana A INNER JOIN beer B ON *int* B.id = *int* A.id I want to correct myself though. In ES6 you can now go very low level and deal with raw bit buffers. 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 ?

tscs37 10y ago
>it would be much more simple if the database could just take any value and store it optimally 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.

Roboprog 10y ago

Compile time types are nice to have, if they stay out of my way (type inference, the ability to easily opt out for certain "tricky" code...) 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)

tscs37 10y ago
I mostly agree, types are nice but they should not clutter code like in C++ or C. 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.
mahyarm 10y ago
Type inference is horrible. Mostly because as soon as your project gets large, type inference eats inordinate amounts of time during compiling and indexing and developer experience degrades. Combine that with operator overloading and generics and it gets even worse. Right now I'm suffering through it with swift with a +100k LOC project. The obj-c equivalent compiles and indexes 5-10x faster. 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!