5 ms·

Isn't it also just as much about Python is having it's day, granted a day long in the waiting but many langs go through this (Ruby, PHP) and then it tapers off

by botto 7y ago

Isn't it also just as much about Python is having it's day, granted a day long in the waiting but many langs go through this (Ruby, PHP) and then it tapers off and the next language has it's day. Probably Go will be the next hotness in 5 years.

Ensorceled 7y ago
Maybe, I love Go but I'm not sure it's the next "hot" thing, all the recent "hot" languages have been scripting languages PHP, Ruby, Python, JS ... I'd say JS and Python are currently jockeying for that position.
- danielscrubs 7y ago
  Isn’t JS one of the most popular languages? It has a monopoly in the browser so that and C++ already has the most impact on users. Hard to see how it can become more popular.
  - arcticfox 7y ago
    The server-side of things can start eating away at other languages. Node.JS is obviously already very popular but it can still grow massively. I for one have started running TypeScript on my servers whenever I can, I love it. There's still room for improvement though.
    - lioeters 7y ago
      > running TypeScript on my servers I'm curious, do you mean compiling to JS and running it on the servers? Because I would love for the runtime itself to run TypeScript, something like Deno [0] but (maybe in the future) as mature as Node.js. [0] https://deno.land/ https://deno.land/
  - saagarjha 7y ago
    > It has a monopoly in the browser Well, there’s WebAssembly…
  - Ensorceled 7y ago
    That's what I mean: Python and JS are jockeying for position as the hot language right now.
- gwd 7y ago
  > all the recent "hot" languages have been scripting languages All the languages you list are over 20 years old. I think the popularity of Go and Rust show that statically-typed languages are having a resurgence. As a long-time C programmer (with significant bits of bash and perl on the side), I've really enjoyed learning Go. But the responsiveness to developing new language features has been _sooo sloooow_. We'll have to see in 10 years if this turns out to have been a wise decision or not.
  - Ensorceled 7y ago
    You could be right, especially as microservice architectures are very popular.
mises 7y ago
Yes and no. Go has its applications, but is not built to replace python but rather to be a better c. That overlaps with the "easy code" part and not much else. Glue code, application scripting, etc. are python's strengths, and I don't see those going away.
- growtofill 7y ago
  Source on your claim? The best I was able to find is this: > Go attempts to combine the development speed of working in a dynamic language like Python with the performance and safety of a compiled language like C or C++. https://techcrunch.com/2009/11/10/google-go-language/ https://techcrunch.com/2009/11/10/google-go-language/
syntex 7y ago
Actually, Golang isn't so great. Try to change something lower level, for example in their socket implementation. Also, it's trying to promise a sane concurrency and all code I've seen use mutex all over the place.
- nighthawk648 7y ago
  The main reason I get so curious as to why so many developers would rather use premade packages then spend r&d into highly optimized solutions.
  - lioeters 7y ago
    As someone with a tendency towards writing my own custom solutions (from scratch or forked), I'm learning the hard way why people prefer depending on premade packages: they're usually better documented, better tested (both written tests and real-life battle-tested), and in a team/collaborative environment, having some canonical packages that everyone is familiar with helps to have common understanding, rather than having to explain how a one-off custom solution works.
    - takeda 7y ago
      It really depends, I've seen many examples where: 1. the package offering the functionality I needed was much more complex than needed and my solution implementing that functionality was much simpler (because it implemented only what I needed) 2. was not the best quality, because it was written by someone who was not necessarily better than me, or didn't spent enough time understanding the problem he was trying to solve Having said that generally popular packages are good quality, although even then #1 applies, if you need just small functionality of a specific package try implement it yourself, it might turn out that the problem was not as hard as you thought and because you're just implementing what you need it might be more elegant.
- lijogdfljk 7y ago
  > Also, it's trying to promise a sane concurrency and all code I've seen use mutex all over the place. I think that's a fault of the devs, more than the language. In many cases (not all, of course) Go gives you multiple ways to achieve concurrent safety. Channels, being the big secondary. Yet it generally (in my experience) requires a very different implementation and in general has a lot of pitfalls. Over all I don't like Go these days, but I prefer it over Python (mostly due to at least having basic types) I've switched everything to Rust though. Just as productive as Go (to me), with more tooling. Though, Rust will be much better in a couple years with some additional baking on new features (GATs, Futures, etc).
