Ask HN: What kind of information do you look for before learning/using new tech?
Hey. I am currently writing a blog post about my experience with Elixir. I aim to write about things I liked, but also I want to describe stuff that I just hated or disliked. Because I've noticed that people always try to praise the new tech they are using, but rarely point out bad things. And the truth is that learning a new technology is many times very time/money consuming process.
114 comments
[ 3.1 ms ] story [ 186 ms ] threadIf it’s for a task, I’d say:
1. Really spend some time to understand what you’re trying to solve 2. (If applicable) What pain point are you experiencing with existing solution? 3. Find tech (old or new) that might be a good solution, and understand their limitations/trade offs that you'll be making by choosing this tool.
Then, make a decision.
If it’s for learning, it ultimately is what are you trying to get out of the learning experience, and see if it fits your goal. (It is totally OK to learn a new tech just because it sounds cool - Learning more about something cool is a type of goals as well.)
Elixir is great for a chat application. At the same time it's probably not the right choice for a Machine Learning project.
Of course there are a number of absolutes that I look for regardless of the context:
* How good is the documentation?
* Is it actively maintained?
* Is it mature?
* etc.
Relatedly, while I wouldn't use either for many types of ML...I wouldn't use Python either. The only benefit to using Python in this space is it has libraries bound atop C/C++ implementations. Erlang/Elixir doesn't, that I know of, but that doesn't prevent it from being done if someone wanted to. In terms of actually building something from the ground up...well, it depends. It isn't fast...but it does make the concurrency part easy to model ( https://www.amazon.com/Handbook-Neuroevolution-Through-Erlan... for instance), and for learning/prototyping that might be what you're prioritizing for. Certainly, Erlang/Elixir have seen use in high speed trading and ad bidding platforms, things known for needing low latency.
Edit: also, active reddit community. I don't ask a lot of questions there, but it's a reasonably good metric of the health of something IMO.
Second is the tooling. How well supported the framework or tech is online and what kind of tooling exists already.
Thirdly, when was the last stable release of the stack occurred and how many and how often do these released occur. This goes a long way to show the maturity.
Fourth, how easy it stands with the already developed knowledge base of your team.
Fifth, are your team members excited about it. Or are you just forcing them into a change that they do not desire.
Lastly, is it really necessary? Can't it be done with whatever you have already. If not, answer in great detail and ask someone to crosscheck.
Not too long ago, that statement would've been seen as satirical. Microsoft has left a huge graveyard of technologies behind. They seem to be on a better track now, but I'd still be wary.
2. What makes it better/worse than other solutions?
3. How is the project run/what is the maintainer situation like?
4. What is the community like? Will I have a hard time finding someone else to work on this project competently if I use this tech?
5. How long has it been around / will it be around in 5 years?
Same with RISC-V ISA. These two have the strongest momentum right now.
The one that feels the momentum is starting to slow is Rust.
The most important is an analysis of what use-cases is Technology X good for, and why? Every technical decision is a list of pros and cons. If it fits the use-case perfectly, that is the most important factor.
After that the most important factor I consider is community and momentum.
It's possible a technology is immature and lacks good documentation. BUT - if it has a rapidly growing community and momentum, these 'cons' will disappear rapidly.
My time is limited for learning any new to me technology. If it doesn’t either lead to me making more money in the future or remaining competitive, I don’t learn it.
Java and C# have been the go to enterprise languages for at least 15+ years. Sql Server/Oracle/MySQL have been three of the most popular database for more than 15 years. JavaScript has been in demand forever.
AWS adds stuff all of the time, but the basics still work like they always have.
I avoid trying to keep up with the latest $cool_kids_front_end_framework for just that reason. It’s about knowing where a technology is in the hype cycle.
Just type in the names of the languages/frameworks into a job search engine with "London" as the location. It'll show up in their hiring ads. If they aren't hiring, they're irrelevant.
Thus, with PHP versus Python battles, for example, looking at libraries matters more. (PHP tends to be easier to set up for web-oriented projects. Something to consider for small or often-changing teams.)
Never mistake popularity for quality. Most of the time they have negative correlation.
Just take SAP, probably a pile of garbage in terms of quality, but it's paying its consultants handsomely and customers keep rolling in.
"quality: general excellence of standard or level."
It is implied here that the product must have issues which are so complicated that you need experts to solve them.
I think it's often the case that hype is not correlated with quality, it's correlated with marketing, social networks, perverse financial interests, click farms, voting rings, etc...
No it isn't. It's orthogonal. If there aren't any issues requiring experts, that's great. If there are issues that require experts, there better be some experts available.
> I think it's often the case that hype is not correlated with quality...
Hype isn't the same as popularity. Hype helps popularity. I'm not saying you should jump on the hype train right away. Let the hype do its job, wait for some critical mass to form.
Just because a lot of people use it, it does not mean that any good people do.
Some technologies are very good in selecting novices only, and some others in selecting experts only. The first ones will always be more popular.
In fact, the average "expertness" of the documentation for the tech and its ecosystem is one of the things I pay most attention to when selecting tools. I've said "expertness" here because I have no better term for it, it does not mean extensive, correct, complete, or any such usual quality. It's more related to "are advanced uses documented?", "is it at the correct level of abstraction?", "are the examples for doing hype or real things?", "do the descriptions pose the proper point of view so they become simple?", and stuff like that.
2. Is it actively maintained? (How) are issues dealt with?
3. How popular is it and what is the trajectory?
I don't want to be the first person to run into all the issues. I'll let the kids do that, they love shiny new technology.
I don't want to invest into a stopgap technology (like Coffeescript). My gut feeling is that Elixir is one of these technologies, it has some good ideas that will probably show up elsewhere in due time.
I do value "XYZ sucks" posts to some degree, but unless I already know the technology reasonably well I probably won't be able estimate the impact of the issues.
* are there any tutorials / code examples? (to see if I like its API/philosophy AND there is a way to pick it up)
* are there any practical, working projects out there (used by companies, etc)? (otherwise it may be not useful for bigger projects)
* is it in active development? (otherwise there is a risk that it will cease to be useful)
* how does it match against other tools (e.g. maybe it is easy to pick, but so are all other frameworks).
Also, I did write some comparisons. Vide: https://deepsense.ai/keras-or-pytorch/ (got popular here).
Programming languages are their own category. They tend to not just be a project investment but a career investment. I generally at least get a feel for the language by reading some projects written in it and looking at code that does things I know how to do in the languages I already know. If there's some known strengths to the language (eg. "Go is good for servers", "Rust is good for system programs", …) I may be tempted to use the language for one such project as my first experience with it.
Software tech, things like what framework/DB engine to use, proprietary services such as AWS/GCE services and what not: Those I'll find when looking up how to solve a technical challenge I'm having at a particular moment. Reading up on it (documentation, known use cases, success stories, failure stories) is the only way to really decide. Then it's a matter of choosing the best fitting solution from the ones I found.
Important criteria:
- How well does this solve the problem at hand?
- Is it open source?
- If closed source, is it hard lock in or does it have open source tooling? (eg. Redshift uses postgres-compatible tooling/syntax, a huge benefit)
- How good is the code? (And what's it written in?)
- How good is the documentation?
- How popular is it? (= how likely am I to find help when faced with an obscure bug) / Is it an easy tech to hire for?
- How much do I trust its maintainers? (Especially: How much do I trust them to keep maintaining it and keep the project healthy)
- Is the pricing/licensing compatible and affordable for my use case?
The most difficult part of this process is knowing when not to use your own shitty hammer when there's much better hammers available for the current nail. It's easy to get stuck in a mindset of "The current tech, which I know, doesn't work really well for this use case but it can be made to work somewhat and that's good enough, no reason to look up better alternatives".
I'm always blown away when I discover a new piece of equipment I might have completely missed, were it not for actually googling/asking around for solutions to a new problem. Immediate discoverability of solutions kinda sucks when you aren't sure what to look for.
I look for a book. Books in general are usually miles better than technical blogs and you can find a ton of information addressed about a subject in one place, so there's the convenience factor (not that you couldn't create some program that indexes your bookmarks, but still have the problem of providing meaningful titles and organization for your bookmarks).
I also find that books are generally peer reviewed, especially textbooks, so the BS is kept to a minimum. Makes for a more boring read, but its more accurate.
That being said, I like language analysis posts. People tend to bring up a lot of things I haven't thought of, and there was one done on C a while back on HN that looked very good: https://eev.ee/blog/2016/12/01/lets-stop-copying-c/ (tbh, I skimmed the article because I didn't have a lot of time to read it at the moment).
Actor model? Type-classes? Algebraic data-types? Immutability by default? Type-level programming?
Second, what is the tool support? Do I get an IDE? A languace server? A config for vim/emacs? At least syntax-highlighting? How do the error messages look like? Compiler? Testing frameworks? Lint?
Third, I like to evaluate practicality. Can I imagine maintaining a cli app in this? A web server? Would I be able to connect to databases? Easily serialize data-structures?
I have built this standard up after a few mistakes, where we chose a tool just to realize pretty much everyone working on it was a extremo ultimate rockstar ninja, better known as first-year CS dropout with a god complex.
NB: I'm not saying all first-year dropouts are bad, or that having a degree is in any way mandatory in this field. All I'm saying, is that when our site is down, I'd like to have a few people with 1980s MIT Electrical Engineering degrees on my team. The kind of people who know what a process is, how TCP passes packets, et cetera.
Me? I'll keep doing distributed and low level programming in Haskell.
When I'm trying to choose between competing technologies, I often choose based on popularity rather than isolated merits, as want to build upon something which other people will be contributing to, rather than something marked for death.
There are few cases where one technology is objectively and universally better than another. Most of the time, each has strengths and weaknesses. Often there is overlap between use cases but one is better for one type of usage and the other for another type (such as Redis/Rabbit). In other cases they’re pretty much interchangeable, but one may match more closely to my particular mental model (my experience with React/Vue/Angular); or one may be easier to get started with.
With that in mind, I’m usually looking for balanced information about specific trade-offs. What is this technology good at that the most similar alternatives aren’t as good at? Where do the alternatives excel that this tool struggles. How do the philosophies of the tools differ? What’s the learning curve like? What limitations did you stumble over only after using them for a while? How do the ecosystems compare?
Pick Django? You're also buying into the system of Django packages vs. those for Rails. Same with all the others. Although I think for the most part in the examples you selected, both choices could be equally valid for different projects which is why there are multiple strong choices for those application areas. I think that also means you probably won't go too far wrong picking one vs. the other. I find the choice is often made by how well the stack integrates with other stuff I'm already working on.
Or that the trade-offs have to do with differences in project philosophy (Rails’ convention over configuration vs Django’s explicit over implicit), which in turn impacts in what ways they’re flexible vs rigid in subtle ways, or what sorts of ecosystems grow up around them.
Often there isn’t a right choice or a wrong choice, but there are still trade-offs. And you or your particular team may be able to more easily absorb certain trade-offs than others.
Even if two technologies are fully equivalent, you’ll need some basis on which to base your decision and to use to build consensus so that you don’t spend the next three years fielding “we should have gone with Laravel” complaints twice a week.
Which is why those in-depth comparisons up front can be so valuable — if you can find them.