Hacker News Reader

Comment by happy-go-lucky | Hacker News Reader

Python 3.x is the present and future of the language

A language I use daily and love, but one that will end up a dead-end I fear long-term. So much is going the way of speed now.

I'm not sure I get that. Care to elaborate, and what use cases you have for it?

OO I'd love to, but you'll have to take it with a grain of salt :)

Python is wildly popular now, and it is great for small scripts and interactive data analysis, but I don't see any real long-term strengths. It is not growing and is very slow in comparison to most languages. There are soooo many interesting projects out there. Perl6 is very immature from an implementation perspective, but is just as easy to use as Python, but has waaay more power and flexibility under the hood. The OO model is more advanced, the semantics are clean and elegant, you can do real FP, easy asynch based off of C#, grammar based programming...etc. Python can do a lot of that with modules, but having it all in one consistent package is nice. On another note, there are sooo many languages that although maybe not as flexible as Perl6, they run blazingly fast. Think of Crystal (Ruby syntax with native speed and no dependencies), Dlang, Go, Rust, Red (fast and dynamic language in a 1.3 MB runtime...you can even access a systems language DSL...the best GUI system I've ever seen). So basically we have new languages that have the advantage of an easy syntax like python, but are waaay faster and not mostly locked in place (Guido doesn't like feature bloat). There is also Elixr...etc. Python isn't dead, but I don't think a JIT is enough at this stage and I'm mostly moving on. Python's hold on scientists is being challenged by Julia which will be just as easy to use, but also once again...much faster. Let's not forget that C# is actively maintained by a large and very well funded team at Microsoft and is constantly adding new features like LINQ and now things from F#, which is a great language on its own. I don't take Haskell seriously. Note that I think it is very advanced and can be quite fast, but it is also very hard for most people to understand things like Monads (just Monoids in the category of Endofunctors...wtf) or Currying...etc. I expect Python to remain around for a very long time (you can still find Cobol at banks and I rely on Fortran every day, but I really hope it is not still in the top 5 on the Tiobe in 10 years unless Python 4 is a rewrite from scratch to have a few more features and run on LLVM...oh wait we already have Nim that is basically Python syntax transpiled to C & then compiled with gcc or clang to get ~40 years of optimizations.

My uses for python are data analysis, helper scripts, command-line apps, glue on Linux servers, glue on windows where it acts as a better CMD (I've tried powershell, but I don't gain much and often lose in speed as 8/10 ways to do something work, but are dog slow).

"All the features" is why perl is considered a write-only language. It's great for personal projects but I have yet to see any big successful perl projects because the onboarding time of learning a given perl project's chosen features is so cumbersome.

Is that serious? Lots of massive perl projects out there like Booking.com. If you search you can find an article on how they manage their +1 million plus line code base in production. It can definitely get unwieldy I bet, but you can write really good code too. I don't think having extra features makes a language bad as long as it isn't all bolted on and the community has some discipline.

A large commercial project is not the same thing. You can use whatever hideous language you want for that because you are literally throwing money at your developers to make them understand and work on the code base.

The bar is large open source projects, which indicates that it's very easy for a drive by developer to isolate a bug and fix it or implement a feature.

Perl5 by itself is a pretty large open source project as is all the 25,000+ CPAN modules, but you're correct that I'd rather not deal with the Perl5 VM itself as that is probably very arcane (although I've certainly never tried). That could just be because the language has 30 years of open source patches on it. Perl6 on the other hand was designed to be stupidly easy to get into fixing the Core and VM. Instead of being written in C, it is written in a limited Perl subset "NQP" or "Not Quite Perl" that is much easier to read. They've had several blog posts about tracing an error pack to the source and fixing it. I'm not sure if P6 will continue steaming ahead into a true production language, but i really hope it does as it is so nice.

I doubt that. Most of the cited competitors to python are either seriously flawed (e.g. go) or aren't really competing on the same turf (e.g. rust/haskell).

Speaking as someone who really loves Haskell -- let's be real, it's not serious competition against Python or Rust, same turf or not. It's a fantastic language for numerical computing and its applications, and for compilers/parsers, but it's never going to be as easy to use for the layman as an imperative language.

As someone who's used Go and who has some mixed feelings about it, I'm curious -- what do you find flawed in it?

Go is not flawed (I mean, of course it has issues), but it's not the same thing/area

> Go is not flawed

For most technologies (with some notorious exceptions) that boils down to a matter of opinion an intended use cases.

>what do you find flawed in it?

* Package management

* The weird and approach to exception handling (which leads to overly verbose code)

* Lack of generics (which leads to overly verbose and somewhat hacky code)

* Vastly smaller 3rd party ecosystem

I think it works well for a very small subset of sysops-style problems (small servers, small command line tools, etc.) especially since it easily compiles into one small, portable binary, but outside of that it flounders.

Thanks for following up! Those are some of my gripes with the language too. The vendoring system/would-be package manager especially has caused me hours of headaches, and I'm glad to hear I'm not the only one who considers it broken.

Well Python is a portable layer of the scientific code written in C/C++/Fortran and a better bash. The reason projects like Pandas, Tensorflow etc. uses it is because it is extremely easy to write a script like code in it that does the heavy lifting in the aforementioned languages. If you had to implement Pandas (more specifically DataFrames) in pure Python it would be extremely slow. With other words Python is an excellent glue languages. I quite often see that people implement complete systems in pure Python when they realise it is too slow or to complex to be maintained. Go at least fast and has proper concurrency while Rust and Haskell are properly typed and supposedly safe. I am not sure if any of these are competitors of Python though.

Agreed, but with things like Crystal coming out, you can still use it as elegant glue, but it will be stupid fast too. One language for everything.

numpy on pypy may well solve that issue for python though.

Pypy isn't very fast, but i guess that plus calling out to the Fortran numpy libraries should be fine for numerical work, but now you have to worry about a JIT, big library, runtime...etc. With something like Crystal, Nim, or Red you get a single small binary at the end of the day and nothing else. I guess to each his own, but I honestly feel like we've overcomplicated things.

Pypy is as fast as or faster than c/c++ in some applications/benchmarks.

And with python (or interpreted langs in general) you gain a repl, a shorter write -> compile -> test loop, and generally speaking a higher rate of development.

I'd agree though, I do want some way to deploy a "python binary" that isn't essentially a virtualenv.

Oh yea I know all about the power of a REPL. My friends with their massively bloated IDEs can't understand my desire for a simple read-eval-print-loop. I gain simplicity and instant satisfaction. Some languages like F# heavily promote both. I didn't think PyPy could be that fast. How on earth could it ever compete with C?

Jits are magic man.

Like I said, it depends on the application. For numerical-heavy code, where you're going to be using numpy hooking into MPI or LAPACK, C or similar code will win, it takes more advantage of things.

For more complex code, say a webserver, pypy can compete and win, because pypy gets the advantage of, after the jit warms up, essentially profile guided optimization, which means that pypy can, assuming there's some kind of loop (there always is), optimize the hot code paths, and the surrounding code to abuse hot code paths, and it can optimize the hot code paths really really well, better than gcc could normally, because it has additional information (pypy knows how the code is being used at runtime, whereas gcc only knows what information is available to the compiler: types and directives really).

PG was talking about viaweb and dead languages in an interview I won't spend 10mins looking for; but he said something like:

Latin is a dead language and no one speaks it. Sure it is helpful for understanding other languages, but I never got that comparison because the computer always speaks it.

Certainly imperfect paraphrase, but the crux is that you can always code python, or lisp ect.

For those who want an alternative there is the community continuation of Python 2.8, called Tauthon:

https://www.naftaliharris.com/blog/why-making-python-2.8/

Those that go on this path will then find out they have gained nothing and only lost time by not updating their systems

and many (like me) who have painfully moved to Python 3 will find that they have gained nothing important there either other than avoiding the "end of life" blackmail.

> avoiding the "end of life" blackmail

People usually think that costs nothing, until they get bitten by it.

Reply on news.ycombinator.com