Hacker News Reader

Comment by yout2 | Hacker News Reader

I think the time is ideal for the "next Python". A new, general-purpose, beginner-friendly language focused on readability, but designed from the ground up with the techniques & features learned in the past 2 decades.

Python has added lots of features to stay current with the latest trends in programming languages, but this has come at the cost of complexity and redundancy (e.g. look at all the ways to format strings or do filesystem operations). And many of the new features such as type annotations have a compromised design due to their being added to Python late in the game. Python's "batteries included" approach of a large standard library was a great asset in the days before package managers but these days I think it would be better to start with a much leaner stdlib and add things in more stringently.

View on HN

I agree with you except the last bit - I want a giant language with professionally developed official libraries. Not some junkies slapping half-baked libs together. There is so much calm and peace that comes with std libs. It's not mutually exclusive. You can have a well crafted and large std lib and still can use external libraries. Nothing is stopping you from BYOL.

I would also want some kind of a typing support, ala Pydantic built in. If for nothing else, I would like to know wtf is this function taking in as args.

Can we also run this in a browser!? One can dream.

I agree with you that it's great to have a comprehensive stdlib but I think the process should be careful and gradual. Python's stdlib has a lot of stuff that is not really best-in-class or consistent in design. I think with today's ubiquity of package managers, we could get away with a smaller stdlib initially, and take time to validate libraries with real world usage before blessing them with official status.

Indeed, but from your own original comment - we have hindsight. So we can build an excellent std lib from the get go.

There are other bundles that are very popular for a reason. Conda. That's all you need to know. People want stability of dependencies, not wild wild west on pulling libs from random github repos.

IMO the bundling and curation is the least interesting part of Conda. What's really nice are the build infrastructure, quality checks and proper dependency bounds (looking at you, PyPI). Something like R's CRAN already has those without bundling.

Can poetry do that or that’s different?

Poetry is pretty much a Setuptools replacement, with optional features to help manage Python virtual environments.

It's not a package manager and it does not provide any environment isolation of its own. Conda provides both of those things, and quite a bit more.

They are totally different tools. Conda is more like Homebrew than Poetry.

What Poetry and Conda have in common is a not-really-bad dependency resolver.

And now we have Mamba, which is just like Conda. Except it has a better-documented (and more open) tooling ecosystem. And it lacks the debilitatingly slow/unreliable dependency resolution of Conda.

https://mamba.readthedocs.io/en/latest/

Most languages would probably benefit from having a “experimental for the standard lib” package that doesn’t guarantee perfection, and might get deprecated then abandoned before making it to the stdlib. But all new features go through that library first.

That experimental library could even be backed by other packages, so you could iterate on the interface while allowing other packages to continue to improve the core. But the assumption is for any clearly solved problem, these “batteries” provide one recommended way to solve the problem, and as of now it’s either the only or at least not the worst way to do it.

Language features either can, or cannot, be used.

Claiming that a language user should be prepared for certain parts of the language to disappear is a perfectly reasonable idea. But in practice it does not work. Because either it can or cannot be used, and if it can't be used it is a waste of time, if it can be used it must be supported.

Once people use a library, there will be pressure to support it forever and the mindshare switch is a real cost. A language bleeds users every time it drops a feature. The Python namespace is still polluted by documentation and tutorials talking about how to do things in v2 too.

Rust seems to handle it ok. Features can spend a long time being nightly-only gated behind feature flags, while nevertheless seeing real world usage from people willing to brave the risk and churn.

But Python has a very different release schedule. Rust's nightly releases nightly and stable every six weeks, while Python only releases once a year. I don't think it could adopt the same model.

>Claiming that a language user should be prepared for certain parts of the language to disappear is a perfectly reasonable idea. But in practice it does not work

Well, it can. That's what you get when there's no official package and you depend on third party packages that change all the time (e.g. common in the Node ecosystem, in GTK+ land, etc.), or are abandoned, etc.

Compared to that, a scheduled, anticipated process for candidate packages to include in the language (or remove eventually) is much easier.

Standard library works pretty much in every platform the language targets, a random package on a package manager might be available, with luck.

I would also like pip and packaging "fixed", which from my standpoint of a python software user is "broken". The three I rely on are in a constant cycle of breaking each other.

...although that might all be the fault of aws-cli. Which by the way doesn't install on a vanilla Ubuntu 20.04 ami via apt which is just... really really bad.

Aws cli continues the inexplicably horrible aws interface that makes me shake my head at people lauding their might, along with their console.

The console rewrite... anyway, pip seems to be a headache, certainly not as good as gems.

I love how you can tell which parts of aws-cli were written by different teams because of how the inconsistencies are consistent within a certain domain.

For god’s sake at least let requirements install in order.

Are there scenarios where this doesn’t happen?

I had a quick look in pip and install order is predicated on requirements order https://github.com/pypa/pip/blob/c188d1f08f1a4a2c0a03e397f15...

I finally switched to poetry for python deps and happy ever since. It’s basically the gems approach applied to python.

I would prefer a simple language with a giant stdlib. Every common protocol/algorithm should be in the stdlib.

This seems too hard to evolve.

I'd instead aim for a language that supported interface/trait/typeclasses with a huge standard library of those that allowed writing uniform benchmarks and unit tests to every implementation that shipped simple implementations for some of those and made it easy to use different implementations and experiment with them.

This seems like solving just dependency injection instead of trying to solve every library ever, which seems a much more realistic problem to solve correctly, or at least in a way better way.

Fortran then :-)

I think a lot of the benefits can be achieved by making more sophisticated types a first class citizen in the language. So for example things like date/time, intervals, and geometries are just another type. And you use normal operators to interact with those types and invoke algorithms.

Visual Basic .NET is your perfect beginner language with a rich built in framework and standard library. Ironically, it likely fell for the same reason discussed in this article: It got a lot more complex over time.

It's not ... possible/viable at this time.

Every common X means thousands of complex things. There are over 9000 RFCs (insert Vegita meme). Even more popular APIs, libs, algorithms, whatevers.

Even basic support would be near impossible. A constant race between what constitutes basic and releasing it. (Plus upkeep/maintenance, as things continue to evolve at a rather fast pace.) And if the language enjoys at least a minimal level of successful then a lot of non-stdlib packages are likely to become standard by convention.

It's no wonder that new languages nowadays start with minimal stdlibs.

(I just noticed that there's an SMTP server in Python3! It's ... great, I guess. But there's no DNS resolver library. So either the SMTP client (and now server) packages do not handle anything related to DNSSEC / DANE / TLSA / MTA-STS / DKIM / DMARC and others, or they bundle it. Sure, maybe it's enough to outsource these to the upstream SMTP server and the SMTPd package is just for "testing" ... but, this just shows how arbitrary "commonness" is.)

