blindseer

I (mostly) like when programming languages allow you to express ideas with dedicated syntax. It (usually) is more clear and concise. Even if I don't use all the syntactic sugar in a language, I often find myself wanting to use a significant number of these features.

However, this brings me to my biggest gripe with the Python ecosystem. For better or for worse, Python is used EVERYWHERE. And, to make matters worse, standard tooling that manages dependencies and versions of Python is a complete mess.

Just in the last couple of months I've written Python packages for applications embed a Python 3.3 interpreter. And I still work with code that runs only in Python 2.6 (working with hardware). In these projects, I can't use these new "features" even if I wanted to.

The tenet of my comment is this:

I really wish there was a standard source to source transpiler that helped in converting Python 3.x code to Python (2|3).(y).

Almost all the features I'm envious of either have a way to be represented in older languages more verbosely (f-strings, :=) or don't need to be in the source on the user end (type hinting, dataclasses, keyword only arguments). I know there's not a one to one mapping here, but even a best effort would go a long way to helping adoption of these new features. I don't see the Python folks slowing down when adding new features to the language.

I really wish I could use these features today but I know I can't. I also hesitate sometimes when I'm making a package open source because I'm worried someone else might want to use my code in an older version of Python and won't be able to because I wanted some syntactic sugar (I've even received PRs on project to revert some changes), and I now actively choose not to use these features against my desires. Larry Hastings may have said farewell to Python 3.5 but lord knows when I will be able to do the same.

Is this just me? How many people use `:=` or `@dataclass` or `|` for dict merges in their code today?

Thank you Andrew for all the work you've done on this! I'm very excited about being able to download zig and get the latest LLVM version AND be able to cross compile in a single go.

`zig cc` in some ways is now a better C compiler than clang/gcc. To me that's even crazier than everything else that is happening in the world right now.

This is tangential but this channel frustrates me to no end. They shamelessly rip other people's content, stripping their videos of author information, conference information etc, AND add their own title card so that it appears like they are the publishers of the video. Why is this acceptable!

Anyway, here is the original source [1], that this time was NOT in their video description.

[1] https://www.youtube.com/watch?v=iGOAQli7tGc

And this is the last time I commented about this channel [2]

[2] https://news.ycombinator.com/item?id=20797683

This is not my original content, but I thought it was fascinating and well worth discussing on HN.

This is tangential, but I really dislike how this YouTube channel always downloads the original video, strips it of all information regarding the speaker and the conference and uploads it to their channel. Even though the original is published under Creative Commons Attribution, it still bothers me that they 1) download and reupload (wouldn't this be better accomplished by a playlist?) 2) strip information that makes it appear they produce the content. I'm curious what other people think about this.

Anyway, here is the source [1] from their video description.

[1] https://www.youtube.com/watch?v=y0vlD7r-kTc

I've used it. Julia's ccall is so nice to work with once you have wrapped it in other functions. The hardest part was creating, finding, downloading and using the right library with it's dependencies during Julia's build step for a package.

I think it'd be great to have a discussion about this. I think the best place might be a thread on Julia's discourse forum. If you want to start a conversation I'll chime in. I'm interested to see what you have going on as well.

Congrats to all the students and good luck to all of them.

But this is personally so disappointing to see no work on PackageCompiler.jl. I think PackageCompiler.jl + some sort of core support for interfaces and traits checked at compile time is what Julia sorely needs. Right now there's just SOOO much boiler plate and resorting to a third party package to solve these problems in the language is starting to get to me. Coupled with the fact that if I want someone to use my code I need to get them to install Julia, configure their environment and run things in a very specific way and I'm looking for another language to put my weight behind.

Anyone else want to share insights about writing large applications and deploying it to users in Julia?

There have been no major updates to Voice in a while (thankfully), but lots of marketing and buzz around Project Fi. I can't help but think that Google will kill Google Voice in the future. Google Voice is integrated with Hangouts as well, which means one of those features will go away, assuming the OP is true. I love using Voice for the same reasons you listed out, but I dread when Google decide to make a change in this space, I'll be very disappointed.

My biggest problem with this change (and dataclasses) is that it is not backward compatible (I know that a backport of dataclass is available, but it is only for Python 3.6). Can people tell me how they deal with this? Are you using features that are only available in the version of Python all your colleagues / users have access to? Are you using the latest version of Python and hoping your colleagues and users can upgrade to that version of Python?

One main reason in my opinion as to why Python 2.7 stuck around for so long was that everyone agreed that it was the last stable version of Python 2, and the devs could make Python 3 changes without worrying significantly about backward compatibility. I've been using Python3 since Python 3.3 but have had to write code that was Python 2 compatible for large code bases for about 5 years because I knew colleagues / users of my packages would not upgrade. This meant using a select subset of features in Python 3 that had been backported to a version of Python 2.7 that I knew I could get my colleagues / users to upgrade to. It has been great to watch the language evolve and Python 3 really gets a lot of things right, but adding breaking syntax features every minor release is extremely annoying. I have to have a mental checklist of all the different possible subsets of features I have access to given a minimum version of Python I want to support. I've spent the last couple of years in my professional career converting large Python 2 only code bases to Python 3.3+. But if someone wants to use async, I need to bump the minor version. If someone wants to use type hinting I have to bump the minor version. If someone wants to use f-strings I have to bump the minor version. If someone wants to use data classes I have to bump the minor version. It's nuts (to me anyway)!

This sounds rant-y but I genuinely want to know what other people are doing to mitigate this. I love Python! I have spent years advocating its merits. But thinking about large codebases in Python just worries me and the future doesn't look promising here. Are Python developers hoping that once 2020 arrives they'll have a stable Python release and work on Python 4. We'll have the Python 2/3 split all over again!

My personal opinion is that Python needs an officially maintained translator for the latest Python features back to older versions. My current favorite package is py-backwards [0] but it is rather unmaintained at the moment.

[0] - https://github.com/nvbn/py-backwards

Thanks for the reply ScottPJones. I've seen your name pop up in multiple Julia discussions and am eager to hear more from you. In another comment you've said that you've used this in two separate commerical applications. Can you share the use cases that your commerical applications tackle?

I do need to choose one, given the time and budget that I will have to work on this. I do understand that if there are things that I cannot do in Julia, I would be able to call out to a Rust shared library using FFI, but I don't expect my use case to need it. I'm likely going to have to build a library that can be called from Julia/Python/Java etc. The question is whether to build that library in Rust or Julia. Rust has more solid C ABI support at the moment. But I'm hoping PackageCompiler.jl and other niceties come along and make the Julia shared library interlop better too.

Thanks for the answer! I also would love to see more experiences presented about Julia in the wild. D and Nim are both on my list too and I will definitely consider them in a more objective comparison.

Rust does "feel" like a lot of overhead in order to avoid the GC. Can you comment on / know how I can check whether the GC in Julia is going to cause an issue for me?