Kotlin is definitely on the shortlist for the next language to be supported! Which language we'll pick up exactly depends on the landscape of available tools for that language. Kotlin is pretty new so I guess that there could be a need for Sourcetrail :)
If you ever go that route and you plan or using/creating some open-source components I would be very interested on hearing more (I am a JavaParser/JavaSymbolSolver contributor)
My hypothesis is that PSD2 will not be the golden opportunity everyone hopes. Banks are an oligopoly and unfettered open access to their customers via open APIs is potentially a disaster for them. They have little to gain and everything to lose. When you consider this and then expect incumbent banks to act in their self-interest it follows that they will act to subvert the impact of PSD2, e.g. by fragmentation, lobbying for onerous requirements in order to consume them, etc. All of this is already happening, which is why I think there is an opportunity for Teller by truly aligning with developers and users.
Removing roaming fees for all European telecom operators was also a something that they had little to gain and everything to lose. But, here we are.
From my understanding SEPA is getting implemented. I could see PSD2 following the same path. Some banks will drag their feet, but it is a pandora box situation, as the banks that will implement PSD2 first might get all the apps attention and love, potentially driving new customers.
Let's see next year how PSD2 adoption pans out...
Current roaming regulations in the EU are designed with the biggest, transnational players in mind. By subsidizing operations in a less lucrative market using proceeds from other countries, they can bleed smaller national telecoms. They will then proceed to buy them for pennies on the dollar. This will result in less competition down the road, and higher prices for the end user.
http://ec.europa.eu/transparency/regdoc/rep/10102/2016/EN/SW... - see page 32 (ARRPU). Operators in different countries have different profits per user (obvious). If you have someone like T-Mobile or Orange, they'll use the proceeds from say... France, to finance their operations in say... Poland. This will put pressure on other national operators to further lower prices. Lower prices mean lower profit margins, mean lower dividends, lower company valuation, being less attractive to investors, etc. After a while their value will decline by so much, they'll be willing to sell themselves at the current going price of their infrastructure. Orange buys them, and kills off competition.
We've been using Algolia in production for 8 months and moved to self-hosted elasticsearch.
Small dataset, 2,5million records in 10 indexes IIRC, data structures and filtering were quite complex.
Algolia Pros:
* very nice UI/dashboard, stats, lots of options, flexible
* documentation is nice, 'onboarding' was not an issue
* it worked reliably most of the time
Cons:
* lock-in/proprietary. Think twice if you want to base your business on it.
* you have trust them with very sensitive customers data
* it is expensive. We reduced costs from $800/month to 40$/month by moving to self-hosted open source solution
with same level/quality of customer experience.
* guys at Algolia like to rewrite client libraries and make them completely backwards incompatible.
Good luck rewriting almost everything.
* support is incompetent and honestly it was useless in our case. I don't want to share details here in public as lots of people were involved
in the case, but their support is disaster and for us that was major reason to migrate away.
We had major issues for 2 weeks and in the end had to debug&fix problem in their client library by our developer.
Long story, but that one was disaster.
In short, it wasn't extremely horrible experience overall, product is nice in general, but elasticsearch is very very good and Algolia just couldn't justify price tag, sorry.
I am sad to see you had a bad experience with Algolia and I can assure you that we put a lot of effort on backward compatibility:
* we have never discontinued a feature in the API since the launch
* We never broke our API clients, we proposed a new version when a new feature required a big change but we kept the previous version (and this happened only on two API client in 5 years)
For the support, this is our engineer's team working on the product that does the support and we put a lot of effort to make sure all our customers are satisfied and get the relevant answers.
Then if you got the same customer experience with a $40 machine, you have probably not used all the feature/power of the engine. I am sad to see such a feedback and you can make me accountable to make sure we will do everything we can to satisfy all our users
In any case, I would be happy to get your detailed feedback by email (julien at algolia.com). I see it as a good opportunity for us to improve ourselves
I'm considering learning go but amount of 'return err' and 'return nil, 0, err' is instant turn-off. Is this best-practice error handling in go ?
Thanks !
It's pretty normal and you will get used to it quickly.
Thanks to this pattern it's very hard to ignore errors.
The only think that could be done better is instead of always blindly returning an error, one could wrap them in higher level errors and build a sort of error trace:
E.g:
- task failed because
- authentication failed because
- could not load credentials because
- because file xy.pem is not readable
But instead of the above, you often just receive a "permission error", but you don't know where it came from, which can make debugging hard.
Basically. It's a little different because you have more control. It's way too easy to assume exceptions won't happen and basically ignore them. But they happen in unexpected places (e.g. every time when dealing with IO).
Exceptions only contain a function call trace (stack of function calls), while a logical error trace is more like an explicit try/catch/wrap/throw around every call and could be more informative to the end user if done properly.
This does not require exceptions. A very simple implementation could involve appending the additional error to the messsage from the lower error level. As far as I understand, exceptions were invented so that error handling code will not clutter up the "happy path". They allow "exceptional condition handling" to be seggregated. But in real world applications you may need to, say, recover from an error. For example, if connection using https fails, fallback to http. This makes code using exceptions look wonky. So might as well use error codes always
This particular code would benefit greatly from named return values.
For example, BuildStats is defined as returning (* stats, int, error), when it could name those and just use naked returns. In buildInstancesStats, they name the return values but then repeat them again on all 3 return lines instead of just using a naked "return".