I agree about the stdlib. There was a reason that xkcd had the "import gravity" joke. One of the reasons I ditched perl was having to evaluate so many different perl libraries, which would do anywhere from thirty to eighty percent of what I needed, and tended to come with some really exciting dependency chains.

I know the mantra is that the standard library is where things go to die, but I believe that to be cultural. I still have code running somewhere probably that uses the cgi library, which was perfectly well-suited for a Windows serve where the page in question got an average of seven hits a day, never to scale much beyond that (you'll have to trust me on this, for amusement I reviewed ten years of logs for just that page to find nothing out of the ordinary, and there are reasons it would not need to "scale" in the future).

Each library and each string-formatting method and so on is a choice, and those choices impose a lot of speedbumps and cognitive friction.

Anecdotally, this approach has been replicated by go. The stdlib in go is surprisingly complete. I’ve seen several go developers cite this as an advantage, being able to write many apps without adding dependencies from external to the language runtime.

I definitely think they’re onto something. Dependencies are a hard problem to solve.

Modern build tools like gradle work great at resolving deps, until they don’t and at that point we’re in for a world of shock at just how complex dependency resolution can be in large projects.

How I dream of a future language with the power of rust, ease of python, and the ability to work in a browser.

Rustonscript :-)

Sounds not far from https://nim-lang.org/

I'm thinking ReasonML or OCaml might be able to take on this role.

I was sad to hear about the change to ReScript though. ReasonML targeting the browser and native seemed nice to me, although I do agree the documentation situation and DX wasn't ideal.

Hindley-Milner typing systems are a great way to introduce typing without making beginners afraid of it. The inference make things just work, the way a beginner may expect from the computer.

Is there a specific advantage to running in the browser versus running in everything at the OS level? I've always been a little confused why are abstractions went all the way up to the browsers. It seems that you could push a lot of browser functionality down the stack and simplify a lot or architectures and remove a lot of cruft we don't need.

Deployment is easier. Upgrade is easier. Access control, restrictions, permissions; you don’t have to add a user account to namespace/sandbox a process in browser tab.

The facilities provided by a browser are almost (but not quite) a complete superset of those provided by an OS. file io, peripheral io, etc. Can all be done via the browser. Additional facilities are provided too (security/sandboxing).

Right, but you could implement all of that at the OS level too, which to a large part of my understanding is what things like docker is built on. Changes to the kernel to allow sandboxing at the kernel level for instance versus doing it in user space (which browsers could theoretically implement with syscalls now?), and would reduce a lot of overhead no? Or are browsers faster because they stay in user space and avoid context switching?

I don’t think so - OS’s have been around much longer than browsers. People have been trying (without anywhere near the success of browsers) to do cross platform deploys for almost as long as OS’s have existed.

Now a common model has arrived (dom + js) allowing multiple browsers to just run your app.

I’m not sure browsers are faster (there was a thing called pepper api in chrome and nacpi or something in firefox - i’m not familiar with the space) that allowed native code to run.

I’m not sure browsers are generally faster than native OS binaries, but they are an easy to deploy to environment that doesn’t need syscall emulation like freebsd can do for running linux binaries.

Say not browsers, but linux becomes the dominant OS in existence on all platforms, not just embedded and server. Does that move the most targetable platform back to the OS level instead of the browser level if we are going off the metric that human interaction and ease of use is more heavily weighted than all possible machine interactions?

Yeah probably, but there would still be the open question of distribution and update (inc dependencies).

You still have to click on the update button for a browser, and as far as apps on your machine go, they could just check for updates next time the application is launched like current web apps/web sites do. What you are saying is not impossible for the OS to take back. It seems more like there just isn't momentum to push browser features down the stack back into the OS and I'm not sure why other than browsers already do it, so why backport it.

I think the point is more to use it instead of javascript.

What do you mean by it? The browser itself? In that case, everything done in the browser could theoretically be pushed down a level from user space into kernel space, potentially saving a lot of overhead, no? The only trade of I imagine is the context switch you hit from doing everything in userspace, but as far as I'm aware, even browsers have to eventually hit the kernel for at least raw input output on the network.

Why not let the OS do more and more of the complicated technical stuff, simplifying the deployment of web apps because now we don't have to know a thousand different bloated libraries, just a slowly updating set of OS APIs.

I'm not sure I care about the "run this in a browser" part (unless someone developed a WASM backend for it). And FOSS would be a requirement for me. Given those criteria, I would gladly pay a recurring subscription or donation for such a language.

For what it's worth, there are a lot of good interesting languages out there that aren't Python and have pretty good library ecosystems. Kotlin, Elixir, and Elm come to mind. But they don't exactly fit the Python niche.

What you're describing sounds to me like a modernized Common Lisp with commercial backing. Rework CLOS a bit, clean up some of the other crufty old weirdness, and give me a big selection of high-quality well-supported libraries like Numpy, FastAPI, Trio, etc.

The advantage of doing it in some Common Lisp derivative is that things like React JSX are pretty much "free" and wouldn't much seem out of place, whereas in Javascript they need a whole separate build/compilation step and are often portrayed as black magic fuckery.

edit 1: Arguably Julia could be used for a task like this, but its library ecosystem and language runtime are heavily skewed towards numerical computing and data analysis.

edit 2: Raku also sounds like a possible candidate here, but it obviously lacks widespread adoption and last I heard it fell significantly short of Perl 5 performance. I'm not sure what kind of library ecosystem it has nowadays and I doubt we're going to see big commercially-backed library development efforts for it, soon or ever. Perl 5 has a huge ecosystem of course, but it's such a nasty warty language with nasty warty tooling.

I use Clojure for that reason. You can use Python libraries with it as well as Java libraries and JavaScript libraries. Its reach is just phenomenal. And indeed, its React support is amazing.

I didn't know about the Clojure-Python interop. This is the library you use for it? https://github.com/clj-python/libpython-clj

Yes exactly. These blog posts have nice little guides on using it:

http://gigasquidsoftware.com/blog/2020/01/10/hugging-face-gp...

http://gigasquidsoftware.com/blog/2020/01/18/parens-for-pypl...

http://gigasquidsoftware.com/blog/2020/01/24/clojure-interop...

And you can try it out in nextjournal online notebooks like here: https://nextjournal.com/kommen/gigasquids-libpython-clj-exam...

If you like Raku, and the large Perl 5 ecosystem, you might consider going the path of Raku, as it allows 99.9% of the Perl 5 ecosystem to be used as if it is Raku, by installing the Inline::Perl5 module. Once that it done, using a Perl 5 module is as easy as:

    use DBI:from<Perl5>;

> Raku ... lacks widespread adoption

Right. It clearly doesn't have a strong enough offering at the moment to attract anyone beyond a few early adopters.

> last I heard it fell significantly short of Perl 5 performance

