I would recommend the author remove the automated live chat on this website trying to sell me their services. There's nothing I hate more than trying to read an article and getting a fake chat notification.
I read through this a little while ago when trying to decide if I should try out Elixir for a side project. The language is really intriguing, but I don't want to start a project without grokking how a more complicated project is laid out. Can anyone provide an open source example of a relatively complex project?
I'm working with a couple other contributors to Elixir School on new material that will go into more detail with regards to designing more involved applications.
I agree that resource is sorely missing from the Elixir community.
Phoenix will lay it out automatically for you, but changing project layout depending on the requirements of your objectives is really common in the community.
However, one prominent example, is Hex.pm, the site behind the package manager for Elixir. You can find its repo here: https://github.com/hexpm/hexpm
I'm doing a fairly complex one, Serverboards[1]. It is a monitoring, administration and automation framework. And so far without Elixir it would have taken me four times more to develop the backend.
Anyway it does not use Phoenix (the most beloved web framework), but a simple Web server based on Cowboy and JSON-RPC via websockets, so it may not be a canonical example.
It should be pretty clear how to use it once you read through the examples.
Jaeger requires using Cassandra as a datastore (for now), which isn't easily supported at my company, so I went with Zipkin and used MySQL as a datastore.
I've spent the last 4 months writing a C# web service on .NET Core and deploy on Linux. We chose it because it was the right tool for the job. We're consuming a verbose WCF web service and there were some unique benefits to doing it in a .NET language.
I've been primarily using python for the last couple of years so it's been a really interesting experience. Here are some of my thoughts:
- The language itself is really mature and actually really easy to be productive in. We're using ASP.NET MVC and getting to know the right way to do things took a while though.
- It's hard to use C# without Visual Studio on Windows. I've tried Rider from JetBrains which is decent but takes SO much memory and is pretty slow to develop in. I've been using VSCode recently which is a great general editor but lacks a number of great VS features. Visual Studio for Mac doesn't work with how our app is structured for some reason (VS on Windows in a VM works fine though). I've had to fire up bootcamp a few times to use VS on Windows.
- I thought static typing was going to make it harder to do things, but I think in terms of preventing some common bugs its great. It's no silver bullet though.
- I'm developing on a mac and deploying on Linux. There's no great way to filter for .NET Core packages on NuGet (the M$ package manager). We've run into some issues trying to use versions of packages that aren't yet .NET Core compatible
- There are a number of commonly used Linux environment tools we cant use, like New Relic for APM, because they don't have support for the platform version yet
- The ORM (Entity Framework) we're using is nowhere near as good as something like SQLAlchemy when it comes to migrations. It's laughably bad.
- The testing framework is pretty good, but without real Visual Studio we're missing some great features like code coverage analysis
- Paying for a license to use a library we needed feels REALLY weird
- Overall our web service is really fast. Asynchronous programming in C# is very easy and very powerful and we've been able to make a lot of performance gains by using it judiciously.
- Its honestly hard to find answers googling around sometimes because there are so many version of .NET and 10+ year of answers to the same questions. The same can be said for a number of languages.
- Our build and deployment already handles a few other statically typed languages to making it work with .NET wasn't a big deal for us, but I can see how that could be hard
I'd be happy to answer any questions that people might have.
The post says that, at least for the time being, nothing is going to change for their users. Hopefully you wont be forced to sign into Pinterest to use Instapaper.
> The post says that, at least for the time being, nothing is going to change for their users.
Except a new third party (Pinterest) will sooner or later have access to my Instapaper data. I trusted Instapaper because they had a sustainable business model not based around ads. I do not trust Pinterest because their business model is based around selling my personal information and activity to advertisers.
But no one on this thread believes it. It certainly says something, and not a good thing, about the startup ecosystem when "in the know" people like us automatically treat news of an acquisition as a death sentence for the product, even if the team claims otherwise.
I think Google cares, but they're not communicating it very well. I would hesitate before building a feature that might kick off a relatively complicated process with a lot of external factors whenever a user wants. It seems very complicated and without much positive benefit for the average user.
Yes! Eventually we will support paid modules (the building blocks of the apps you see in the marketplace) that allow developers to define a price and a license. That will in turn dictate how much an app would cost a user to use.
For example, you can imagine a Twilio module that costs a penny to use, so the end user of the app would be charged a penny per use.