Rotareti 7y ago
> Probably Go will be the next hotness in 5 years. I think it will be difficult to grow a large ecosystem for a language with very poor FFI performance [0] in the long run. Golang's poor FFI performance is the number 1 reason I wouldn't use it for my own projects. [0]: https://github.com/dyu/ffi-overhead https://github.com/dyu/ffi-overhead
- naikrovek 7y ago
  People gripe about the strangest things. After using Go almost exclusively for about 18 months I have had to interface with existing C libraries exactly zero times.
  - Rotareti 7y ago
    I think you don't get the point. Most people don't create such interfaces, but the libraries/systems they work with use them a lot, at least in other languages. This is for example the reason why there won't be a large mathy/scientific ecosystem in golang.
    - justinclift 7y ago
      > This is for example the reason why there won't be a large mathy/scientific ecosystem in golang. That seems weird. Go has a pretty large (and growing) Data Science Community. Lots of Math/Scientific stuff there, especially including many people from Python and Ruby backgrounds.
    - jerf 7y ago
      Python needs FFI, because its native performance is fairly poor [1]. In general, Go gets away with less FFI because it's fast enough that it doesn't need things to be implemented in C to run quickly. This is especially true if you consider "Go" as "Go + its ASM", which is probably what you'd want if you think of it in terms of science programming. For another example of a similar effect, Rust has great FFI. Yet I would expect over time it will be necessary for fewer and fewer things, because Rust is already roughly on par with C, and over time, a native Rust API will still be preferable to a C API wrapped with a Rust access layer. It will always have great C FFI, by its nature, but the percentage of projects that won't need it is already pretty high and probably only going up over time. [1]: People seem to misinterpret this statement a lot, as if I'm saying Python is bad or something. No; it is simply this: Python performance is not very good at a very raw level. It is merely one characteristic of a language out of many, many relevant ones, not a full assessment of the language. Python has many other dimensions in which it has superior capabilities. It just pays for that on the performance dimension. (Whether that's an essential or an accidental tradeoff, well, ask me again in ten years; the programming language community seems to be in the process of working that out right now.)
tyingq 7y ago
I'm sort of wondering if there might be a PHP resurgence. Things have gotten much better recently. The historical warts are easier to avoid now.
- ProZsolt 7y ago
  I was a PHP hater before but in my last job, I had to rewrite a big chunk of code from PHP 5.x to 7.2. Actually quite liked it. I would happily work with PHP 7.2+ code in any day but still wouldn't start a new project in it.

by botto 7y ago

Ensorceled 7y ago

Maybe, I love Go but I'm not sure it's the next "hot" thing, all the recent "hot" languages have been scripting languages PHP, Ruby, Python, JS ... I'd say JS and Python are currently jockeying for that position.

danielscrubs 7y ago
Isn’t JS one of the most popular languages? It has a monopoly in the browser so that and C++ already has the most impact on users. Hard to see how it can become more popular.
- arcticfox 7y ago
  The server-side of things can start eating away at other languages. Node.JS is obviously already very popular but it can still grow massively. I for one have started running TypeScript on my servers whenever I can, I love it. There's still room for improvement though.
  - lioeters 7y ago
    > running TypeScript on my servers I'm curious, do you mean compiling to JS and running it on the servers? Because I would love for the runtime itself to run TypeScript, something like Deno [0] but (maybe in the future) as mature as Node.js. [0] https://deno.land/ https://deno.land/
- saagarjha 7y ago
  > It has a monopoly in the browser Well, there’s WebAssembly…
- Ensorceled 7y ago
  That's what I mean: Python and JS are jockeying for position as the hot language right now.
gwd 7y ago
> all the recent "hot" languages have been scripting languages All the languages you list are over 20 years old. I think the popularity of Go and Rust show that statically-typed languages are having a resurgence. As a long-time C programmer (with significant bits of bash and perl on the side), I've really enjoyed learning Go. But the responsiveness to developing new language features has been _sooo sloooow_. We'll have to see in 10 years if this turns out to have been a wise decision or not.
- Ensorceled 7y ago
  You could be right, especially as microservice architectures are very popular.

mises 7y ago

Yes and no. Go has its applications, but is not built to replace python but rather to be a better c. That overlaps with the "easy code" part and not much else. Glue code, application scripting, etc. are python's strengths, and I don't see those going away.

growtofill 7y ago
Source on your claim? The best I was able to find is this: > Go attempts to combine the development speed of working in a dynamic language like Python with the performance and safety of a compiled language like C or C++. https://techcrunch.com/2009/11/10/google-go-language/ https://techcrunch.com/2009/11/10/google-go-language/

