What Python Creator Guido van Rossum Thinks of Rust, Go, Julia, and TypeScript (youtube.com) 103
Python's creator Guido van Rossum shared his opinions on other programming languages during a new hour-long interview with Microsoft's principle cloud advocate manager. Some of the highlights:
- Rust: "It sounds like it's a great language — for certain things. Rust really improves on C++ in one particular area — it makes it much harder to bypass the checks in the compiler. And of course it solves the memory allocation problem in a near perfect way... if you wrote the same thing in C++, you could not be as sure, as compared to Rust, that you've gotten all your memory allocation and memory management stuff right. So Rust is an interesting language."
- Go and Julia: "I still think that Go is a very interesting language too. Of all the new languages, Go is probably the most Python-ic — or at least the general-purpose new languages. There's also Julia, which is sort of an interesting sort of take on something Python-like. It has enough details that look very similar to Python that then when you realize, 'Oh, but all the indexing is one-based and ranges are inclusive instead of exclusive,' you think, 'Argh!' Nobody should ever try to code in Julia and in Python on the same day.
"My understanding is that Julia is sort of much more of a niche language, and if you're in that niche, it is superior because the compiler optimizes your code for you in a way that Python probably never will. On the other hand, it is much more limited in other areas, and I wouldn't expect that anybody ever is going to write a web server in Julia and get a lot of mileage out of it. And I'm sure in five minutes that will be on Hacker News with a counterexample."
-
TypeScript: "TypeScript is a great language. You might have noticed that in the past six or seven years, we've been adding optional static typing to Python, also known as gradual typing. I wasn't actually aware of TypeScript when we started that project, so I can't say that we were inspired by TypeScript initially. TypeScript, because it sort of jumped on the JavaScript bandwagon — and because Anders is a really smart guy — TypeScript did a few things that Python is still waiting to figure out. So nowadays, we definitely look at TypeScript for examples. We have a typing SIG where we discuss extensions of the typing syntax and semantics and the type system in general for Python, and we definitely sometimes propose new features because we know that certain features were also originally initially lacking in TypeScript, and then added to TypeScript based on user demand, and [became] very successful in TypeScript. And so now we can see we are in that same situation.
"Because JavaScript and Python are relatively similar... Much more so than Python and say C++ or Rust or Java. So we are learning from TypeScript, and occasionally, from my conversations with Anders, it sounds like TypeScript is also learning from Python, just like JavaScript has learned from Python in a few areas."
Re: (Score:2, Flamebait)
Python is ok. Good, but not such an amazing work of genius that anyone should give a damn what it's creator thinks bout other languages.
The indentation thing I like. Python did NOT invent this. Make sure your editor does not stick in tabs when you press the tab key is all. Tab key is for indenting. Tell the editor to use Python mode.
Re: (Score:1)
I know. He created one of the most popular languages in the world so he's definitely a hack. F. him.
Re: (Score:2)
So did Larry Wall. I disagree with Larry on stuff, but it was popular and useful language. But he was annoyed with me for pointing out where it could have been done better ("you computer scientists are all alike!").
Re: (Score:2)
The irony being both created languages meant to be entirely for scripting and then they tried to bolt on Object Oriented Programming Languages. Both semi-succeeded at that, having major issues at the enterprise level. Python dependency management is still an ongoing issue (often called dev hell). Perl exploded into a spaghetti code of solutions and ways to do things. Python basically split into 2 and 3 to avoid the same issues Perl had but completely fractured their base.
Re: (Score:2)
Oh one more point. Python 2 versus 3. So if van Rossum is a genius then he failed to foresee the headache that comes from having major incompatibilities between versions (forwards and backwards compatibility).
Python did a better transition than perl at least (Score:2)
Still, Python seems to have managed it far better than Perl 5 -> Perl 6. Most large projects (like Django) seems to have made the transition, and it was possible to have libraries working under both Python 2 and 3 (with Python 2 support now mostly being dropped).
Re: (Score:2)
perl6 is an entirely different language from perl5.
I don't mean the same basic language with some behavioral gotchas that will fuck you if you're familiar with intrinsic behaviors of the old version. I mean it is a different language. Entirely.
Re: (Score:2)
Perl also had a major break between Perl 4 and Perl 5. (Versions 1 through 3 were not widely adopted.) But the Perl 5 switchover happened earlier in the public history of the language than the Python 3 switchover did, so the pain level was lower and there wasn't as much legacy code in common use. Unlike Python, just about the entire Perl community switched over to Perl 5 fairly quickly.
Perl had its own difficult transition when the proposal for Perl 6 came along, and the fact that Perl 6 was a difficult lan
Re: (Score:1)
I don't care care if this is an "infomercial" as long as the language opinions represents his actual thoughts. There's no reason to believe they are not.
Current times can be exhausting. There are so many things for which I have to pick a side. Of all the problems in the world Microsoft lands well down towards the bottom of my list. Looks like this is near the top of your list. Keep up the crusade.
Re: (Score:2, Insightful)
"Make sure your editor does not stick in tabs when you press the tab key is all".
So for Python to work you need to tell your editor to not do what it's actually supposed to do.
What a great design decision.
Re: (Score:2)
The vast, vast majority of text editors nowadays are configured to indent with spaces by default, so I would argue that this is exactly what they're "actually supposed to do", based on the prevailing expectations.
Although there's no problem indenting with tabs in Python, either. The only thing it doesn't allow is mixing spaces and tabs in the same file. Which you're never "actually supposed to do" anyway, because tab size can vary, and thus you never know how many spaces you'd need to properly line things u
Re:What I think of Python ... (Score:4, Interesting)
Python has serious memory allocation problems of its own. It allocates memory for so many short-lived values that it ends up stressing the memory allocation subsystem a crazy amount. On an application that I maintained, the guts were written in C++ and only minor bookkeeping was done (periodically, on events of interest) in Python. The C++ code very seldom allocated new memory. The total application still spent 5-10% of CPU time inside malloc or free. On a SWaP-constrained system, you can't just say "throw more cores at the problem"; that overhead comes straight out of system capacity and latency.
There's the GIL as well.
Re:What I think of Python ... (Score:4, Informative)
That is the scripting approach. It is not intended for computation-intensive things.
Do not do heavy lifting in Python, it is unsuitable for it. Instead embed C modules and use Python as glue and C&C code. I have done this several times with excellent success. You can also nicely prototype in Python and then make C classes with exactly the same interface and use comparison of results as very effective test code for randomizes unit tests.
Re: (Score:2)
Re: (Score:2)
Exactly what part of "the guts were written in C++ and only minor bookkeeping was done (periodically, on events of interest) in Python" is significantly different from that? The bookkeeping was the C&C element of the application. Python even configured the C++ to exclude most events that the Python parts doesn't care about at that particular time.
Re: (Score:2)
AFAIK that's why Ruby runs orders of magnitude more slowly
No, it's not. First of all, Ruby is not "orders of magnitude slower" than Python in the first place. Second, Javascript, Strongtalk, Smalltalk, Common Lisp all prove your speculations wrong anyway.
Re: (Score:2)
Parent has no idea what he's talking about. None.
Re: (Score:2)
Everything in Python _is_ 'monkey-patchable object at runtime'.
Btw - so is Objective-C, and its a compiled language!
Re: (Score:2)
Re: (Score:2)
A quick Google search reveals several projects that attempt to preprocess Python files, transforming brace-delimited blocks into properly indented standard Python.
I wonder whether something like that might work for those who really hate whitespace-as-code.
Also . . in my experience, regardless of language, a 500LoC code file almost certainly benefits from splitting into smaller ones. Remember that someone will have to maintain that code someday, and, conceivably, it might be you. :)
Re: (Score:2)
Re:What I think of Python ... (Score:4, Insightful)
One possible argument for braces might be that you want to use them without indenting also. But who does that?
Personally, I don't care too much. It's fine to have preferences (everybody does), but I certainly don't consider source code formatting to be on the same level as run-time bugs.
Re: (Score:1)
Re: What I think of Python ... (Score:4, Insightful)
Re: (Score:1)
To play devil's advocate: presumably, even in languages that use braces (or keywords) for code blocks, you still indent to make the blocks easy to see. Given that, Python's argument is: why not make indentation (that you're doing anyway) significant?
Because auto-indenting, copy-pasting, and adding a for-loop around a section become significantly more difficult.
Re: (Score:2)
Re: (Score:2)
The braces matter because your editor cannot automatically re-indent code correctly without knowing where each block starts and ends, which cannot be inferred from the (incorrect) indentation you are attempting to fix after moving the block of code. With braces around blocks the AST for the transplanted section of code no longer depends on the indentation of the surrounding lines, so automatic re-indentation becomes trivial.
Now Haskell has a superficially similar indentation-implies-structure system which I
Re: (Score:2)
Either you select the text you want to wrap a loop around and hit tab: then all is indented one layer deeper, and then add the loop on top, or: you select the text and chose "gode generation -> surround with ..." and pick loop. Usually the IDE can even guess what kind of loop is wanted, at least in Java, as the following container(s) are known types. (Containers as in a real array versus a Collection class).
Re: (Score:1)
Yeah, or you just manually hit tab on each line.
It's not an unsolvable problem, it's just a pain compared to other languages where you just hit command-shift-O and it all indents perfectly.
Re: (Score:2)
Well, I don't think it is a pain, and I never used auto format ... :D
Perhaps I should try it
Re: (Score:2)
You're probably just really good at indenting.
Re: (Score:2)
Psst! Truth is, sometimes I write code like this:
if(something) doIt();
else doSomethingElse();
Then I wait for the git commit log if one reformats it.
Re: (Score:2)
To play devil's advocate: presumably, even in languages that use braces (or keywords) for code blocks, you still indent to make the blocks easy to see. Given that, Python's argument is: why not make indentation (that you're doing anyway) significant?
Maybe because I do it for me, at my pleasure and discretion, and not just to make the damn code run.
Re: What I think of Python ... (Score:2)
Two words: local refactoring.
I've lost counts of the times I had to add or remove an outer block (if, for, ...) over half a function or so. If the function is something I wrote few weeks ago I may not rember - or care to dwelve into - all its branching details. But getting the indentation wrong on a line is common, and will force me to.
Not to speak of the scenario when you move a bunch of stand-alobe functions to a different namespace, e.g. a class definition...
Re: (Score:2)
Even in my generally small-ish Python scripts I do run into these issues, but I try to keep functions and files small, and to refactor sooner rather than later, and as a result they tend to be a minor annoyance only, not the huge pain they might be if I let them grow into behemoths with hundreds of LoC and things nested 10-20 levels deep.
Another post mentioned 500LoC Python files. That's already about 400 LoC bigger than what I would prefer.
And for anything over a few thousand LoC total, I tend to start th
Re: (Score:1)
I'm the one that mentioned that 500LoC thing. Sorry to horrify you, I wasn't talking about 500 LoC files, I referred to "units" (function definitions, data structures, etc) *within* (often much larger) files.
Your preference for under 100LoC files, a few thousand LoC total for Python programming just confirms that block-by-indentation makes Python unsuited for "large and complicated systems".
You'll easily reach 500LoC just validating a not too complicated web form (for example, to fill an invoice). Splitting
Re: (Score:2)
I guess we're coming from different places. But I'm fine with using a plain old hammer when it's the right tool for the job. If the job is securing the pillars for a bridge across the Atlantic, it probably isn't. But most of the time, I'm working with plain simple nails, and the plain old hammer works just fine :)
As for the limits of Python scaling, I find that whitespace is not usually the issue for me. It's more the lack of static typing (possibly now mitigated somewhat by annotations) as well as the
Re: What I think of Python ... (Score:2)
In principle yes, but an annoyance that wouldn't need to be. With braces, any decent editor can reformat code that's been copypasted.
I wrote large(er) things in Python, several thousand LoCs altogether. As to early refactoring... yes, that's easy, but I tend to view that as the daily churn of programming, not as refactoring. The *real* refactoring is when your problem domain outgrows your code architecture and you need to adjust architecture, not just function flow and API calls. And this is usually (1) alw
Re:What I think of Python ... (Score:4, Funny)
How to find someone whos never used Python: look for the guy complaining about whitespace.
Re: (Score:2)
Bit of a tautology there: somebody who thinks significant whitespace is a damn fool idea will probably avoid Python to start with, so your statement is a bit of a self-fulfilling prophecy.
Re: (Score:2)
Maintaining other people's code is always more of a challenge than writing from scratch. Especially if they are idiots. Although, for that latter reason, maintaining my own can sometimes suck as well. :)
But Python can and should read almost like pseudocode, and when it doesn't, it may be time to comment and/or refactor until it does. That is the whole point of a higher-level language. If you want it to be obscure, just write in Assembly, Intercal, or Brainf**k. If you want it to be understandable, and
Re: (Score:3)
... good, useful language with one astonishingly poor "feature" --- indenting determines code blocks
If that's the thing that bothers you, the switch to Ruby.
For me, the problem with Python is that it has the libraries I need. Otherwise I would never use it.
Re: (Score:1)
... good, useful language with one astonishingly poor "feature" --- indenting determines code blocks.
Couldn't agree more. The abandonment of "whitespace is whitespace" was a stupid design decision.
Get rid of all the syntactic sugar? Okay, sure, whatever, but then to turn around and enforce some magical whitespace constraints is just plain idiotic.
Re: (Score:2)
... good, useful language with one astonishingly poor "feature" --- indenting determines code blocks. I view that problem on the same level as languages that are prone to memory allocation problems.
And then, anybody competent has not problem with this approach. There is a problem with your skills.
Re: (Score:2)
But if your argument is that nobody competent will find that approach poorly thought out, or detrimental to the code quality, then you've made a logically fallacious argument.
For my part, I can use that paradigm just fine. I'm as capable of holding my nose as anyone else is.
But it's a stupid one. It breeds errors.
Any python programmer who tells you they haven't pulled hair out of their head fixing indenting issues during a refactor is lying.
Re: (Score:2)
Re: (Score:2)
This is an instance of Wadler's law [haskell.org]:
The bulk of discussion on programming language design centers on syntax (which is a solved problem) as opposed to semantics.
ah the Rust safety myth (Score:5, Interesting)
Rust allows and has "Unsafe Rust"... because the memory safe Rust doesn't always cut it. It's like a second language lurking in the main one because shit can't always get done with safe Rust. An operating system or system library in Rust will have to have unsafe rust. And there will be bugs...
Re:ah the Rust safety myth (Score:4, Funny)
But doesn't that destroy the Rust religion? It's like having an eleventh commandment that says "you can ignore the above if you have a good reason"!
Re: (Score:3)
Every religionist uses that excuse, though, and it does not appear to destroy their Faith.
Re: (Score:3)
That is why it is called "faith" and not insight or understanding: It is not rational.
Re: (Score:3)
In the Rust religion only the divine leader can ignore laws by divine mandate, divine intervention prevents it for everyone else. In Rust there is a god.
In the C++ religion everyone can ignore laws and any attempt at policing to prevent it from happening is comically inept. In C++ there is no god.
Re: (Score:2)
C++ style was "you can do application layer stuff while still being able to do system level code, but if you do system level code without application level features then we will taunt you mercilessly!"
Re: (Score:2)
Re: (Score:2)
Every religion has its dirty secrets, which usually invalidate the whole thing. Rust is no exception.
Re:ah the Rust safety myth (Score:5, Informative)
Re: (Score:1)
Re: (Score:2)
Unsafe Rust is limited to the code sections marked as "unsafe" whereas the whole [...] C++ application is unsafe. Those blocks are usually small and well-defined so it makes it much easier to find and fix the bugs if there are any.
That... doesn't compute.
The unsafe blocks makes it easy to find unsafe blocks. But any bugs in the unsafe regions renders the whole application unsafe, just as C++. Rust, and other languages, CANNOT guarantee safety beyond the statically checked parts of the code. The unsafe/safe boundary cannot magically stop the propagation of errors from within the unsafe block. In actuality, the "unsafe block" is actually saying "assume this code is safely written" - it's a declaration of "trust me I know what I'm do
Re: (Score:1)
Re: (Score:2)
So really, you can easily emulate Rust, and I won't be surprised if, in the future, someone implements a checker that precisely impl
Re: (Score:1)
Re: (Score:2)
It's not so hard to write a checker that forbids the use of pointers outside of functions marked with certain attributes, for example. It won't break the language, because it's not defined as part of the language, but it will be there for projec
Re: (Score:2)
That's true, but... when memory problems arise in Rust, you only have to look for bugs inside unsafe blocks, that are usually a very small percentage of the codebase. That's a big win.
Re: (Score:2)
What if your safe block is passing unexpected things into your unsafe block and you're not testing nor realizing it? Any code with an unsafe block in it is unsafe.
Re: (Score:2)
Rust allows and has "Unsafe Rust"... because the memory safe Rust doesn't always cut it. It's like a second language lurking in the main one because shit can't always get done with safe Rust. An operating system or system library in Rust will have to have unsafe rust. And there will be bugs...
Indeed. And worse, the Rust coders will not have experience doing this and will do much worse than C coders. One of the dirty secrets the Rust fanatics like to sweep under the carpet.
Re: (Score:2)
Re: (Score:2)
No, it's just me pointing out the Rust B.S. when it comes to systems programming. Any code with unsafe block in it is unsafe in its entirety. It's the Rust hype that reality will destroy; Rust programmers might turn out to be even be worse at dealing with their unsafe blocks than experienced C programmers do with system code.
TypeScript is really accelerating now... (Score:1)
I am seeing a lot of devs all over picking up TypeScript for stuff, it seems to be on the increase broadly...
Python was in the same way, I'm not sure if TypeScript is taking away developers from Python or not. It seems like at the moment the spheres of influence and work seem to be fairly separate.
Personally I didn't mind the type freedom of good ol' Javascript, but I can see the appeal in TypeScript.
Re: (Score:2)
Personally I didn't mind the type freedom of good ol' Javascript, but I can see the appeal in TypeScript.
Typescript is mainly an advantage on larger projects and larger teams. When your project is large enough that you frequently don't know what type a variable is, then it's time for typescrupt.
Re: TypeScript is really accelerating now... (Score:3, Interesting)
I used to hate typescript, but then things started changing in the structure of data coming from the server (python as it happens) that made me start to value that I could simply change the type in the ts interface and recompile and the compiler would tell me where it was being used with the old type and I'd forgotten.
I guess that's the same with pretty much any typed language... but it saved me a few times, or at least made things easier/quicker.
However, there are times when typescript failed to tell me wh
Re: (Score:2)
That means your compile time needs to be sped up.
Re: TypeScript is really accelerating now... (Score:1)
It'll never be as fast as javascript.
Re: TypeScript is really accelerating now... (Score:1)
Also, that wouldn't scale.
I'd suggest that some more modular development practices might result in a better development experience, like doing TDD or something like that, which would reduce the bulld time most of the time.
Re: (Score:2)
If you run TypeScript on JavaScript files with JSDoc comments that specify types, it will use that information to typecheck.
Re: TypeScript is really accelerating now... (Score:1)
Interesting, thanks.
Re: (Score:2)
Re: (Score:2)
Each 21st century non comp-si professional that needs to do some coding, most likely is using python. It's the 90s excel.
There are some exceptions tho, statistician use R and, as far as I know, some mathematicians still do FORTRAN
Re: (Score:1)
Python is the defacto language for non programmers:
An interesting observation but I know a number of older die-hard programmers and newer CS grads, that are all very into Python...
Have to admit I like the sound of calling it "the programmers Excel" though. :-)
Re: (Score:2)
An interesting observation but I know a number of older die-hard programmers and newer CS grads, that are all very into Python...
The lower half of the bell curve needs tools, too.
Re: (Score:2)
Excel was, and might still be, the way by which most programming is done. And by programming, I mean instructing the computer to do arbitrary work. Excel is Turing complete after all.
Julia and Python (Score:2)
This is the reason why I gave up python for julia language. Easy choice when you look at benchmarks, at least for the problems I have to solve.
Re: (Score:2)
You can tell Van R has never really used Julia if he thinks it is Python like
Somehow, I manage to switch between the two when I write code that calls Python *from* Julia.
If that's the thing that bothers you the most, perhaps computing is not for you.
Re: (Score:2)
Van R is a dumbfuck.
The primary argument for his intelligence and/or wisdom and/or competence seems to be that he created a popular language.
I suppose that proves that Kanye was right all along. He is a fucking genius.
Vendors, Standards (Score:1)
Maslows Python (Score:1)
Death pyramids (Score:1)
Can we all cheer? (Score:2)
Umm...yeah... (Score:1)
Of all the new languages, Go is probably the most Python-ic...
Except for that whole "Python sucks and Go doesn't" thing.
Re: (Score:2)
"Microsoft Reactor", apparently ;-D
go figure.