Personally, I find it unfortunate that Guido picked “twisted like” over “gevent like” for asyncio (née tulip).
Having used twisted for a while, when I first started using gevent, I found it amazingly more usable (and better performing to boot).
I still do lots of python2 for work, but given a choice of language, there are luckily many other decent languages to use these days. I can’t think of a case where I would choose python3 (even over python2) for a new project.
It would of course depend on performance expectations, and other requirements.
That said, I would probably see how the requirements matched up with Go. If static typing ended up not being a hard requirement, and if Go wasn’t a good fit, I would probably look at Elixir….maybe python2 if the requirements fit better.
Swift and Rust are both interesting to me, but I haven’t really used them “in anger” for anything yet. I also hear some people have used D for web projects to good effect.
Try Opa. It’s designed for one, safe language doing the whole stack with DB functions built-in. If that doesn’t work, tell them why so they can improve it.
At first glance, this seems like the wrong direction web development should be going in. By conflating the server and client side, I think you add complexity to the problem.
Also, I think you should use javascript on the front end (since there are no alternatives), but on the back end I would recommend finding a language better suited for the job.
Why does this add complexity? Lots of webdev is incidental complexity brought on by mashing lots of different technologies together and letting the dev sort it all out.
“By conflating the server and client side, I think you add complexity to the problem.”
Why does it matter where it runs if you can ignore that and still build apps that work? Sounds like incidental complexity as mattgreenrocks points out. The first to try to eliminate this problem was MIT’s Curl which is still sold. It aimed to be more like markup languages.
That worked out fine for lots of their customers but needed a plugin. The Opa project uses a ML-like language to get the readability and safety of one. They make it agnostic to client or server to reduce mental burden on developers. They integrate database since people need that anyway. Target JavaScript on client side since it’s supported everywhere without a plugin. Originally targeted J2EE IIRC on the server-side but switched to Javascript to leverage Node.js ecosystem. I’m against Node.js and that Opa move but oh well. Otherwise, quite a rational product where they let people get more done, more safely, easier to maintain, and with compatibly with existing systems. Now I have to get feedback on what people think of their implementation of that concept to see what is working or not.
On INFOSEC side, Cornell’s people implemented Java extensions that let one specify information-flow policies to protect confidentiality and integrity of applications. Their JIF, SIF, and Swift tools let one do this for web applications where Swift automatically partitions the app between client JS and server Java in a way that maintains security policy + optimizes performance. They built Civitas system for secure voting using this toolkit. Fabric extends it for open, secure, distributed computing. Lot harder to pull off information-flow secure apps working in several, incompatible languages that have to integrate just right. They put the correctness (Opa) or security (SWIFT) in the tooling for just one instead.
My experience of asyncio is not like that, though: it doesn’t seem simple or clean at all, it feels like an overdesigned monstrosity that’s been bolted onto the language with too many moving parts and too many new concepts. That was my first impression and it’s remained the same as I’ve tried to understand it more deeply.
I’d have to agree. But I think that covers a lot of Python 3 in general: they’ve been adding a considerable amount of new libraries and language features that make understanding the runtime significantly more complicated, and that complication seems to hold the deeper you dive. They even seem to have repeatedly snatched defeat from the jaws of victory, not just with asyncio, as you point out, but with breaking backcompat on typing, and again on async hidden methods, and a couple other issues. It’s losing its niche as my simple C glue language.
“at first glance”, i.e., when you first see the new syntax entailed—though I guess that’s not the best time to make a definitive judgement on whether it’s a good solution to the problem.
See, there’s your problem. Always go with the hot new thing, never the new hot thing.
Personally, I find it unfortunate that Guido picked “twisted like” over “gevent like” for asyncio (née tulip).
Having used twisted for a while, when I first started using gevent, I found it amazingly more usable (and better performing to boot).
I still do lots of python2 for work, but given a choice of language, there are luckily many other decent languages to use these days. I can’t think of a case where I would choose python3 (even over python2) for a new project.
What is your preferred stack if you want static typing and you’re doing a CRUD app?
It would of course depend on performance expectations, and other requirements.
That said, I would probably see how the requirements matched up with Go. If static typing ended up not being a hard requirement, and if Go wasn’t a good fit, I would probably look at Elixir….maybe python2 if the requirements fit better.
Swift and Rust are both interesting to me, but I haven’t really used them “in anger” for anything yet. I also hear some people have used D for web projects to good effect.
Try Opa. It’s designed for one, safe language doing the whole stack with DB functions built-in. If that doesn’t work, tell them why so they can improve it.
http://opalang.org/
At first glance, this seems like the wrong direction web development should be going in. By conflating the server and client side, I think you add complexity to the problem.
Also, I think you should use javascript on the front end (since there are no alternatives), but on the back end I would recommend finding a language better suited for the job.
Why does this add complexity? Lots of webdev is incidental complexity brought on by mashing lots of different technologies together and letting the dev sort it all out.
“By conflating the server and client side, I think you add complexity to the problem.”
Why does it matter where it runs if you can ignore that and still build apps that work? Sounds like incidental complexity as mattgreenrocks points out. The first to try to eliminate this problem was MIT’s Curl which is still sold. It aimed to be more like markup languages.
https://groups.csail.mit.edu/cag/curl/wwwpaper.html
That worked out fine for lots of their customers but needed a plugin. The Opa project uses a ML-like language to get the readability and safety of one. They make it agnostic to client or server to reduce mental burden on developers. They integrate database since people need that anyway. Target JavaScript on client side since it’s supported everywhere without a plugin. Originally targeted J2EE IIRC on the server-side but switched to Javascript to leverage Node.js ecosystem. I’m against Node.js and that Opa move but oh well. Otherwise, quite a rational product where they let people get more done, more safely, easier to maintain, and with compatibly with existing systems. Now I have to get feedback on what people think of their implementation of that concept to see what is working or not.
On INFOSEC side, Cornell’s people implemented Java extensions that let one specify information-flow policies to protect confidentiality and integrity of applications. Their JIF, SIF, and Swift tools let one do this for web applications where Swift automatically partitions the app between client JS and server Java in a way that maintains security policy + optimizes performance. They built Civitas system for secure voting using this toolkit. Fabric extends it for open, secure, distributed computing. Lot harder to pull off information-flow secure apps working in several, incompatible languages that have to integrate just right. They put the correctness (Opa) or security (SWIFT) in the tooling for just one instead.
https://www.cs.cornell.edu/jif/swift/
https://www.cs.cornell.edu/projects/fabric/
Not OP, but C# with asp.net’s mvc framework is quite pleasant, if slightly bloated. Linux support for asp.net is pretty solid now as well.
Python has a history of making things seem simpler and cleaner at first glance than they actually are.
My experience of
asynciois not like that, though: it doesn’t seem simple or clean at all, it feels like an overdesigned monstrosity that’s been bolted onto the language with too many moving parts and too many new concepts. That was my first impression and it’s remained the same as I’ve tried to understand it more deeply.I’d have to agree. But I think that covers a lot of Python 3 in general: they’ve been adding a considerable amount of new libraries and language features that make understanding the runtime significantly more complicated, and that complication seems to hold the deeper you dive. They even seem to have repeatedly snatched defeat from the jaws of victory, not just with
asyncio, as you point out, but with breaking backcompat on typing, and again on async hidden methods, and a couple other issues. It’s losing its niche as my simple C glue language.“at first glance”, i.e., when you first see the new syntax entailed—though I guess that’s not the best time to make a definitive judgement on whether it’s a good solution to the problem.