Likewise. I'm pretty sure Perl still roundly trounces it for a lot of operations, especially in regex processing. I think it will need to be significantly faster than Perl before it will have a chance at gaining significantly more adoption.

> I'm not sure what kind of library ecosystem it has nowadays

The raku.land directory has less than a thousand packages and many seem to be jokes, unloved, poorly tested and documented, version 0.x, or even 0.0.x. [0]

The standard library is a different ballgame. It's generally well designed and very large, cutting out the usual blizzard of folk reinventing the wheel for basics. So that's good.

> I doubt we're going to see big commercially-backed library development efforts for it, soon or ever.

I agree.

> Perl 5 has a huge ecosystem of course, but it's such a nasty warty language with nasty warty tooling.

This is where I think Raku's strength lies.

A lot of the effort that went into Raku was to build a platform that could just directly use tooling and libraries of other PLs while insulating developers from their downsides.

That way you get to use Raku tooling, syntax and semantics at the surface level with other PLs' tooling and modules and performance. Kinda like using C code in a non-C PL, but generalized to using code from any other PL in Raku.

The exemplar was supposed to be Perl, but it was also supposed to extend to many other PLs. Starting 7 years ago this became the Inline family.[1]

Inline::Perl is the most mature. Imo it's remarkable. But it was always supposed to just be the first one to get the polish to demonstrate that the approach works and works great. About a year ago the author behind it said it was nearly time to do the same for Python modules. And now I see a GSOC proposal to do that.[2]

The Inlines hide the warts (though you do have to read the modules' documentation to know what their API's are etc).

I think the impact of Inline Python will be huge because it takes away the complaint about reading Perl documentation and code. Instead you read Python API docs but get the benefits of using Raku.

(And, in the wings, there's Inline::Ruby, Inline::Lua, and so on.)

[0] https://raku.land/

[1] https://raku.land/?q=inline

[2] https://github.com/perl-foundation-outreach/gsoc-2021-ideas/...

Somewhere I have posted code that uses Inline::Perl, Inline::Python, Inline::Ruby, and I think maybe Inline::Go to convert Base64. (Perhaps other language interfaces as well, I don't quite remember)

While there were some quirks, It worked rather well.

Aren't there plenty of languages that fit that description? Java, C#, TypeScript, Kotlin, Swift, et all ?

>Not some junkies slapping half-baked libs together.

This is offensive. Whether the people who work hard to make and share (for free) half baked libraries are addicted to drugs is really not part of the main thrust of your argument. You could leave it out, save words, and not have distracting comments from people like me while still making your point.

Are you seriously taking this literally? I didn’t even think this deep when writing it. Honestly! Lighten up.

No one in their right mind thinks about people building free libraries on GitHub as nothing but positive thing. Come on. I am offended that you’re offended by this.

Usually, I would apologize for saying something offensive, but I guess someone will get offended on the internet. If I said “Wild Wild West” then may be some Texan would be offended by it.

Intention matters. Smile more and be tolerant, no offense :-)

> No one in their right mind thinks about people building free libraries on GitHub as nothing but positive thing.

If you feel love, share love. xx

Amen.

It's bringing love, don't let it get away! Break it's legs!

It’s 2021. The Earth is heating up, we have a cult member who believes in baby eating pedophiles in the USA government, and people are still dying from their inability to afford insulin. It’s not that name calling will be taken seriously by everyone, but thoughts like that are distractions we can no longer afford to think about. Put your energy towards ensuring there’s a future worth worrying about.

If they just don't eat, they won't need insulin anymore!

Parents words were meant to convey a certain disgust/impact.

Leaving them out would communicate the core idea, but not the emotional tone they wanted it to have.

(And it's obviously not about literal junkies, it's meant as "random people who don't know what they're doing").

I honestly can't tell if it's sarcasm or not. If I was reading it on some comp.* newsgroup I'd say the former, but it's 2021 so I consider the possibility you might be serious - but I hope not.

I read that as programming language (re)design junkies, not pharmaceutical junkies.

I'm fairly certain, given context, he didn't mean drug users. He was using it as definition two here:

https://en.wiktionary.org/wiki/junkie

What about Microsoft's Blazor - compiling C# down to wasm:

https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

> There is so much calm and peace that comes with std libs.

This, and library documentation. It's probably the single practica issue I have with D and Nim. They seem to have fairly robust standard libs but when I look for something specific it always turns out this feature is missing, outdated, or badly documented.

Libraries in Python are hell. And Stackexchange can be almost pedantically useless in those things. For example let's take OpenCV bindings for Python. 3 separate libraries provide it, which all are called in as

   import cv2

Yes, Stack Exchange, I know OpenCV can do this for me, but integrating that into my package dependencies is time down the drain which I am never getting back.

Two pieces of advice:

- Just learn the language with all of its quirks

- If you are new, ignore the quirks until you are ready

Creating a new language sounds ideal, but there are a whole slew of caveats. Python tends to be recommended as a beginner language since it is reasonably easy to learn and offers considerable room for growth By the time the Next Python reached that stage, we would have accumulated a new two decades of techniques and features that would leave Next Python in a similar position to Python today. That assumes that people would even agree upon which language would serve as Next Python as a standard recommendation. One of the advantages of having so many people agreeing upon Python as a starting point is it eliminates the first hurdle novices most novices face: figuring out where to start.

As for the batteries being included, it is also a strength of Python. Choosing libraries can be difficult. That's true for the novice and it's true for anything but trivial projects. Lean standard libraries encourage fragmentation. We should have learned that from the shortcomings of C, yet many languages have followed in the same footsteps with similar results. We should have learned that large standard libraries can be useful, from the success of languages like Java and Python. Package managers don't change the degree of fragmentation, they only make it easier to deal with.

> Creating a new language sounds ideal

I seriously cannot think of anything I could do to exceed Python.

Does it do everything? No. But name a tool with significantly greater overall reach. Some compete, but seriously. . .

Better main method calling, better chaining, multiple constructors, and better reflection.

Agreed. I’ve always felt that the following sums up why Python is my preferred language:

Python is the second-best language for everything.

With the big, big, notable exception: targeting the browser.

To be perfectly fair, unless you count WASM or other compiles-to-JS-but-not-quite-native langs (which, outside TS, are pretty niche), this is the case with literally every language except JS.

> unless you count WASM or other compiles-to-JS-but-not-quite-native langs

As a happy user of clojurescript, or seeing the popularity and adoption rate of typescript, I do not count them out.

JavaScript and it’s variants are 1st place for the browser (shoe in on a technicality) ... but like 213th for everything else.

Not counting them out either, but outside TS, they're still quite marginal, at best.

Possibly not for long: https://www.brython.info/

Brython has been around since 2014.

Python is great if you’re writing code to run on your own computer(s). But it’s terrible for packaging into executables to give to others (compared to Go), for embedding in applications (compared to Lua) and for running in the browser (compared to JS).

There’s no reason a new scripting language couldn’t excel in all three of those areas. But AFAIK none currently come close.

Pyinstaller seems to work pretty damn well for packaging standalone binaries. Or at least it does on macOS, I haven't tried it on other platforms.

I have tried PyInstaller some, on Windows, for both CLI and GUI (wxPython) apps, and what I tried worked fine, including single-file EXEs.

I'm using PyInstaller on Win10. It works well, although the single-file binaries get slower as I add more libraries because it starts by extracting that single file out into a temporary directory and then running it.

It's a personal project so I like to experiment, but it's also a CLI program that accepts command line arguments, runs, and then exits, so a 3-5 second delay _each_time_ it runs is pretty painful.

Luckily for me there's a 'single directory' option, which puts everything (uncompressed) into a folder. Snappy start because there's no decompression step, and while I like the idea of a single file .exe it turns out I don't really need that (I'm not copying the program from computer to computer).

