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.
I mean, I get it - for a personal project, I did exactly what you just described, wrote the web app in rails and wrote some scikit-learn stuff with python. I did this mainly because I like rails, I like python for ML stuff, and I didn't want to have to learn Django to get a prototype working.
But assuming you were willing to take a small hit/make a small investment in a new technology, do you think it might be a little better to have it all in python, and use Django? Or is the separation similar enough that it doesn't really make much of a difference (i.e., you'd be calling the ML stuff through an api anyway, an your web app would be pretty separate from your ML service, so the only real benefit to Django vs Rails is one language for everything, which I'm inclined to think isn't that big a deal).
I've moved more heavily into Python lately because of data analysis, ML, numpy, all that, and I am enjoying it a lot. I find python very nice to write in, even though I like Ruby and Rails a lot. Python looks good on the page, and has that clarity I like in ruby and rails, and of course the scientific programming world isn't really a ruby one, python is far, far more prevalent. So I've been thinking of taking the plunge and learning Django, but I'm not completely convinced it's really necessary, since you can do what you just described here...
Oh also, (sorry, this is a very scattered post), would you mind sharing some of the technical information about what tech you used to create the api for your python side?
Ok, so I'm going to bite. I'm using Django for my company's website, and while I think it's hands-down the best framework for Python, I must admit to having felt some envy when I investigated what all the fuss on Rails was all about.
I think Rails' controller concepts are cleaner, and its way of handling forms is simpler and more direct (granted, with more sugar or magic, which some have a problem with -- not me).
Railscasts was awesome. In particular, I really loved the ASCIIcast feature on each video. I can't say enough about how helpful that site was in terms of helping me learn Rails.
Just today, another commenter  said that...
The job market for Rails devs seems to be pretty dry.
Many Rails devs I know, including myself, do not get even
10% of Rails job offers anymore, as it used to be until a
couple of years ago.
That's about 20% of the jobs.
1. If they tried hiring me as a mid-level Rails dev, I'd be too inexperienced in Rails
2. If they tried hiring me as a staring Rails dev, I'd be too underpaid
So apparently, my past web dev skills are non-transferrable to some companies that hire web developers. Yikes.
With rails when i'm writing some new code quite often i'll open pry and experiment. %w!bob tom harry!.<tab><tab> gives me all the things I can do on this array. So maybe I'd do %w!bob tom harry!.sort
If i'm in iex (the elixir equivalent REPL) I have no such help! first, I can't use %w! to define an array, and secondly You can't call things like that. The equivalent is
['bob', 'tim', 'atom'] |> Enum.sort
The second part is a pretty fundamental language difference but you can use sigils to handle the first part. E.g., to generate word lists use ~w like so:
~w(bob tom harry)
1) I generally prefer Ruby's syntax over Python's (I would miss blocks for sure)
2) Rail's ecosystem seems larger than Django's, but that could just me being more familiar with it
3) There seem to be a lot more Rails jobs than Django ones
Django would make more sense for a business that uses python for other things, though.
I have know django developers who were great in django but never got their heads around python beyond the framework.
Maybe things have changed since the last time i poked at it.
With PHP, building an online store was possible for me. With Rails, it became obvious.
Always be willing to upgrade - but don't hastily discard something useful for something new either.
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.
REST shouldn't be too bad; there are even frameworks dedicated to it, like https://github.com/cargonauts-rs/cargonauts
Can't speak to GraphQL though.
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.
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.
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.
(I don't agree that your other assertions are correct, but I'm most interested in this one.)
I'm excited to try Elixir but from what I've read (e.g. https://medium.com/mint-digital/elixir-deployments-on-aws-ee..., http://engineering.pivotal.io/post/how-to-set-up-an-elixir-c...), much of my recent experience in running production apps at scale won't apply to Elixir/Phoenix.
There's a Redis adapter for Phoenix channels that you can use in environments like Heroku where clustering might not be an option.
If you want to use built in Mnesia database on an immutable or cluster, attach block storage and configure it to store to that disk so you can remount when you deploy your immutable image.
Hot reloading is the only one where you NEED mutable servers.
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 :( ).
Bash is mostly for gluing things together; it's (almost?) all in the form of Nix derivations, and mostly just pipes things around (lots of calls to `jq`).
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.
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 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.
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.
Edit: and it looks beautiful! Thanks for the pointer!
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.
My main advice is just to jump into it, and to distinguish problems that you should try to solve on your own to learn faster from purely incidental problems that aren't worth your time. (Conceptual questions and understanding abstractions falls into the first camp; dependency issues and bad error messages in the second.) Especially with the second sort of problem, you can always get help on #haskell IRC, /r/haskell or StackOverflow.
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.
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.
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.
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.
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.
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 :)
Or are you serving up the user-facing pages from Node?
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.
Amazing that NONE of the top 10 answers mentions things like PHP or JS, but focuses more on niche frameworks.
I am learning Laravel though and it's completely changed PHP for me, such a nice framework to build upon.
But now, almost a year later, I think I finally have a pretty good handle on Go, so I think it's time to break out the Rust again.
- Python3 to rewrite a moderate-sized batch application with a lot of custom rules
- Java/Spring to rewrite an internally-used web app
Reason: lots of developers on the market, established ecosystem and design patterns - all that is good enough to get the job done.
I'm using Pyramid and it's decent. A little less convention-oriented than Rails but still, nice.
For non-web: either, F#, C# or Rust depending on what it's about.
* LuaJIT. Amazing performance, ranging from near-C to better-than-C.
* 1-indexing actually prevents a lot of off-by-one errors.
* Anything can return. Even files. (Great for library making, and generating namespaces.)
* Luarocks is a decent package manager, for a very basic language.
* Moonscript. No-boilerpate to-Lua language, but Lua can import it, and vice-versa.
- rust on an esp controller, or as a lisp implementation language
- lua as embedded scripting for dillo
- clojure to try to design a more concurrent lazy reactive graphical system. Totally because it's been since forever that I wanted to have something more lively and that I knew back and forth.
Because Clojure as a language really spoils you, it's more concise and quick for prototyping than any other tool I've tried. And Reagent or Om build lightning fast interfaces.
(Background jobs in my case mostly seem to be responding to webhooks, sending out emails, etc.)
When it is out "for real" I'll look, but I get the impression switching from Perl5 -> Perl6 is probably comparable to switching to golang, or similar.
Having said that, there is a lot more to Perl 6 than what comes baked into Perl 5.
The transition is a lot more like C to C++, where you could just use a C subset and be immediately productive.
Perl 6 has given me basically all the things I wanted changed in Perl 5 (function signatures, everything is an object, built in REPL) plus a whole bunch of stuff I didn't know I wanted but now love (gradual typing, crazy powerful type system, amazing out of box CLI argument parsing).
With Inline::Perl5 you also have access to all of CPAN.
Performance isn't quite there yet, but for the stuff I use it for (one off scripts, reports, personal CLI tools) it's been great.
Orleans is a virtual actor framework, similar to Akka in Scala.
For anyone unfamiliar, it's basically distributed OOP built into the runtime. You instantiate a User class, and that class instance will exist somewhere in your cluster, but you can access it like a regular class anywhere in code. You could then have a Company class on another node in the cluster, and they can interface seamlessly with each other without any networking code -- just as if they were running on the same machine. Adding capacity is as simple as spinning up more app servers, and because of the way Orleans handles state and garbage collection, you've basically got a distributed cache of all your recently accessed objects, so next time you access them there may not be a need to query the database.
Personally, our use cases were highly applicable to the use cases for which Orleans has been battle tested.
Orleans also makes a lot of promises around availability and fault tolerance, which are really important for such a system.
On the surface, Orleans seems a lot easier to use and abstracts away a lot of the complexity of building a distributed system.
Rust because I want to learn it, VHDL because I know it reasonably well and need more practice. Also I've got a nice little FPGA dev board, I should get some more use out of the thing. (Digilent Nexys4 DDR).
I'm looking around for this and I'm not sure that I've found the right information here. Does this apply on a per-field basis?
I'm only 27 and feel like a dinosaur for using PHO, but it's what I've always known and Laravel makes prototyping so easy.
Professionally, Java or .NET based languages.
The exact one depends on the customer, but mostly Java or C#.
WPF, UWP, Android, JavaFX if I am able to suggest "native" based solutions.
JEE or ASP.NET if actually must be web based.
For web projects straight ES 6 on the browser side.
If talking with databases, Transact SQL, PL/SQL or pg/SQL as well.
It encapsulates everything I used to do with Node.js using Express and middleware plus socket.io for real time.
I am working on making it into the 1.0.0 and then will add React to it.
React / Preact
[an observable library]
TypeScript for everything
I'm coming from web development - and feel a bit stuck on how to layout things with Xcode / Swift. I'm not convinced by the graphical way to build interfaces provided by Interface Builder / Storyboards, as they feel quite limited in terms of precise control, dynamic layout, no duplication and use with VCS.
Optimally there would be something like React to build interfaces declaratively.
Does anyone have some insight into this topic?
(Also: why are variable declarations so implicit in Swift? When importing a package all its exported variables are avaliable within the file, making code really hard to read in my opinion.)
Mostly small side projects.
Using emacs as a base to improve an internal business process.
I would like to find a way for everyone to use org-mode but we were running into too many merge conflicts.
I just learned about mmm-mode (https://github.com/purcell/mmm-mode) but I haven't really dug into it to see if this could be the bridge between Org-mode + forms-mode.
Editing and entering structured data is still one of the most annoying tasks I do, and I still don't have a good solution to it.
The emacs package requires request, json, widget, wid-edit and cl.
I would like to open source it in the near future.
Love the combination of Serverless and AWS, setup and deploy a full environment with Lambda, API gateway, Dynamo, Elasticsearch, SES with one command. All of it already on a CDN and fully scalable.
For server stuff in production, once I went Elixir/Erlang I haven't looked back. Just blows anything else I'd used out of the water (in terms of productivity, performance, stability, and... FUN -- deployment is a bit of a bitch).
I'd also love to play more with Julia and Idris at some point.
Some computations with sparse matrices are better expressed in the M-code, but the bulk of the image processing work is done by standalone programs written in C, piped together by a shell script.
Most probably I will prototype a small CRUD app with Gin and Gorm to have a feeling of it. Anybody has gone this path already and would recommend a better tech stack based on Golang?
The rest of the team has been writing Scala for other projects (and Python for the ones I'm working on).
By the way, if anyone here is in Algiers, Algeria.. Get in touch, we're hiring (mostly ML but we're open to technically and humanly interesting people).
Coupled with Azure, I expect we'll have a production grade system in months.
The one thing I haven't nailed down is how to handle business rules - I might finally use a BRE as the project fits that need well, but I'm worried about those since I've never used one.
Besides that, I sort of want to go as minimalist as possible on the front end. I went clean for a while, relying on just jquery and CSS and it felt great, after all this time spent on Bootstrap. It just offers me so much control and customization to be free of frameworks sometimes.
Swift on the server: fast, typed and expressive like Python/Ruby
Postgres: the world's best open source Db no explanation needed
REdis : ranking systems and all
Elm: Seems easier to get shit done with, coming from an iOS backend...React/Ember are confusing
Currently my favorite stack using my two favorite languages and I see no reason to change it; the only exception would be when the client wants a prototype ASAP, then I'll probably use Django.
The philosophy behind the project's choices resonate with mine.
Simple is good.
I'm not really aware of another good option for doing AU/VST/AAX plugins.
Actually I started @ https://github.com/amirouche/socialite
Because I can :)
1. Go + chi + Postgres + React
2. Node + koa + mongo + React
I also really want to try Elm.
It comes with a blazing fast build system with dependency management. I've found it so easy to build golang projects or use them as a library. And the single binary for all platforms makes distribution easy.
The decision to keep the language simple along with bundling a great standard library reduced my learning curve.
Can't imagine switching to another langauge.
I plan to use as much from the OTP and the standard library as possible.
I will be starting a new project soon though, and I'm thinking of trying React, Apollo, GraphQL, Sequelize and MySQL.
Plan on learning how to build a streaming pipeline in Python
"Django is a great fit for any web application," becomes "Patch Django or spin up additional services with a new communication layer for web sockets?"
"Python is fast to develop in, and it will always be fast enough when running," becomes "It's not fast enough, and we don't have expertise to write the C extensions."
"Ansible is awesome," becomes "Salt fits our security needs."
"Angular all the things!" And we all saw where that one went.
For all I know, I'll be writing an Elm application in Electron. I hope not, but stranger things have happened.
Because it's what I'm used to and it gets the job done.