syntex 7y ago

Actually, Golang isn't so great. Try to change something lower level, for example in their socket implementation. Also, it's trying to promise a sane concurrency and all code I've seen use mutex all over the place.

nighthawk648 7y ago
The main reason I get so curious as to why so many developers would rather use premade packages then spend r&d into highly optimized solutions.
- lioeters 7y ago
  As someone with a tendency towards writing my own custom solutions (from scratch or forked), I'm learning the hard way why people prefer depending on premade packages: they're usually better documented, better tested (both written tests and real-life battle-tested), and in a team/collaborative environment, having some canonical packages that everyone is familiar with helps to have common understanding, rather than having to explain how a one-off custom solution works.
  - takeda 7y ago
    It really depends, I've seen many examples where: 1. the package offering the functionality I needed was much more complex than needed and my solution implementing that functionality was much simpler (because it implemented only what I needed) 2. was not the best quality, because it was written by someone who was not necessarily better than me, or didn't spent enough time understanding the problem he was trying to solve Having said that generally popular packages are good quality, although even then #1 applies, if you need just small functionality of a specific package try implement it yourself, it might turn out that the problem was not as hard as you thought and because you're just implementing what you need it might be more elegant.
lijogdfljk 7y ago
> Also, it's trying to promise a sane concurrency and all code I've seen use mutex all over the place. I think that's a fault of the devs, more than the language. In many cases (not all, of course) Go gives you multiple ways to achieve concurrent safety. Channels, being the big secondary. Yet it generally (in my experience) requires a very different implementation and in general has a lot of pitfalls. Over all I don't like Go these days, but I prefer it over Python (mostly due to at least having basic types) I've switched everything to Rust though. Just as productive as Go (to me), with more tooling. Though, Rust will be much better in a couple years with some additional baking on new features (GATs, Futures, etc).

Rotareti 7y ago

> Probably Go will be the next hotness in 5 years. I think it will be difficult to grow a large ecosystem for a language with very poor FFI performance [0] in the long run. Golang's poor FFI performance is the number 1 reason I wouldn't use it for my own projects. [0]: https://github.com/dyu/ffi-overhead https://github.com/dyu/ffi-overhead

naikrovek 7y ago
People gripe about the strangest things. After using Go almost exclusively for about 18 months I have had to interface with existing C libraries exactly zero times.
- Rotareti 7y ago
  I think you don't get the point. Most people don't create such interfaces, but the libraries/systems they work with use them a lot, at least in other languages. This is for example the reason why there won't be a large mathy/scientific ecosystem in golang.
  - justinclift 7y ago
    > This is for example the reason why there won't be a large mathy/scientific ecosystem in golang. That seems weird. Go has a pretty large (and growing) Data Science Community. Lots of Math/Scientific stuff there, especially including many people from Python and Ruby backgrounds.
  - jerf 7y ago
    Python needs FFI, because its native performance is fairly poor [1]. In general, Go gets away with less FFI because it's fast enough that it doesn't need things to be implemented in C to run quickly. This is especially true if you consider "Go" as "Go + its ASM", which is probably what you'd want if you think of it in terms of science programming. For another example of a similar effect, Rust has great FFI. Yet I would expect over time it will be necessary for fewer and fewer things, because Rust is already roughly on par with C, and over time, a native Rust API will still be preferable to a C API wrapped with a Rust access layer. It will always have great C FFI, by its nature, but the percentage of projects that won't need it is already pretty high and probably only going up over time. [1]: People seem to misinterpret this statement a lot, as if I'm saying Python is bad or something. No; it is simply this: Python performance is not very good at a very raw level. It is merely one characteristic of a language out of many, many relevant ones, not a full assessment of the language. Python has many other dimensions in which it has superior capabilities. It just pays for that on the performance dimension. (Whether that's an essential or an accidental tradeoff, well, ask me again in ten years; the programming language community seems to be in the process of working that out right now.)

tyingq 7y ago

I'm sort of wondering if there might be a PHP resurgence. Things have gotten much better recently. The historical warts are easier to avoid now.

ProZsolt 7y ago
I was a PHP hater before but in my last job, I had to rewrite a big chunk of code from PHP 5.x to 7.2. Actually quite liked it. I would happily work with PHP 7.2+ code in any day but still wouldn't start a new project in it.