So - thumbs up for PyInstaller!

Pyinstaller is nice for packaging projects with smaller libraries. Hello world is about 7MB.

Try including pandas with a few other popular libraries.

Suddenly you have 500MB blobs. Not very practical for passing around multiple projects.

I suppose that is not worse than Electron apps...

I know you are being factious, but it is much worse than Electron apps. One advantage of JavaScript's focus on smaller libraries and aggressive tree shaking at build time is that it is pretty good at only shipping code that is actually called.

In the python world you have to do all the work by hand. I've literally spend time copying and pasting code out of libraries and into my code just so that my build wouldn't balloon by 100MB because I wanted to call a 100 line function.

Is Python actually so poor though?

This is an extremely unscientific comparison, because I don't feel like creating custom binaries specifically to test with. But I happen to have a copy of youtube-dl on my hard drive, and it's 1.8 MB. I'm not sure whether youtube-dl creates their binaries with PyInstaller, but youtube-dl is written in Python, and the binary is a single file that can be run without a Python installation.

I also have a copy of docker-compose, which I know for a fact is created with Pyinstaller. That one clocks in at a significantly worse 10.8 MB (so perhaps Pyinstaller is the culprit and youtube-dl is doing something unique), but that's still relatively small for a considerably complex program.

Lastly, I have a binary called "toggle-switchmate3", which I created myself some years ago. I have a set of Switchmate light switches set up in my apartment, and the best way I could find to control them from a Mac was via this Node package: https://www.npmjs.com/package/node-switchmate3. NPM's dependency mess freaks me out, so I set everything up in a virtual machine, and then created a binary with "pkg", the Node equivalent of pyinstaller.

"Toggle-switchmate3" is 36.1 MB. And it's not a standalone binary—it requires a separate "binding.node" file to be in the same directory.

Is Python actually so poor though?

Perhaps not in the general case, but in many cases it absolutely is. The problem isn't python itself but libraries. While JavaScript tends towards dozens of small libraries that do only one thing, python tends towards one library that does everything. Which is really handy in most cases, but very painful when you want to package something that just uses one of those functions.

In a concrete case I had a small script that ran a particular edge detection algorithm on an image and returned the edges in geojson format. The whole script was less than 300 lines. But the built dist weighed in at several hundred MB as it pulled in the entirety of numpy, scipy, scikit-image, fiona, shapely and rasterio, despite needing only maybe a couple of percent of the functionality of each library.

And small things. Like your function wants to know if a parameter was not used when calling it. The ideom if par=None breaks if called with arrays. Ending scripts with a command early would also be great (for interactive programming)

