Whether it is a side project or a professional one, what programming language and/or framework (web, gui, &c) do you plan to use for your next project, and why?
Because for 95% of my projects, personal and professional, thats the tool to solve it. I don't have to reinvent anything, or worry about gaping security holes common to web applications - i just need to work on the problem domain.
I can focus on good modeling and good front-end UI/UX. And there is flexibility in delivering desktop/mobile applications quickly, using what i've already built in rails.
As a one man band, I can't think of a better instrument to play.
Oh how I love Rails, the framework and language (Ruby) of developer happiness. But now working in AI, it's a Python game. This is maybe embarrassing to admit but I prefer having the Python pipeline, TensorFlow, numpy, etc. living on its own box, exposing inference as an api, so I can keep developing in Rails and its supporting ecosystem (background processing, push notifications, etc.) as the main app handling everything else.
There are so many jobs out there in rails / ruby. I really want to learn it, but the tutorials I've seen teach you how to generate a blog engine. I want some real world examples and tutorials, where's the best place to start?
This is exactly how i feel about flask and prior to flask turbogears. Stick with what you know until it doesn't solve the problems in satisfactory way.
Not supposed to be a short term project, though. Currently working on extending inth-oauth with openid support. I'm only really able to work on the fringes of this idea, though, since:
* Rocket itself is currently on Hyper v0.10, while v0.11 became async. This means various libraries around it are adapting async while Rocket itself won't for some time. Thus, I'm working on the fringes getting them to async.
* Async itself is in flux, because generators should be entering nightly any day now. When that happens having async/await macros available will make a huge difference.
Generally though I do really see Rocket + Rust in general becoming a huge deal in webdev. I've used Rust for so many C++ equivalent roles because of its safety guarantees, and they make development so much faster when you aren't dealing with undefined behavior cropping up in the corners you have to dig through to find. Additionally, the larger a project gets, the more valuable static typing is. Rust even pushes you towards best practices further by pressuring static dispatch and lock-free sharing of data.
How does that stack fare for building REST/GraphQL APIs? I've been meaning to play with Rust, but I'm not sure if using it for a Web project will be worth the trouble.
It's incredibly productive, you get the benefits of microservices with the development and deployment style of monoliths thanks to umbrella apps and there's not a single performance based concern I can think of that it can't handle.
Plus it simplifies infrastructure significantly by removing the need for much outside of Postgres.
I would love to use Elixir and Phoenix for my next personal projects, but I would not use it at work.
Elixir and Phoenix developers are much more expensive and scarce than Rails ones.
I would only start to use Elixir and Phoenix in my company if we were fully staffed and the rest of developers agreed on putting some extra effort (mostly during their time) to learn the new system.
How are you planning to deploy it? Getting the benefits from Elixir/Phoenix seems to require much more old fashioned thinking: long-lived, mutable servers with direct interconnects, so none of that immutable infrastructure, or platform-as-service stuff.
Haskell, unless I have a good reason to use something else. An example of a good reason was a recent project which made heavy use of s-expressions, so I learned Racket to do that and it works reasonably well (required quite a lot of optimisation for a particular loop though!).
As for "frameworks", I find JSON over stdin/stdout to do almost everything I need (Haskell's aeson package is good for this; I might try learning lenses too next time). I also make extensive use of env vars to pass options/config into programs, since I find their semantics (key/value pairs, globally readable, inheritable by child processes, overridable for child processes) more friendy than commandline arguments. Their only downside is being mutable, but that's easy enough to avoid in one's own code.
I also use Nix to manage all building, dependencies, etc. since it's trivial to get code written in many languages to play nicely together (my current project uses Haskell, Bash, Racket, Python, ML and Isabelle). Nix's "Hydra" build server is nice enough for continuous integration, although it's admittedly tricky to set up (it doesn't have proper versions; you need to find a git revision which works :( ).
It's difficult, but worth it. Lenses are super cool. They also play well with Aeson. There's a package lens-aeson that has a bunch of useful stuff. You can actually operate directly on Text values and treat them as JSON structures.
...totally made all those up, but by the time I get around to it they'll all probably exist, right? Point being, it is both alarming and overwhelming to me the sheer number of available frameworks and languages that all attempt to solve the same things. Even when I dedicate myself to learning whatever the "latest thing" is, it's only a matter of months until I feel behind the curve.
I'll stick with C# on the back-end and React/ES6 on the front until something compellingly better comes along. The reasons NOT to use .NET on personal projects (especially the $ factor) are continually declining, and there's really nothing I've learned about that stack that doesn't readily translate to whatever other languages I've encountered thus far (Python, Ruby, Rust, Go, etc).
The only thing I feel like I'm missing out on at times are algebraic data-types, so I guess I'll give a nod to Haskell on that front.
One could say that we're professional learners, and that learning things doesn't actually progress us in our career paths, but that our ability to learn -- the efficiency and rate at which we learn -- is the thing we get paid for.
I've used C# for a few years and just started using it professionally this year. But never have used it for web dev. Is the .NET Entity Framework what is recommended today? What are some things I have to be aware of when setting up a web server coming from LAMP and MERN stacks?
I'm still finding that making the actual HTML part in Go is a bit frustrating. Template funcs have not become widely shared and people seem to deeply entangle them with their own project, and there's a lack of i18n and l10n too.
But... most of what I write lives with little to no maintenance, and this is a productive path to a very stable and easy to maintain code base that with locally vendored dependencies checked-in will continue to be stable over very many years.
I wrote a Go API some 5 years ago that has required virtually no changes in all that time (I've rebuilt it with every version of Go and only the 1.0 to 1.1 had a few dependency changes - which were trivial updates).
The benefits for me, hugely outweigh the negatives of not having more tooling for the web side (the API stuff is wonderful already).
For backend I'd surely use Elixir/Phoenix, that's what I've used in the last 2 years, after ~9 years of Ruby/Rails. Elixir and Phoenix are fast to bootstrap, easy to use and deploy, even for complex scenarios (background jobs, websockets, key-value store, etc). Even for quick prototypes, I find Elixir/Phoenix a lot simpler than Ruby/Rails.
For frontend, thus JS, I'd use Vuejs. I switched to it after some year with React. It's a perfect compromise between React and Angular.
I'm going to do most of my logic in Cobol. I'll make the front end with ActionScript & Adobe Flash. I will then call myself an expert & charge around $500/hr for migrating software services.
I'm going to use Elixir and PostgreSQL for my next project, which is an algorithmic trading platform. The two main reasons is I want to learn more Elixir (I've done a few libraries and some other work with it but not a lot) and also the OTP's supervisors will keep things up and running even during a crash. This will be nothing more than an OTP application so no front end available. I may end up making a front end so I can track everything visually and if I do I would probably learn Angular 4, or maybe go back to Elm.
Docutils allows deep customization of source text, programmatically. There's a lot of work needed to bring it to the next level, but the potential is huge. There can be beautiful LaTeX PDF documents and improved HTML output.
Bulma is already a great flexbox-based framework: http://bulma.io. I threw out two huge framework (bootstrap 4 and mdbootstrap pro) to use this. The markup is far simpler, the spacing is grand, and the feature:size ratio is perfect. Highly recommended.
I'm not sure if this is because I'm using a Chromebook, but the HTTPS link to Bulma both fails certificate validation and fails to load CSS. http://bulma.io works fine.
Edit: and it looks beautiful! Thanks for the pointer!
Definitely Haskell, with GHCJS and reflex-frp for the frontend.
I've been using Haskell for most of my personal projects for a while and, over the last year or so, I've been using it at work. The overall experience is incredible. It's hard to isolate exactly why it's so great, and there are certainly some concrete annoyances (tooling and compile times, mostly), but the end result is still unquestionably the best programming experience I've had with any system.
It did take more effort up-front than other languages I'd used. There's still a lot of incidental complexity with bad error messages and tooling that's hard to setup and understand—although it's definitely improved over the last few years. And it did take significant effort to learn, largely because it's so different from every other language I know. But once I got over the initial hump it's been smooth sailing, and I'm always happy to spend some up-front O(1) effort for a long-term reward!
The codebase at work—written by a small team with different backgrounds and levels of software engineering experience, sometimes under tight deadlines—is still largely a pleasure to read and refactor. I consistently leave code in a better state than I found it, not because I am particularly disciplined but because it is so easy.
I also tend to work on my personal projects on a very on-and-off basis—more off than on, most of the time. I've found my Haskell projects to be much easier to pick up months or even years later as compared to my projects in other languages (largely JavaScript as well as Java, Python, elisp and who knows what else).
After some on and off experimentation for quite I while, I finally started a side project using Clojure(Script) in the backend, frontend and the data crunching workers.
So far it is more about learning new things and a different approach to problem solving than about productivity.
If productivity and design is crucial and/or I need to quickly get out something I currently would go with either Pyramid, Flask or Django depending on the requirements. Not because I think Python or these frameworks are superior to all others, but because I value experience higher than technology.
Web - Flask / Postgresql / Vuejs (i can't stand complicated js build chains when 99% of the work i do is sever rendered with only small parts needs js).
Standard Small Business apps - python / pyside
Automations and sysadmin - python
Fun/Learning - everything. I am constantly playing with java, c#, go, whatever made me feel tingly most recently but i rarely move from learning/fun to using it in production as the above stacks just work and i am very proficient in them. Something to be said about getting a problem solved fast and easy.
I've had good luck with React -- but only when using in a smart way. When I develop my reporting software I just use Flask as you do, and even jQuery for simplicity: usually it's just some small modification to the DOM that I don't even need jQuery for, but why not?
Ruby on Rails if it's something that doesn't demand top-of-the-line performance. It easily makes me the most productive writing backend code/APIs and it's not really close -- so many problems that are just solved, sane conventions, etc.
Elixir/Phoenix if I need blazing speed. It's younger and a bit more of a wild west but the speed is incredible.
React for the frontend (if it's anything more than basic CRUD). Regardless, webpack for frontend assets -- I'm never going back to sprockets.
I plan to repurpose old-ish boards with MIPS/ARM SoCs (e.g., AR7240) for various network security purposes. For the C part I have a set of daemons planned and partially implemented which will provide basic functionality without mixing in too much policy/role specific stuff, as well as an IPC library for those daemons. Lua will be used for the test harness and for wiring the functionality provided by the daemons together based on the role of the specific device. POSIX sh for things like execve shims and glue. Everything running on top of a small Linux system. FreeBSD would be nice, but I've had some mixed results with support for it on some SoCs and I want it to be as painless as possible.
Purely a hobby project ATM. I have a couple of boards lying around and I like the design constraints; it's nice to write code for something that's 400MHz, 8MB ROM, 32MB RAM and the size of a match box. Some include removable PSUs, but can also be powered with Li-Po packs &c. Most of them have Ethernet and USB, some WiFi.
Elixir and Phoenix. I've been working in Elixir full-time for about 2-3 months (I rewrote a Rails app at my company), and I feel like I can't go back to Ruby.
I want to experiment with using GraphQL, and mapping the response to props for my React components. It seems like it has the potential to be a lot cleaner than a traditional JSON REST endpoint.
I know some friends who're excited about elm, and that also seems like it would fit nicely with an Elixir backend, so that's on my list of tech to try out.
In my free time, I have some ideas for some more OTP-heavy distributed Elixir OSS.
My docker-compose always has these three containers: Node (for server side rendering), Python (for APIs) and PostgreSQL.
For the frontend, I use React + Redux + React-Router + Redux Sagas (I like starting with a modified version of ReactGo: https://github.com/reactGo/reactGo).
For the API, I use Flask + SQLAlchemy.
I've been thinking about replacing Python with something more strictly typed (Python 3's hint are a good step, but not enough IMO). However, SQLAlchemy is so great I can't imagine developing without it :)
This is what I've been experimenting with. How are you getting along with rendering React on the server from Python? react-python seems cool but it seems like I'm going to have to do some extra legwork to render a whole redux app rather than just passing props to a component.
Or are you serving up the user-facing pages from Node?
Elixir/Phoenix is just delightful, and I'm feeling really comfortable in both. Front-end is my weakness, so probably something popular like React would be good.
ES6 for a React frontend (probably with some gradual migration to TypeScript where possible), either Ruby/Grape/ROM or Kotlin/Dropwizard/Kwery for the backend.
I tried, I legit tried, to go with TypeScript on the backend. But SQL is a continual sticking point in Node; Active Record is bad-and-wrong (immutability removes such classes of failure as to be a no-brainer) so Sequelize has minimal value to me and TypeORM, which definitely has a more reasonable approach with its data mapper design (though it then also commits the sin of decorating your entities), doesn't...seem to...work very well yet? It's early for them, so not throwing any shade. The lower-level libraries will result in me basically reinventing the world for them, and...well...no. Ruby and ROM are as close to doing-it-right as I know, but I think I want a type system to catch my stupid mistakes and Kwery, while immature, does work very well and doesn't rely on object metadata or annotation in order to do its thing.
[+] [-] meesterdude|8 years ago|reply
Because for 95% of my projects, personal and professional, thats the tool to solve it. I don't have to reinvent anything, or worry about gaping security holes common to web applications - i just need to work on the problem domain.
I can focus on good modeling and good front-end UI/UX. And there is flexibility in delivering desktop/mobile applications quickly, using what i've already built in rails.
As a one man band, I can't think of a better instrument to play.
[+] [-] orthoganol|8 years ago|reply
[+] [-] roryisok|8 years ago|reply
[+] [-] 33degrees|8 years ago|reply
[+] [-] sAbakumoff|8 years ago|reply
[+] [-] Omnius|8 years ago|reply
[+] [-] zanny|8 years ago|reply
Not supposed to be a short term project, though. Currently working on extending inth-oauth with openid support. I'm only really able to work on the fringes of this idea, though, since:
* Rocket itself is currently on Hyper v0.10, while v0.11 became async. This means various libraries around it are adapting async while Rocket itself won't for some time. Thus, I'm working on the fringes getting them to async.
* Async itself is in flux, because generators should be entering nightly any day now. When that happens having async/await macros available will make a huge difference.
Generally though I do really see Rocket + Rust in general becoming a huge deal in webdev. I've used Rust for so many C++ equivalent roles because of its safety guarantees, and they make development so much faster when you aren't dealing with undefined behavior cropping up in the corners you have to dig through to find. Additionally, the larger a project gets, the more valuable static typing is. Rust even pushes you towards best practices further by pressuring static dispatch and lock-free sharing of data.
[+] [-] GeneralMaximus|8 years ago|reply
[+] [-] brightball|8 years ago|reply
It's incredibly productive, you get the benefits of microservices with the development and deployment style of monoliths thanks to umbrella apps and there's not a single performance based concern I can think of that it can't handle.
Plus it simplifies infrastructure significantly by removing the need for much outside of Postgres.
[+] [-] tiffanyh|8 years ago|reply
Erlang/OTP 20.0 was just release last month.
Elixir 1.5 was just released this week.
Phoenix 1.3 is just about out the door (currently in Release Candidate phase)
And maybe most importantly, the complete rewrite of Cowboy 2.0 is almost done. Cowboy 2.0 is also currently in Release Candidate phase.
[+] [-] 6t6t6t6|8 years ago|reply
Elixir and Phoenix developers are much more expensive and scarce than Rails ones.
I would only start to use Elixir and Phoenix in my company if we were fully staffed and the rest of developers agreed on putting some extra effort (mostly during their time) to learn the new system.
[+] [-] jelder|8 years ago|reply
[+] [-] amirouche|8 years ago|reply
[+] [-] auxbuss|8 years ago|reply
[+] [-] chriswarbo|8 years ago|reply
As for "frameworks", I find JSON over stdin/stdout to do almost everything I need (Haskell's aeson package is good for this; I might try learning lenses too next time). I also make extensive use of env vars to pass options/config into programs, since I find their semantics (key/value pairs, globally readable, inheritable by child processes, overridable for child processes) more friendy than commandline arguments. Their only downside is being mutable, but that's easy enough to avoid in one's own code.
I also use Nix to manage all building, dependencies, etc. since it's trivial to get code written in many languages to play nicely together (my current project uses Haskell, Bash, Racket, Python, ML and Isabelle). Nix's "Hydra" build server is nice enough for continuous integration, although it's admittedly tricky to set up (it doesn't have proper versions; you need to find a git revision which works :( ).
[+] [-] shae|8 years ago|reply
[+] [-] pc86|8 years ago|reply
[+] [-] wyager|8 years ago|reply
It's difficult, but worth it. Lenses are super cool. They also play well with Aeson. There's a package lens-aeson that has a bunch of useful stuff. You can actually operate directly on Text values and treat them as JSON structures.
[+] [-] twodave|8 years ago|reply
...totally made all those up, but by the time I get around to it they'll all probably exist, right? Point being, it is both alarming and overwhelming to me the sheer number of available frameworks and languages that all attempt to solve the same things. Even when I dedicate myself to learning whatever the "latest thing" is, it's only a matter of months until I feel behind the curve.
I'll stick with C# on the back-end and React/ES6 on the front until something compellingly better comes along. The reasons NOT to use .NET on personal projects (especially the $ factor) are continually declining, and there's really nothing I've learned about that stack that doesn't readily translate to whatever other languages I've encountered thus far (Python, Ruby, Rust, Go, etc).
The only thing I feel like I'm missing out on at times are algebraic data-types, so I guess I'll give a nod to Haskell on that front.
[+] [-] fapjacks|8 years ago|reply
[+] [-] christophilus|8 years ago|reply
[+] [-] ccdev|8 years ago|reply
[+] [-] Scarbutt|8 years ago|reply
[+] [-] agumonkey|8 years ago|reply
[+] [-] buro9|8 years ago|reply
I'm still finding that making the actual HTML part in Go is a bit frustrating. Template funcs have not become widely shared and people seem to deeply entangle them with their own project, and there's a lack of i18n and l10n too.
But... most of what I write lives with little to no maintenance, and this is a productive path to a very stable and easy to maintain code base that with locally vendored dependencies checked-in will continue to be stable over very many years.
I wrote a Go API some 5 years ago that has required virtually no changes in all that time (I've rebuilt it with every version of Go and only the 1.0 to 1.1 had a few dependency changes - which were trivial updates).
The benefits for me, hugely outweigh the negatives of not having more tooling for the web side (the API stuff is wonderful already).
[+] [-] apeacox|8 years ago|reply
For frontend, thus JS, I'd use Vuejs. I switched to it after some year with React. It's a perfect compromise between React and Angular.
[+] [-] mattferderer|8 years ago|reply
[+] [-] tomcam|8 years ago|reply
[+] [-] jetti|8 years ago|reply
[+] [-] git-pull|8 years ago|reply
The site is a work in progress, you can preview at https://devel.tech.
This is docutils: https://devel.tech/site/updates
This is sphinx: https://devel.tech/features/django-vs-flask/
Docutils allows deep customization of source text, programmatically. There's a lot of work needed to bring it to the next level, but the potential is huge. There can be beautiful LaTeX PDF documents and improved HTML output.
That's not to mention the power of reStructuredText's custom roles: http://docutils.sourceforge.net/docs/howto/rst-roles.html
My ambition is to be able to give back improvements upstream (https://devel.tech/site/open-source).
Also, the maintainers on the docutils mailing list have been very helpful to me with questions relating to internals. I recommend checking it out at http://docutils.sourceforge.net/docs/user/mailing-lists.html.
Bulma is already a great flexbox-based framework: http://bulma.io. I threw out two huge framework (bootstrap 4 and mdbootstrap pro) to use this. The markup is far simpler, the spacing is grand, and the feature:size ratio is perfect. Highly recommended.
[+] [-] tonyarkles|8 years ago|reply
Edit: and it looks beautiful! Thanks for the pointer!
[+] [-] tikhonj|8 years ago|reply
I've been using Haskell for most of my personal projects for a while and, over the last year or so, I've been using it at work. The overall experience is incredible. It's hard to isolate exactly why it's so great, and there are certainly some concrete annoyances (tooling and compile times, mostly), but the end result is still unquestionably the best programming experience I've had with any system.
It did take more effort up-front than other languages I'd used. There's still a lot of incidental complexity with bad error messages and tooling that's hard to setup and understand—although it's definitely improved over the last few years. And it did take significant effort to learn, largely because it's so different from every other language I know. But once I got over the initial hump it's been smooth sailing, and I'm always happy to spend some up-front O(1) effort for a long-term reward!
The codebase at work—written by a small team with different backgrounds and levels of software engineering experience, sometimes under tight deadlines—is still largely a pleasure to read and refactor. I consistently leave code in a better state than I found it, not because I am particularly disciplined but because it is so easy.
I also tend to work on my personal projects on a very on-and-off basis—more off than on, most of the time. I've found my Haskell projects to be much easier to pick up months or even years later as compared to my projects in other languages (largely JavaScript as well as Java, Python, elisp and who knows what else).
[+] [-] smoe|8 years ago|reply
So far it is more about learning new things and a different approach to problem solving than about productivity.
If productivity and design is crucial and/or I need to quickly get out something I currently would go with either Pyramid, Flask or Django depending on the requirements. Not because I think Python or these frameworks are superior to all others, but because I value experience higher than technology.
[+] [-] Omnius|8 years ago|reply
Standard Small Business apps - python / pyside
Automations and sysadmin - python
Fun/Learning - everything. I am constantly playing with java, c#, go, whatever made me feel tingly most recently but i rarely move from learning/fun to using it in production as the above stacks just work and i am very proficient in them. Something to be said about getting a problem solved fast and easy.
[+] [-] odonnellryan|8 years ago|reply
[+] [-] schneidmaster|8 years ago|reply
Elixir/Phoenix if I need blazing speed. It's younger and a bit more of a wild west but the speed is incredible.
React for the frontend (if it's anything more than basic CRUD). Regardless, webpack for frontend assets -- I'm never going back to sprockets.
[+] [-] sebcat|8 years ago|reply
I plan to repurpose old-ish boards with MIPS/ARM SoCs (e.g., AR7240) for various network security purposes. For the C part I have a set of daemons planned and partially implemented which will provide basic functionality without mixing in too much policy/role specific stuff, as well as an IPC library for those daemons. Lua will be used for the test harness and for wiring the functionality provided by the daemons together based on the role of the specific device. POSIX sh for things like execve shims and glue. Everything running on top of a small Linux system. FreeBSD would be nice, but I've had some mixed results with support for it on some SoCs and I want it to be as painless as possible.
Purely a hobby project ATM. I have a couple of boards lying around and I like the design constraints; it's nice to write code for something that's 400MHz, 8MB ROM, 32MB RAM and the size of a match box. Some include removable PSUs, but can also be powered with Li-Po packs &c. Most of them have Ethernet and USB, some WiFi.
[+] [-] jmcgough|8 years ago|reply
I want to experiment with using GraphQL, and mapping the response to props for my React components. It seems like it has the potential to be a lot cleaner than a traditional JSON REST endpoint.
I know some friends who're excited about elm, and that also seems like it would fit nicely with an Elixir backend, so that's on my list of tech to try out.
In my free time, I have some ideas for some more OTP-heavy distributed Elixir OSS.
[+] [-] dec0dedab0de|8 years ago|reply
Python because of the syntax, and community.
Django vs other python frameworks, because it has sane defaults, and has made everything pluggable or easy to ignore should I need to change.
Intercooler because I'm awful at js, and the few things im doing shouldnt need full js apps.
[+] [-] senorsmile|8 years ago|reply
[+] [-] temuze|8 years ago|reply
For the frontend, I use React + Redux + React-Router + Redux Sagas (I like starting with a modified version of ReactGo: https://github.com/reactGo/reactGo).
For the API, I use Flask + SQLAlchemy.
I've been thinking about replacing Python with something more strictly typed (Python 3's hint are a good step, but not enough IMO). However, SQLAlchemy is so great I can't imagine developing without it :)
[+] [-] ioddly|8 years ago|reply
Or are you serving up the user-facing pages from Node?
[+] [-] raarts|8 years ago|reply
[+] [-] droidist2|8 years ago|reply
[+] [-] KZeillmann|8 years ago|reply
[+] [-] eropple|8 years ago|reply
I tried, I legit tried, to go with TypeScript on the backend. But SQL is a continual sticking point in Node; Active Record is bad-and-wrong (immutability removes such classes of failure as to be a no-brainer) so Sequelize has minimal value to me and TypeORM, which definitely has a more reasonable approach with its data mapper design (though it then also commits the sin of decorating your entities), doesn't...seem to...work very well yet? It's early for them, so not throwing any shade. The lower-level libraries will result in me basically reinventing the world for them, and...well...no. Ruby and ROM are as close to doing-it-right as I know, but I think I want a type system to catch my stupid mistakes and Kwery, while immature, does work very well and doesn't rely on object metadata or annotation in order to do its thing.