[normac]

Python occupies a niche that isn't going away any time soon: making it easy and natural to write readable, straightforward, more-or-less imperative, slightly boring code of the type you learned in CS 101.

This is still a very practical way to solve many problems and I'd wager for most programmers it's still the easiest way to do things. Maybe it will always be. It's hard to imagine there'll be a generation of programmers some day that finds it easier to compose dozens of tiny modules, chain callbacks with a variety of async abstractions, and implement as much as possible in tiny idempotent functions.

I feel like the worst case scenario for Python is that it will fade into the wallpaper of mature and unsexy languages like Java and C++ that nonetheless run the world and will probably be around for another 100 years at least. I'm guessing Guido would be cool with that.

[Gratsby]

At my work we recently needed to hire a developer. We gave them all a very basic problem to solve and told them "use any language, use any libraries". The idea was to get a feel for their coding style - do they comment their code, is their logic something the rest of the team could follow, will they address unmentioned issues, will they press for clearer requirements, etc.

A few notable solutions: 1) The C guy. Damn if he didn't blow that problem out of the water. I never want to be responsible for anything he coded. Entirely too complex, no comments, lord knows what side effects he put in place.

2) The java girl. Didn't finish. Didn't do any logging. Very logical separation of code. Lots of comments. Had to continually reference a text file in order to run the command to show output.

3) The .net guy who attacked the problem with Python. Imported a handful of libraries. Wrote 14 or 16 lines of code. Completely baffled that we would provide such an easy problem. When asked why he didn't use his strongest language, he laughed.

One of them got hired and won't have to write a single line of .net anything for a very long time.

[normac]

One of my favorite pieces of code I've written is a 150 line Python script I made to solve a really ugly text processing problem. I have tried to use it as a code sample when talking to potential employers, but it backfires because it makes the original problem look so simple that they wonder why I bothered to send it.

[gknoy]

If it's any consolation, Peter Norvig's Sudoku solver seems so readable on the surface that I've fallen into the trap of thinking it looks easy, or that I fully get it. :)

0: http://norvig.com/sudoku.html

[shiftb]

Maybe you should try a reverse interview process. Send them the original problem, ask them to have one of their top developers solve it, and then compare solutions.

[agumonkey]

Is this a real thing ?

[csense]

It should be.

[TylerE]

I once wrote a custom report generator that could pair basically arbitrary input formats (pluggable, I think by the time I was done I'd written importers for CSV, fixed width, and JSON data) and output custom PDF output, with fully-user definable formatting/elements - using XML "templates" just because I didn't want to write a custom parser. Included loops, if statements, etc, and some pretty fancy output features (e.g. output N records per page, with custom sorting, headers/footers/etc). Used ReportLab for the PDF generation. Whole thing was under 1k lines of Python 2.

[tanlermin]

Why can't Julia fill that role?

[opensandwich]

Try to do machine learning in Julia; it is difficult. If I want to say fit a gradient boosted tree or SVM its not support in Julia, whilst appears in Python/R libraries. Also, with Spark being more and more popular in the data science landscape, the lack of Julia bindings is also a no for the data scientists I work with (Spark has Python/R bindings).

[aut_dan]

You will have to reach a little deeper for machine learning methods not supported by Julia. XGBoost has a Julia interface and you can google Julia SVM for myriad of alternatives. Packages like Mocha and MXNet are a few deep learning alternatives. PyCall is also an easy solution for interfacing with Python for things such as pyspark. It also has some of the most convenient to use parallel / distributed computing tools for numerical computing.

Point being that even if Julia is not there to replace Python, there is still a strong case for using it as a way to augment Python workflow.

[eva1984]

If Julia just want to replace Python as the glue interface, it seems to have no chance winning...What it can do, as a glue layer, that Python cannot do?

[tavert]

It's much easier and lower-overhead to call into C, Fortran, and soon even C++, from Julia than it is from Python. If there's a library in Python but not yet in Julia, it's really easy to call into Python from Julia.

What you can do in Julia that you can't do in Python is write high-performance library code in the high level language. If you need to write custom code that isn't just using stock numpy or scipy algorithms right out of the box, and needs to use custom data structures and user-defined types, Julia is a fantastic choice. You can try with Cython or Numba or PyPy, but you're either working with a limited subset of the language, or forgoing compatibility with most of the libraries that people use Python for.

Julia feels like writing Python but does not allow some of the semantically impossible-to-optimize behaviors that you can find in Python, and has a type system that you can use to your advantage in designing optimized data structures for the problem at hand.

[eva1984]

Thanks for explaining this.

As to my own experience dealing with data, the degree of freedom, as basically a programmer, is small. Specifically, I have to think and bear tools in my mind from the start. Which might not be ideal, but cant avoid anyway.

[ced]

It's not meant to compete with Python as a glue language. The point is that you can start using Julia right now and be productive by calling other languages' libraries to fill in the holes.

[TheLogothete]

The questions is why would I do that? Because Julia is new?

[jordigh]

Because it's young and we still don't know how it will pan out.

[andybak]

Which role? A general purpose programming language with an emphasis on readability?

[tanlermin]

Yes...but one that is also very fast, portable and with great generic programming.

[andybak]

I had never considered Julia as a general purpose language. I assumed it was targetted mainly at data science etc.

[ced]

The core language is general purpose, and IMO really good for high-performance work, but the community is focused on numerical code, so there aren't a lot of libraries for non-numerical/scientific/financial work at this point in time.

[21]

Stuff like Numba greatly decreases the need for Julia.

C++17 also feels surprisingly dynamic, and together with Cython for easy Python-C++ interop also decreases the need for Julia.

And reports from the Julia world are not exactly encouraging - http://danluu.com/julialang/

[aut_dan]

That report is over a year old, which for a 4 year old language is a very long time. The top comment in [1] is from a week ago and highlights why it is now mostly invalid.

[1] https://news.ycombinator.com/item?id=11070764