Also what is wrong in having a switch statement? (I`d like one with range cases 1<x<10..)

Accesing dicts with a struct syntax.

'Inline' C functions.

JIT, especially for loop acceleration.

I believe the idiom to check, if a parameter wasn’t set is to use an object() instance as default value.

  _notset = object()

  def foo(x=_notset):
      if x is _notset:
          print("foo was called as foo()")

Thats nice. Thanks. Where did you find it.

I think it is from somewhere in standard library.

I don't understand what you mean by arrays.

    if par is None: ...

As for accessing dicts with a struct syntax, I prefer keeping dicts and objects different things (unlike Javascript).

And for JIT, there's numba!

Agreed on the switch statement...

Quick note, the more pythonic way of checking par in this case would be just to:

  if par:
    do_stuff()

Python does some really cool, if slightly unintuitive, checks for "truthiness" where 0, [], {}, false, '' and None (could be other cases too, brain's a little foggy today) all evaluate as false. This controls for:

  if par = None:
    do_stuff()

not catching empty lists, empty dicts, etc.

How do you define the function in that case?

So, a more complete example might help:

  def myFunc(par=None):
    if par:
      # do whatever is needed when the parameter exists
    pass
    #finish processing

This allows you to pass in [], {}, None, '', or omit par all together, which will all behave as if par=None, or pass in data and use it appropriately. You can also use

  if not par:
    pass

if you want to do the inverse.

>> for embedding in applications

I did this before and found it really easy to integrate. The provided C API surface is really easy to integrate with. It was literally just a case of detailing my types, calling the Py runtime and then querying the results/side effects.

Having never done something like that before, i was full of trepidation - i was amazed at how easy it was.

Packing Python into single packages has been a thing since 2002.

There are a lot of things python could do to be much better. Two examples, 1) dependency management in python is a train wreck compared to most modern languages. 2) the way package paths are done for imports is far more confusing than it should be.

JavaScript has greater reach. ES6 in a modern browser with native modules, and if you avoid classes and this, focus on object literals and pure functions, and pick a decent utility library, its a very good environment with max reach.

I'm not sure what you mean by reach? But Clojure given one definition has more reach. It can make use of Python libraries, Java libraries, C# libraries, JavaScript libraries, Erlang libraries, C libraries, and can run on desktop, mobile and browser.

> I seriously cannot think of anything I could do to exceed Python.

Just off the top of my head:

- Pattern matching

- Multi-line lambdas

- Proper variable capture in lambdas and inner functions (as was fixed with the 'let' keyword vs 'var' in recent versions of JavaScript)

- Support for cyclic imports (a bad pattern in general but necessary in some cases)

- A well-defined C API for extensions that doesn't get them too entangled in the internals of CPython. This would make it possible for other implementations to reach the level of library support that CPython enjoys.

I would say proper variable scoping in general. It would be awesome to have let variables in python!

Variables are scoped just fine from my point of view. What do you mean by proper?

I meant to say block scoped. Variables in python have function or global scope but no global scope. E.g. you can say

   for x in ...:

and then use x outside of the loop.

I have no idea why you would want to declare an x in the loop, and then use it outside the loop. There are better ways of doing things.

The fact that you can do such a thing in JavaScript is exactly why JavaScript is such a mess of a language with its globally-declared and hoisted variables.

That sort of practice has never made sense, and is not a language design that Python should follow.

Pattern matching is in PEP 635, created Sep 12, 2020.

Multi-line lambdas can be sort of obtained in Python by defining a progn function:

https://news.ycombinator.com/item?id=19933223

> ignore the quirks until you are ready

If you are new, chances are do not yet know what is a quirk and what is idiomatic.

It can be challenging and frustrating trying to follow guides or tutorials and they are all doing things differently - which is the "right" way? You have no idea as a beginner.

>Python's "batteries included" approach of a large standard library was a great asset in the days before package managers but these days I think it would be better to start with a much leaner stdlib and add things in more stringently.

I think that package managers or not, the "batteries included" approach is great, because it leads to most of the code for useful things already available, and also helps third party packages be smaller (since they can depend on things available in the standard lib).

Imagine 3 different packages, for example, each bringing its own different json parser depedency -- as opposed to all leveraging the included json package.

That's how you get no community standards but tons of packages for the same basic things in slightly different ways, each with 20%-30% adoption.

That's also how you get 1GB node_modules folders.

That's also how you have the "leftpad" situation.

I've been thinking for a while that it's about time a new (maybe jit compiled?) language hits the scene with:

- A simplified/sounder natively integrated version of Typescript's type system - Javascript's easy notation for manipulating objects - None of Javascript's other baggage/cruft - Something akin to go routines

Basically, something with the performance of Go/Java (so there would be no need to rewrite your code once it starts serving millions of people) but the elegance of Typescript.

Not sure if this is similar to your vision of a "next Python" but it feels somewhat similar.

Basically I think right now:

C -> Zig

C++ -> Rust

Java -?-> Go

Python/Javascript --> ???

With native typing we could get a language as fast as Java/Go but with the cleanliness of Typescript.

I remember a few years back when Nim was going to be the next big thing here, but unfortunately it never gained that level of traction. Still an interesting language even without bigco levels of support behind it.

Scala comes very close to that.

the JVM is an incredibly heavyweight runtime compared to CPython. I don't think we're going to find the next beginner-friendly language coming out of the most professional runtime in human history.

> incredibly heavyweight runtime

The apps may be heavyweight, but the runtime was designed to run on set-top boxes 25 years ago.

The JVM is definitely memory hungry (excluding cherry-picked examples such as 'set top deployments' or the Java Ring from the 90s), moreso than any other language runtime referenced in this discussion.

True, but I don't think that is what the OP was taking about. The language itself is rather independent of the runtime. Scala compiles to native code or Javascript as well.

Scala is nowhere near as approachable as Python or Typescript

Why do you think that?

At least when I used it ~2 years ago: an extremely complex type system with a huge learning curve (unless you're going to just write Java in Scala), poor documentation, and a very slow compiler. That's to say nothing of the JVM-based runtime.

I got really frustrated one of these days because I reached the 20-something limit for fields in a case class and I had to change a lot of my architecture. It was a Spark job so I needed all those fields in that structure.

Not sure if that's because I'm a beginner or if it's just Spark itself, but Scala errors are impossible to decrypt.

Ah yeah, that was really a stupid limit.

Time to bump Scala to version 3 so that you don't have the 22 case class field limit anymore. :)

See here: https://dotty.epfl.ch/docs/reference/dropped-features/limit2...

> unless you're going to just write Java in Scala

That is what I mean though - but I would replace "Java" with python here. Just stay away from all the complexity and write python code. It's pretty simple and some people argue it's the better way to use Scala.

Scala’s implicits, mutable/immutable collection bifurcation, infix/dot syntax interchangeability for method invocations, tendency of libraries to implement their own mini language, ...

As a beginner, you don't really have to use Scala's implicits or "infix/dot syntax".

Just like how you don't have to use type annotations, generators, decorators, context managers in python.

Same for libraries.

At some point you will stumble upon a library that forces you to understand them or you even write one yourself, but that is not something that stops you in the beginning.

It does.

Go got this right. If you want to read code, contribute to a large code base, folks will be using the features of the language, including the weird ones. Go has kept things very simple (relatively) in terms of core language. Some things were beyond basic (error handling? no generics?) But boy did it make it easier for contribute and understand code.

def Hi() = "hi" Hi() Hi

Yes, those two variants both work?

> If you want to read code, contribute to a large code base

Sure, but in that case, is python really beginner friendly? I don't think so. I had the impression we were talking about starting out with the language and building the well-known todo-list to learn the basics.

Also, golang is a rather young language and it will go the way that all languages go: it will get more and more complex because the more experienced developers want to improve their productivity with better language features. Remember the "no generics" thing? Well, now the generics will be added - I predicted this to happen. And just wait, other features will follow...

It was originally. But agreed, less so now.

They've been adding some really more edge / line noise type features. Consider the walrus operator? You can do pretzel magic with this which make figuring out scope and what happened to what difficult.

I love the old way.

with open(…) as f: for line in ...

And I wish they'd just made more things iterable maybe or fixed some of the regex match stuff?

Typescript is not clean because it has to accommodate every crazy thing people do in raw JavaScript.

Having said that, isn’t Deno close to what you’re looking for?

I actually really like TS's type system precisely because it is insanely flexible.

I can write statically typed code that easily shapes & reshapes objects & code that fits functional or object oriented programming styles.

It's a statically typed language that feels dynamic.

Now, if I were to get a version of TS without all of JS's crutches that would be amazing.

Deno is pretty close, but it lacks on performance & is bounded in potential by JS (in some aspects).

I live in hope that, one day, TS will loosen its links to JS.

Things like `Object.keys` irritate me because they don’t compose well. What would go wrong if TS started supporting `Object.prototype.keys`? Could even be implemented as a rewrite using `Object.keys`.

I’ve been thinking about this, and I never thought of it before. I would love a language that is both dynamic and static similar to JS and TS. but, when the types are provided, use them to compile to fast code, while keeping the ability to do dynamic scripting.

What’s your opinion on Julia?

Swift would be a candidate and is a great, progressively disclosed language, simple enough for beginners but scales up in advanced features. It’s attachment to Apple puts a lot of developers off but there is a lot of work going into windows and linux support as well as WASM. One issue is compile times right now.

> C -> Zig

If dealing with uses after free and lack of bounds checked access in release code is still a fun factor.

> Java -?-> Go

Not at all, unless one misses Java 1.4 with loots of if/else boilerplate.

- But huh, if you checked that at runtime compiling un debug mode, and then you compile you compile the exact same code... It should be OK right ?

- I think you're right. C is more l'île a garbage collected C.

Big if, specially if you haven't tested all use cases.

It is the same fallacy as C code is safe if everything was checked, while CVEs keep happening.

What do you think of Dart? It's still evolving, but for me it ticks all those boxes.

I’m overwhelmingly favourable towards Dart. While I picked it up for mobile (Flutter) dev, I’ve been slowly replacing a lot of scripting/backend work with it too.

It’s the ideal replacement for general purpose scripting and browser work IMO. I can’t recommend it enough.

Python honestly did not learn from many things that were already well known when it was designed.

It wasn't arcane at the time that using exceptions for decision logic, or letting loops run by assignment, rather than by creating a new scope, were not the most salient ideas.

The following Python code contains a bug:

  list_of_adders = []
  for x in iterator:
   list_of_adders.append(lambda y: y+x)

Namely, since `x` is assigned with each iteration of the loop, rather than that a new scope is created, the `x` that the closure encloses is re-assigned with it, so all anonymous functions contain the value that `x` had in the last loop, which is almost certainly not what the programmer intended.

In fact, if within the same scope, which is quite large, since Python does not like block scope, x ever be re-assigned, which is quite likely, as Python uses the same syntax for initialization and assignment, then all the closures collected in the list shall thenceon refer to the new value that x is assigned to.

These are not design choices that many other programming languages at the time made; they were bad with the knowledge of the time, and continue to be bad now. There is no justification to have loops be implemented by assignment, and not create a new scope.

The justification for function-scope instead of block-scope is that only the former really works if you have implicit variable declarations.

In turn, implicit variable declarations (using the same syntax for initialisation and assignment) are a reasonable choice for a language that aimed to be “executable pseudocode” and that supports mixing initialisation and assignment in a single statement (e.g. `a, b, self.c = foo()`).

It could easily be written as `var a, var b, self.c = foo()`.

Having the same syntax for initialization and assignment is quite quæstionable.

That’s not a bad suggestion, but it’s quite verbose (it would require declaring multiple variables as `var x, var y, var z` instead of `var x, y, z`).

That could easily be `var (x, y, z) =`, which is similar to what many languages use.

I'm always surprised when something throws in my face how many details we have to keep in memory to make implicit mutability work.

It's amazing that people can program in imperative languages at all, yet it feels easy. I wonder how much trouble this causes for somebody learning how to program in a modern high level language.

New languages need to have a distinct benefit in order to be enough encouraging for new people to learn it over picking something which is already well established. In python case it was something that replaced shell language for data administrators, and many of the quite complex languages used by data scientists.

The one big selling point a future language could have would be inherent parallelization that uses all the 32+ cores of the developers machine, but that are as beginner-friendly as python. Such language does not exist. A dynamic, easy to use, and built from the ground up to always utilize all cores all the time without demanding that the programmer are handling side effects.

Such a language _can not_ exist, because it stops fulfilling the "beginner-friendly" criteria. As soon as you deal with concurrency, things either get hard to learn or get super messy.

Maybe golang comes closest to that (and concurrency is messy in there), but I'm not sure if it fulfills the "beginner-friendly" criteria from the perspective of a python developer.

Go minus concurrency actually is a good candidate for a solid beginner language. It has quirks, but no more so than any other choice, and fewer than most, for a beginner.

However, in my experience, keeping beginners away from concurrency is difficult. A lot of Go tutorials make a hard burn for it, since it's the big feature if you're already a programmer. And I've gotten (internet) yelled at for trying to suggest that concurrency is something beginners should leave until much later.

The other problem is a lot of what beginners may want to pivot into after they are done writing their "is the number higher or lower?" first terminal app isn't great for them. It's not a great game/graphical language. GUIs mostly suck. Web is awfully hard to get into nowadays, even if you try to help them narrow their focus.

> As soon as you deal with concurrency, things either get hard to learn or get super messy.

Strong disagree. There is a language where concurrency is trivial and beginner-friendly. It is called POSIX shell with standard GNU tools. To run several independent commands in parallel, you print them and pipe to GNU parallel. If your concurrency has an arbitrary tree of dependencies, you print it in the form

    target : dependencies ; command

and then run GNU make.

Languages that make this simple stuff complicated, like Python, do so by choice, not by need.

There is a reason why no one uses shell for anything more complicated.

E.g. start two long-running commands and then close the one of them depending on some later output of the other one or vice versa.

If that's not already complicated enough, we can easily add things like, execute a command A and then another other commands (B, C, D) and, only once all these are finished, run a cleanup command D. But run D always, no matter wether B, C, D fail (think of closing a database connection). And now treat this whole thing as yet another command E, that itself can be used in the same place as e.g. B or C or D before (= composition).

Shell is great for many common tasks, but I would never call it beginner-friendly, even less "trivial to use for concurrency".

> Shell is great for many common tasks, but I would never call it beginner-friendly, even less "trivial to use for concurrency".

Yet somehow beginners in my lab cannot get their hands off the shell and we have to politely guide them to other languages... But still, I insist that parallelism in the shell is very easy. How do you do that in Python, for example?

    # convert images from jpg to png, in parallel
    for i in *.jpg; do
            echo convert $i ${i/jpg/png}
    done | parallel

Regarding your "complicated" use cases, I must confess that I don't understand them nor their relevance. But for simple people like me without fancy needs, the simple concurrency offered by GNU parallel and GNU make is good enough.

Haha, please don't get me wrong! I didn't mean to say that concurrency in python is any easier - it's probably even harder than in shell.

> Regarding your "complicated" use cases, I must confess that I don't understand them nor their relevance.

They are two recent examples of mine. But even if you don't see the relevance in them: if shell truly makes concurrency trivial, then the shell code should not look much more difficult then my English descriptions.

Parallel independent batch jobs are easy in Python though. If you can write it as map(function, iterable) you just need to import the right module and drop it in and you’re done.

I think the reason no one uses shell for anything more complicated is related to the fact that:

1. It's not generally taught in CS classes, and people just search up enough syntax to be able to acomplish their task.

2. A lot of it's variable expansion/substitution are remiscient of Perl.

3. Small mistakes can have huge impact (everyone knows how often rm -rf of unintended directories takes place). Just for the fun of it, I suggest everybody reads at least once the Unix Haters Handbook https://web.mit.edu/~simsong/www/ugh.pdf

If I understood your task correctly, it can be done just nicely in the shell (after all, this is what I think the shell excels at). You'll see the unpleasant side of it when dealing with function arguments and slicing values and referecing specific ones. I don't guarantee it does what you want to the letter, but just my quick interpetration of your description.

    function demo() {
      first=$1
      last="${!#}"

      $first &
      wait

      for f in "${@:2:$#-2}"; do
        $f &
      done
      wait

      $last
    }

    function first() {
      sleep 5
    }

    function pingy() {
      ping -c 8 google.com
    }

    function last() {
      echo -----------------------------
      echo done
    }

    function inception() {
      demo first pingy pingy
    }

    demo first pingy pingy inception last

> As soon as you deal with concurrency, things either get hard to learn or get super messy.

I'd argue that Clojure, while perhaps not the easiest language for beginners in all aspects, is both minimalistic and really fantastic for doing clean and safe concurrency.

The program should leave one core for the OS.

> replaced shell

I'd argue it replaced Perl.

Are you saying it was a replacement for a two year old language?

Perl - December 1987

Python - December 1989

Yes. You need to remember than neither language was relevant yet; I'd draw that line around Perl 5 and Python 2. Don't forget that Perl 6 spent two decades in development hell.

Not that the TIOBE index is perfect, but you can see what happened since 2001. Perl used to be a lot more popular for early dynamic websites and systems glue, but by 2011, Python had gotten a lot more popular in those roles.

https://www.tiobe.com/tiobe-index/

Zope was winning over mod_perl back on those days.

Chapel and Julia.

dask in my opinion comes decently close to better parallel computation in Python, and being beginner friendly. It is immensely compatible with numpy and pandas, and can abstract away a lot of the parallel computation complexities which makes getting up to speed easier.

However, their scheduler really needs speed ups, and they do run into weird data handling bottlenecks in my experience.

Using a lot of execution resources is not a direct benefit from the user POV.

Making programs execute faster could be. And there using many cores is one implementation strategy among many complementary ones. But the current landscape of programming languages shows that languages focusing on execution speed and parallelism have smaller user bases.

Also, re this data interpretation of Python's killer app, this usage of Python is something fairly recent and happened after Python had already broken into mainstream usage in the industry. A lot of small and big applications have been built using it before the data and ML things got in vogue (like Youtube, Dropbox, Spotify etc at the bigger end).

I spent a few decades chasing "the next great language", and I regret it. I wish I had spent those hours learning about statistics or cryptography or algorightms. Things that are timeless. If you want to be a jack of all trades, master of none, by all means, chase the next great thing.

I for one, think it's more likely that Python will evolve. The mathematicians and physicists, biologists, astronomers etc. that have finally gotten rid of C++/Fortran and learnt Python aren't going to change to anything with forced static typing any time soon...

Not a mathematician/physicist/etc, but having literally dived into Julia today, I think you’d be surprised. It definitely seems like “Python 2.0” for numerical computing.

Julia is probably excellent. How large are the benefits to using Julia compared to Python? Are the benefits great enough to compensate for the time spent:

- Training your entire team to use Julia instead of learning about other relevant things

- Re-writing your Python-infrastructure (or dealing with Julia to Python-interoperability, which means new employees now have to learn or know both Python and Julia)

- Replacing Jupyter and learning new, similar tools

- All employees making their favorite IDEs function well with Julia

- Figuring out how to make Julia talk to software that already has an existing Python API (Wireshark, AutoCAD, GNU Radio, ... just about everything you can think of)

Those are definitely problems for the corporate world (except for Jupyter, a Julia kernel already exists for that).

Again, I’m not an academic so take what I say with a grain of salt - but I can see Julia paying dividends very very quickly in that sphere (once you’re over the admittedly steep learning curve).

A few of these are non-problems IMO.

- Julia is relatively easy to learn for Python people (especially the numerical people who have experience with stuff like Cython)

- The interop (both ways) is pretty great with Python

The Ju of Jupyter is for Julia.

I think Python's batteries included approach still matters a lot, because many users (myself included) have to work from locked up workstations, with awful tech support, no local administrator privileges, and draconian policies forbidding installation of not previously vetted software. For example, not long ago a colleague requested a Orange (data mining software) install. Corporate IT took more than six months to validate it and fullfill the request. To avoid hassle like that, the most you can get from just the initial install, the better.

Keep the python brand and fix these things in a new backwards incompatible python release. Call it Python 4.

I’m sure it’ll only take a couple of years for everyone to migrate

Python 3 ?

I feel like Python just went through that big shift. Doubt we need a other one of those.

Also, I'd just look at Julia for some of what you're describing. It's basically going for a more focused approach with the learnings of Python in place.

Please no, the migration from python 2 to 3 was a disaster and we’re finally on the other side of it.

> I think the time is ideal for the "next Python".

We could call it Python 6.

I agree with you that Python now features some redundancy. Yet I do not agree with you that there is 'complexity', going by your examples.

Notwithstanding the various ways of doing the same thing (which sometimes goes against the zen of Python), as of Python 3.6 there's been a constant trend towards f-strings above all else (barring maintenance and legacy code), and generally beginners have no need for anything beyond f-strings. If they'd like to go into the old string formatting techniques, they're welcome to, but they're not that complex.

I don't understand how type annotations constitute a 'compromised design' - they've worked quite elegantly with Python's dynamic typing, they greatly assist linters and IDEs when you turn them off, and they can be disregarded when you don't need them, which is a far cry from the enforced typing of other languages.

And I certainly do not agree that there is a need for a "next Python". Python does a lot of things very well - it's design is clear, the design patterns are methodical, the language is well-governed, the central packaging system is reliable (and not like the insane NPM and dependencies of JavaScript), there is a distinct idiom/style consistency amongst Pythonistas, a and a large gathering of minds behind the language. Further, Python reads very well, and can be even pseudocode without being pseudocode, which makes it very much suited for beginners who can stray as far as they want to into the language when they feel ready for it.

Python is a great language for beginners, so I have no idea what you're talking about.

> ... And many of the new features such as type annotations have a compromised design due to their being added to Python late in the game. ...

But they tend to get ironed out over time. Python 3.9 adds parametrized generic type hints based directly on container types, alleviating the need for a parallel type-hint type system. i.e. `dict[str, list[int]]` over `typing.Dict[str,...]`

That’s exactly the feature that’s causing the problem in this article.

I'd love a Python 4, or one by any other name, to be like the latest Python, but cleaned up, with no regards for backwards compatibility. For example: a trimmed standard library, and much of the alternate syntaxes removed. Better tooling and official-docs support; ie like Rust: A modern, official package manager, a built-in linter, formatter, binary-creator etc.

I have a hunch that in five years, the global-state package manager built into python will be a feature because we will all be working exclusively in dev-containers.

What does it matter to you if there are features in the standard library you don't use? The full python embedded distribution is only 8MB including runtime.

I hope your hunch is wrong! I feel like containers are a symptom of situations like this Python one.

Hehe, Python 4 will probably not happen after 2->3.

I don't think any single language will be the "next Python" for everybody.

Many seem to be happy replacing Python with Go, to get better performance, parallelism and packaging support. However, for my uses I'd much rather replace it with another high-level scripting language, even if it's still slow and single-threaded.

This is what I’ve done and it’s way easier from a packaging perspective but the thing that stings is Go misses out on all the data science stuff like pandas, numpy etc

In terms of style, Swift feels like the next Python. And it’s starting to pick up a sizable standard library.

Yeah, every time I’m playing with typing and mypy I start yearning for Swift’s type system instead.

f-strings are amazing

Can we make that the standard and get rid of the ugly str.format(UGLINESS) syntax.

Yes please, and thank you

`str.format` can’t be removed completely - it’s necessary if you want to build format strings at runtime.

But otherwise, yes - make f-strings the “one obvious way to do it” and use `format` only when necessary. And get rid of the old %-formatting.

Also consider making f-strings the default: https://pyfound.blogspot.com/2020/04/all-strings-become-f-st...

> Can we make that the standard and get rid of the ugly str.format(UGLINESS) syntax.

`format` is still useful, particularly when working with pre-templatized strings. It's also a (relatively) new feature; Python 2 didn't have it at all.

OTOH, I wouldn't cry if Python 3.X finally removed %-formatting. `format` does everything that `%` does, with a much nicer API (especially in 3.7+).

Jokes on you, my coworker still obsessively uses % args syntax.

I can understand that, to a point. Not the so much the obsessive part, but I sometimes fall back to % formatting too since that uses the formatting syntax I'm familiar with from C and C++. The syntax used in f-strings and .format is probably better, but requires re-learning.

Please tell me you correct them in the code reviews?

Everytime someone uses %args inappropriately a baby seal dies.

f-strings are standard, what do you mean? That the "f" be ommitted? I'm all for it, yet it would need a bit of adaptation for those old programs that put {} inside non-f strings.

I'm not a big fan of f-strings. I like to have a nice separation between the format and the values.

f-strings work well in simple cases. But once the things you want to output are somewhat larger expressions, format() works much better.

Example: instead of something like

    print(f'{id:<5}  |  {", ".join(members}:<50} |  {", ".join(str(score) for score in scores):<30}')

This is much clearer IMO:

    print('{:<5}  |  {:<50} |  {:<30}'.format(
        id,
        ", ".join(members),
        ", ".join(str(score) for score in scores),
        ))

Actually, what do you mean by "ugly" and "UGLINESS" in "the ugly str.format(UGLINESS) syntax"? The UGLINESS are simply the things you want to format. Ugly is in the of the beholder of course; personally I don't really see anything ugly about format. The f-string equivalent here is much uglier and much less clear/readable to me, because the formatting and the expressions are mixed and parsing the whole thing to see what is what is more effort than it should be.

Both examples look unreadable to me. Just because you can do a lot on a single line doesn't mean you should.

    all_members = ", ".join(members)
    all_scores = ", ".join(map(str, scores))
    print(f'{id:<5} {all_members:<50} {all_scores:<30}')

> Can we make that the standard and get rid of the ugly str.format(UGLINESS) syntax.

No, please.

F-strings are useful for some things, but there's a good reason. to define templates other than deep in code for ease of editing them distinct from functionality (often, completely externally to code) and using str.format supports that.

If anything, I'd prefer r-strinfs as the default with both escape handling and formatting non-default options, but the status quo is acceptable and better than r-strings as the base.

What's wrong with having a robust stdlib? Are those extra 50 megabytes really a problem?

The issue is not the size of the stdlib but rather the process for how things get in there. IMHO Python's stdlib has a number of modules of sub-standard quality and design. It would be good to have a gradual process for inclusion in the stdlib, so that different 3rd party libraries could be vetted by the community before we bake one into the language.

I agree Python has some frustrating imperfections, but it has a pretty great ecosystem, and a new language would presumably have to start over.

I wish Python went with static typing from the offset, and I wish it had better parallelism, but with Python you can get a library for just about anything with a simple pip install, and that's worth a great deal.

Need a WebSocket library? No problem. Need a cross-platform TUI library? No problem. Python's maturity means you can do a lot of things with little hassle. Some of the less mainstream programming languages are nowhere close to Python in this regard, even after many years.

Like a statically typed, compiled Python? With a more flexible approach to OO?

That can compile to binary, javascript and other languages?

That would be https://nim-lang.org/

Relatedly, I made a flake8 linter plugin for modern Python if you really feel like being constrained:

https://pypi.org/project/flake8-simplicity/

https://github.com/wryun/flake8-simplicity/blob/master/flake...

Golang looks like that language. it would be my go to, but why they decided to have Nil Pointers, I don't know. Golang without Nil and also mostly pass by value, and only using pass by reference for people doing lower level stuff, would've been good. for now, staying with python.

Golang is easy to get started with tooling and packaging is good. but then the code in the wild is littered with pointers for when you wouldn't need them.

>A new, general-purpose, beginner-friendly language focused on readability

Sounds great. What made Python so beginner-friendly and readable? Most of the "let's improve Python" gang I see can't begin to answer that - by their metrics, the language must be a failure.

Beginners have the advantage of not thinking "this is the best way to do it because that's how C/C++/Java do it".

F# is that language and is rapidly gaining steam.

> Python's "batteries included" approach of a large standard library was a great asset in the days before package managers but these days I think it would be better to start with a much leaner stdlib and add things in more stringently.

With all these memory safe languages getting popular NSA needs more npms, not less.

Could something be added to the linter, to flag language features that you don't want to use? This would allow creation of a beginner mode, where all but the most primitive features are left out. It would also be a potentially useful way for us to impose consistency on our codes as they grow in size.

So a Kotlin for Python?

Yes, but the other way around :)

Kotlin solved the syntax and language warts on top of a good runtime.

For python the syntax is (mostly) good but the runtime and package management needs a rehaul.

> mostly

Bolted-on classes and types annotations, and missing real lambdas isn't awesome, and lack of proper variable scoping is error-prone.

I agree that the runtime is a mess, but more in naming inconsistencies and how its organized than functionality.

Kotlin solved Google's Android problem, on the JVM it is just another radar noise in the set of guest languages.

Kotlin was developed by JetBrains, not Google, as a 'better Java'.

So what? #KotlinFirst is being pushed by Google.

Android is the only place where Kotlin actually matters.

Do you need to use all the features of a language all the time? I don't think you do.

A language with a consistent design can have layers, and beginners can just do with the external bits without getting too deep initially, but with enough space to grow.

IMHO Python is a good language on that regard.

Rinse and repeat. Three hundred years later, we're at the original python again. Invented on the USS Enterprise.

"To boldly create programming languages no man has created before."

Julia in many ways was designed as the next Python. Their user base is growing steadily, and they may displace Python in many applications a decade from now.

Learn Common Lisp and you'll find "the techniques & features learned in the past 2 decades" notion laughable. Or sad.

Why does nobody talk about drawbacks of common lisp?

Because in this thread it would be off topic?

Ruby 3.0 is a great time to get back into Ruby :)

Totally. What Rust is to C.

Reply on news.ycombinator.com