4 ms·

I've been on large projects written in Python, it's no good. (I say this as a Python fan!) For scripts and small projects or rapid prototyping Python is prett

I've been on large projects written in Python, it's no good. (I say this as a Python fan!) For scripts and small projects or rapid prototyping Python is pretty much king. (Although Red/Rebol is a contender. Check out their GUI examples!) For medium-sized projects (100K LoC, 1-10 devs) you might use Go or you could experiment with the usual suspects: Lisp or Nim or Haskell or OCaml or whatever you want. For a large project (millions of LoC, 100's of devs) I would use Ada or Java unless the problem was very Erlang-shaped (in which case you would use Erlang (or Elixir.)) For front-end work I'll personally never use anything but Elm for the foreseeable future. Based on economics. Compared to Elm the entire JS ecosystem is a incredibly massive boondoggle, a total waste. (I'm cranky this morning and I'm practically trolling here. Apologies to those who are not entertained. I mean it though: in my considered opinion Elm mocks JS, brutally.)

hbrn 4y ago
Could you elaborate on this more? What exactly happens between 20k and 100k LOC (or 2 devs and 10 devs) that makes Go more suitable than Python? What exactly happens between 100k and 1kk LOC (or 100 devs and 500 devs) that makes Java more appropriate than Go? How do you even find this boundary when same apps in Java and Python might have 2-3x LOC count difference? I've seen this mantra repeated for decades (technologies X/Y/Z for small/medium/large projects) and could never make sense of it. For example Angular was always sold as a technology for "large" projects (as opposed to React). Where is Angular now? All those "large" projects are now legacy that everyone despises. And if you have 100+ developers on a "large" Angular project I bet you're are feeling fucked now. Since everything breaks at scale, I'm actually into the opposite mantra: only the tech stacks that are great at small scale are capable of being great at large scale. Note: capable, not guaranteed. I always prefer layering complexity on top of a simple technology, instead of praying that complexity inside of a complex technology will perfectly match my needs.
- carapace 4y ago
  > Could you elaborate on this more? > What exactly happens between 20k and 100k LOC (or 2 devs and 10 devs) that makes Go more suitable than Python? > What exactly happens between 100k and 1kk LOC (or 100 devs and 500 devs) that makes Java more appropriate than Go? > How do you even find this boundary when same apps in Java and Python might have 2-3x LOC count difference? I've been thinking about those questions for roughly thirty years, and I still don't have exact answers. (If I did I'd be famous and hopefully rich, but that's another story, eh?) Speaking in broad generalities, the main thing seems to be something like the number of separate concepts you have to keep in mind to make (non-breaking) changes to the system. The more that the system you're using can do for you, the more suitable it is for larger-scale projects. > I've seen this mantra repeated for decades (technologies X/Y/Z for small/medium/large projects) and could never make sense of it. I gotta say, it's not a "mantra", it's experience. Have you not worked with various languages on various sized projects? (In re: Angular, to me that was an obvious shitshow from day one. I would never hire anyone who admitted to ever thinking Angular was a good idea. Same thing in re: Heroku, while I'm at it. Lots of people do lots of foolish things when computers get in the mix.) > I'm actually into the opposite mantra: only the tech stacks that are great at small scale are capable of being great at large scale. Note: capable, not guaranteed. I don't see how that follows? (I also don't see how that's "opposite" to the other "mantra".)

hbrn 4y ago

Could you elaborate on this more? What exactly happens between 20k and 100k LOC (or 2 devs and 10 devs) that makes Go more suitable than Python? What exactly happens between 100k and 1kk LOC (or 100 devs and 500 devs) that makes Java more appropriate than Go? How do you even find this boundary when same apps in Java and Python might have 2-3x LOC count difference? I've seen this mantra repeated for decades (technologies X/Y/Z for small/medium/large projects) and could never make sense of it. For example Angular was always sold as a technology for "large" projects (as opposed to React). Where is Angular now? All those "large" projects are now legacy that everyone despises. And if you have 100+ developers on a "large" Angular project I bet you're are feeling fucked now. Since everything breaks at scale, I'm actually into the opposite mantra: only the tech stacks that are great at small scale are capable of being great at large scale. Note: capable, not guaranteed. I always prefer layering complexity on top of a simple technology, instead of praying that complexity inside of a complex technology will perfectly match my needs.

carapace 4y ago
> Could you elaborate on this more? > What exactly happens between 20k and 100k LOC (or 2 devs and 10 devs) that makes Go more suitable than Python? > What exactly happens between 100k and 1kk LOC (or 100 devs and 500 devs) that makes Java more appropriate than Go? > How do you even find this boundary when same apps in Java and Python might have 2-3x LOC count difference? I've been thinking about those questions for roughly thirty years, and I still don't have exact answers. (If I did I'd be famous and hopefully rich, but that's another story, eh?) Speaking in broad generalities, the main thing seems to be something like the number of separate concepts you have to keep in mind to make (non-breaking) changes to the system. The more that the system you're using can do for you, the more suitable it is for larger-scale projects. > I've seen this mantra repeated for decades (technologies X/Y/Z for small/medium/large projects) and could never make sense of it. I gotta say, it's not a "mantra", it's experience. Have you not worked with various languages on various sized projects? (In re: Angular, to me that was an obvious shitshow from day one. I would never hire anyone who admitted to ever thinking Angular was a good idea. Same thing in re: Heroku, while I'm at it. Lots of people do lots of foolish things when computers get in the mix.) > I'm actually into the opposite mantra: only the tech stacks that are great at small scale are capable of being great at large scale. Note: capable, not guaranteed. I don't see how that follows? (I also don't see how that's "opposite" to the other "mantra".)