News for hackers. Stuff that matters.
Re:Ask HN: Is Python dying? by switchbak on Sunday February 14, 2016 @10:22PM (#11101350)
I wouldn't say Python is dominant in startups across the board. Though it is strong in data-heavy environments (with all it's issues nonetheless).

I've been a Pythonista for over a decade, and the API scene isn't quite as utopian as you describe. Date/time handling in particular is a really poorly handled area, but there's quite a few out there.

That said, in general I agree the 'batteries included' approach is good, and the libraries _tend_ to be easy to use for most tasks. Compared to most Java libraries, it's a breath of fresh air.

Re:Ask HN: Is Python dying? by ForHackernews on Monday February 15, 2016 @01:06AM (#11101763)
> Date/time handling in particular is a really poorly handled area

Just use Arrow http://crsmithdev.com/arrow/ everywhere, all the time(s). Now your date/time problems are solved.

Re:Ask HN: Is Python dying? by kdeldycke on Monday February 15, 2016 @04:51AM (#11102459)
Couldn't agree more. Developing for the last couple of years code that is highly sensitive to dates and time, and Arrow saved my life.
Re:Ask HN: Is Python dying? by meowface on Sunday February 14, 2016 @11:21PM (#11101495)
I think there's more of an interest in scalability and compile-time checking among startups nowadays, hence the shift from dynamic languages to lightly static languages like Go or all of the type-checking and Haskell-derived JS variants out there.

This means Python and Ruby aren't as much of a first choice as they used to be, even if they're arguably a lot faster for getting MVPs out.

Re:Ask HN: Is Python dying? by snuxoll on Monday February 15, 2016 @01:31AM (#11101830)
> I think there's more of an interest in scalability and compile-time checking among startups nowadays

Which is precisely why all of my new code targets Python 3 and I use PEP 484, and before that I always had type information in my docstrings. There's some places where duck-typing makes sense, but a lot of times I'm really just doing things like I would in a statically typed language so I just type the crap out of everything and run MyPy against it.

Unfortunately the runtime itself doesn't benefit at all from the type information, but I know I any of my .Net-centric colleagues can easily inherit any of the Python code I've written and be able to read it without much headache - without having to intuit what magic goes on behind the scenes, especially with things like the Pyramid request/context objects.

Re:Ask HN: Is Python dying? by cyphar on Sunday February 14, 2016 @11:15PM (#11101477)
> Though it is strong in data-heavy environments (with all it's issues nonetheless).

Which is why numpy and scipy are so full-featured and pretty damn fast.

Re:Ask HN: Is Python dying? by drvortex on Sunday February 14, 2016 @11:44PM (#11101562)
Techincally, Numpy and SciPy are C and Fortran extensions to Python, not Python code.
Re:Ask HN: Is Python dying? by gh02t on Monday February 15, 2016 @12:03AM (#11101611)
I'm not sure if that's the best way to describe them. IMO, NumPy/SciPy are probably best described as Python wrappers for a wide range of C and Fortran codes, but they add quite a lot of value on top of that. If you've ever used e.g. LAPACK or VODE directly, you'll probably have horrible memories that you prefer not to recall. NumPy and SciPy have a large contribution in that they unify (admittedly, neither is really a paragon of consistency, but...) a huge range of disparate libraries under a much more accessible interface.

To say NumPy or SciPy is just the sum of the libraries it uses is a bit like calling MATLAB a fancy interface for LAPACK. That really was what MATLAB was intended to be originally, but to reduce it to that is missing the appeal. As somebody who absolutely loathes MATLAB, even I wouldn't think that is fair.

Re:Ask HN: Is Python dying? by Scarblac on Monday February 15, 2016 @09:56AM (#11103650)
Libraries are what make a language.

The major feature of Python for me is that all its various open source modules for anything n-dimensional (matrices, image processing, GIS, machine learning, etc etc) all use the same data structure: the Numpy array. It's basically part of the standard library that is developed outside of it for pragmatic reasons. And with the speed of Fortran array operations.

That's something that only Matlab really has as well, but Python is much better in other aspects.