5 ms·

This fails from the false dichotomy of speed of execution vs speed of development (which includes fixing bugs). Well written languages optimize to a certain wei

This fails from the false dichotomy of speed of execution vs speed of development (which includes fixing bugs). Well written languages optimize to a certain weighted preference of the two and some languages deliver more of _both_ than others. For example; Typescript is fast to write. and Golang is reasonably quick to write, _and_ execute. Both should have ~15% less bugs than javascript, potentially making them faster to develop (where bugs matter).

ninjakeyboard 8y ago
what is the 15% figure from? I'm suddenly working with a dynamically typed language (elixir) coming from scala and I do find more bugs. Would like some hard evidence to support that so just curious.
- maerF0x0 8y ago
  15% is from this paper as I recall it: http://ttendency.cs.ucl.ac.uk/projects/type_study/documents/type_study.pdf http://ttendency.cs.ucl.ac.uk/projects/type_study/documents/... https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-quantifying-detectable-bugs-in-javascript/ https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...
  - ninjakeyboard 8y ago
    thanks!
- pera 8y ago
  Have you tried to use Dialyzer or Dialyxir and typespecs?
  - ninjakeyboard 8y ago
    no. I probably should.
chrisco255 8y ago
Once you've paid the upfront cost of learning Golang, I might agree with you. But then again, in particular when building a full stack app (and not when on a team that has back end and front end specialists), it's helpful to use the same context (JS/NPM) when devving. People are bad at context switching.
- maerF0x0 8y ago
  That's why I mentioned TypeScript. It can run on both "sides", and has faster speed of development (as I defined it above, considering bugs) ...
- notdonspaulding 8y ago
  I've heard this argument several times now and it finally hit me what I dislike about it. If you aren't context switching between your backend code and your frontend code (even when both are JS), you're probably incurring technical debt in your architecture to be paid in even greater numbers of dev hours down the road. When you are writing an all-JS full-stack app, do you really feel like you're only working on a single app, as opposed to two different apps which happen to share the same repo?
  - chrisco255 8y ago
    It's not even likely they're in the same repo when working with Node (although possible). The context switch between apps is one cost you have to pay (surely your backend will differ from frontend in architecture). However, the costs of switching languages is higher. Golang / JS conventions are very different. It is possible to share some common libs front end / back end (lodash, validation logic, etc) and that helps too.
    - dozzie 8y ago
      > The context switch between apps is one cost you have to pay [...]. However, the costs of switching languages is higher. Is it? I was working with a system where server is written in Erlang and client (and another server) is written in Python. No problems with switching back and forth.

ninjakeyboard 8y ago

what is the 15% figure from? I'm suddenly working with a dynamically typed language (elixir) coming from scala and I do find more bugs. Would like some hard evidence to support that so just curious.

maerF0x0 8y ago
15% is from this paper as I recall it: http://ttendency.cs.ucl.ac.uk/projects/type_study/documents/type_study.pdf http://ttendency.cs.ucl.ac.uk/projects/type_study/documents/... https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-quantifying-detectable-bugs-in-javascript/ https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...
- ninjakeyboard 8y ago
  thanks!
pera 8y ago
Have you tried to use Dialyzer or Dialyxir and typespecs?
- ninjakeyboard 8y ago
  no. I probably should.

chrisco255 8y ago

Once you've paid the upfront cost of learning Golang, I might agree with you. But then again, in particular when building a full stack app (and not when on a team that has back end and front end specialists), it's helpful to use the same context (JS/NPM) when devving. People are bad at context switching.

maerF0x0 8y ago
That's why I mentioned TypeScript. It can run on both "sides", and has faster speed of development (as I defined it above, considering bugs) ...
notdonspaulding 8y ago
I've heard this argument several times now and it finally hit me what I dislike about it. If you aren't context switching between your backend code and your frontend code (even when both are JS), you're probably incurring technical debt in your architecture to be paid in even greater numbers of dev hours down the road. When you are writing an all-JS full-stack app, do you really feel like you're only working on a single app, as opposed to two different apps which happen to share the same repo?
- chrisco255 8y ago
  It's not even likely they're in the same repo when working with Node (although possible). The context switch between apps is one cost you have to pay (surely your backend will differ from frontend in architecture). However, the costs of switching languages is higher. Golang / JS conventions are very different. It is possible to share some common libs front end / back end (lodash, validation logic, etc) and that helps too.
  - dozzie 8y ago
    > The context switch between apps is one cost you have to pay [...]. However, the costs of switching languages is higher. Is it? I was working with a system where server is written in Erlang and client (and another server) is written in Python. No problems with switching back and forth.