Ask HN: What Technologies to Learn in 2020?
It is always good to keep yourself up to date with the hottest tech stacks. So what are your suggestions for 2020?
For example: Flutter / React Native ? ML? Tensorflow / Keras ? GraphQL ? Vue JS?
Go or Rust?
+1 if you suggest something cutting edge that very less people know about!
440 comments
[ 4.7 ms ] story [ 301 ms ] threadRust isn't. Not to say that couldn't change, but there's just no active functioning infrastructure using it yet - or if it is, it's not very visible yet.
Mind, I code in C daily and rarely see anything else anymore, but I work in that infrastructure level of systems.
I'm personally hot for GraphQL because it's a powerful paradigm to model data.
Both Go and Rust are incredibly interesting languages, in very different ways.
In some ideal world, Go fits in a scaling/efficiency vertical somewhere in-between C and C++ (it's very specific but it basically encompasses all middleware, many microservicing archs, and most 'simple' projects at the edge).
Rust is more of a C++ juggernaut that does it all, if it prevails it'll be applicable to anything and everything.
Both have extraordinary great communities, very welcoming and attracting many great minds. Support is all but guaranteed for the next decade. You just can't go wrong with either, imho, just pick one that fits your domain best.
I'd be happy to work in both.
That's what they say, but in practice people report that the lack of the more intuitive tooling like REPL in Python is a common reason not to use Go for scripts.
> not really with either C or C++
Well in terms of e.g. concurrency, compiling, syntax... the initial intent by Pike and Thompson was clearly unambiguously to do better than C++, which was the language they used at Google at the time.
They literally dug up SCP (1978) and the Oberon family to design a simpler, more manageable approach (the Go spec really is user-centric from inception). It was also months after the release of the first multicore CPU by Intel (Core2Duo iirc?) which paved the way to parallelism.
Regarding C, I agree in terms of domain / purpose insofar as C goes below (not familiar with it myself but cgo lets you inject C). I suppose I mentioned C because that's the standard performance benchmark that people tend to aim for (including the Go team, often), and Go is often a very valid albeit much simpler direct alternative to writing some package in C.
About Rust, thanks a lot for the precisions. I'm not as familiar with it as Go. I do find that Rust has incredible potential to be a really good high-level language, much more expressive than Go will ever be (by design, different goals).
Go is very niche in scope, which is how it manages to be so essential.
But I've heard enough opinions to know this is opened to preferences.
Regarding Rust, it's a systems programming language (with this definition, one can skip the different opinions about it being "more C" or "more C++"), with the implications of the category: primarily, that it's undesirable for web developers to deal with the overhead of systems programming.
I mean Go is a systems/middleware dream, but I wouldn't start there for BI, enterprise-y, "expressive" code. I'm not sure to which extent Go at Google replaced Java or C++ but my money is on the latter.
I'm not stating this as "fact", really open to the discussion! I have much to learn, and this is not speaking from experience but rather perception, extensive but nonetheless second-hand knowledge.
Regarding Rust, good points, good food for thought. Thanks.
Edit notes:
[1] "no generics!" — "wth error handling `if err != nil { return err }`" — which are godsend to other devs, other domains.
Hard to say; it's important to recognize that Golang is still young, compared to Java/C#; the generics subject is very much open.
My very general idea is that Golang is a more modern language, specifically, because it was build from the ground up to tackle more modern problems (concurrency and networking first of all).
Also it's important to consider that there is an ecosystem beyond the pure language design - single binary approach, compiling time, etc. (I also have not-so-fond memories of XML-based build tools, I prefer Makefiles).
I've read of people writing fairly low-level stuff in Gol. I still personally prefer a proper systems programming language for that type of work. On the other hand though, many C/++ tools/projects originated when there wasn't so much availability of compiled languages - therefore the choice of such languages was not ideal; definitely, in the same conditions, Golang would have probabaly be better suited (but imagine how large it would be an Ubuntu distribution where all was written in Go ;-)).
Is there a reason to try WebAssembly besides curiosity or a need to optimize performance-heavy front-end computations in browser?
- as a freelancer, new business use-cases. We're essentially bridging OS with browser in terms of capabilities at that point.
I find that there are often a few low-hanging fruits in pretty much all categories of tech that you might do well to leverage, with parsimony.
Some of my potential projects tend to have unrealistic demands for the budget (hence they remain "potential"), or actually, for the times, and wasm is moving the needle in that regard. Think, do the 20% that yield 80% of the result and integrate that into a classic stack. Baby steps. Low-effort, high-value 'features', you don't need to rock the boat to benefit greatly from the addition of wasm.
- Research: some of it may be gimmicky today, but I wager it'll become the standard a decade from now:
web = OS = native, in the user's perception.
Note that it won't end "platforms" (horizontal business-driven gardens, e.g. darwin-safari, gentoo-chromium, etc). We're talking about a vertical bridge here, "through" the hard+soft stack, from kernel to browser passing by storage, GPU, sensors, at last SMT, etc. It took us what, 30 years, but we finally reach a point where web and native may become technical finer points, not a user experience gap.
So wasm now is already a great enabler of feature-rich user experiences, and that has value to me. It's also a big part of the next paradigm, IMHO, thus worth wetting the shirt as soon as possible.
Unfortunately, the end product isn't very easy to integrate with WASM, but I'm going to keep in mind the possibility from the start next time.
Rust's extra bonus for me is that it can be used to make natively invoked functions that can be used in Erlang/Elixir code with zero risk of taking down the whole VM (which can be done with C).
Seems like the issues I hit either have open issues or I can’t find reasonable solutions. Most recently I tried to convert a Vue app to TS and never could figure out what knobs to turn (even copying over configs from a new, clean run of vue create didn’t work).
Have you had similar troubles or have you always been able to set up a clean project?
I've spent the last five years building SPAs using mainly React and see LiveView evolving as a compelling alternative.
https://github.com/darrensiegel/spelling
Do you still feel that way even with the new features of LV being developed? It feels like how you use it is being heavily churned on with the introduction of Live Components and now people are also building custom unofficial abstractions on top of that. But at the same time, end user features don't seem to be being released that often.
IMO it's starting to feel like Phoenix is becoming very fragmented even though it's already a small community. You have people not using Live View, some people using Live View, other people using Live View Components and others trying to build their own custom take on what a LV component is. Combined with the documentation being pretty sparse on LV in general makes it pretty non-friendly to develop with and a lot of the articles you read online don't apply to "Phoenix". The apply to whatever variant of no LV vs LV vs LV components vs LV custom component library style you use.
It reminds me of the Node days when tj stopped working with Node and a million other libraries and styles started to spring up to become an alternative to Express. It took years for that to settle down and it's still pretty fragmented.
But a lot of folks just want to go heads down and write cool applications. I really do like Phoenix but yeah, since the introduction of LV and watching its development pace for the last year+, I'm getting kind of uneasy with how things are unfolding.
I.e., what happens in case of failure (blocking send/receives on channels; what happens if the sender/receiver fails?), distribution, memory management (Go requiring you to be very cognizant as to whether it's heap or stack based; Erlang is basically all stack based), the dangers of mutability and the required patterns needed to be consistently immutable, etc.
Others are condemned to perpetually reinvent the wheel instead of making true progress.
The number of available libraries is ridiculous thanks to Java interop. Compare this with an Elixir project some of my coworkers did. They ended up having to write their own message bus client library because one didn't exist yet. That sucked up a huge amount of dev time that could've been used to actually make their product.
I don't understand what all the downvotes of the parent are for.
This is simply a large overstatement. There are many other modern popular languages on JVM that have unrestricted access to the exactly same ecosystem. To name a few: Scala, Dotty, Clojure, Groovy, Ceylon, Jython, JRuby.
> Others are condemned to perpetually reinvent the wheel instead of making true progress.
This is a funny statement to make when promoting a language that basically took almost all of its features from Scala and a few minor things from the others. There is nothing original in Kotlin.
BTW: the ecosystem is not only libraries. It is also tooling. Kotlin is a single, proprietary IDE language. Quite limited compared to the other languages I listed.
As far as removing redundant repetitive code, while Kotlin may be slightly better than Java in this regard mostly due to a nicer syntax, it stands no chance compared to Clojure or Scala, which both allow extremely high level, abstract way of coding.
Having said that, Kotlin is a fun language to write in. If I needed to write an Android app, this would be my first choice.
That's a mistake, which industry will eventually recognize if it hasn't already.
Why: Frameworks that use fine-grained DOM updated currently top js frameworks benchmark [1]. Svelte lags a bit behind in performance but it offers a better developer experience
[1]: https://rawgit.com/krausest/js-framework-benchmark/master/we...
So they might work very well if you can contain the state to a single component, but if you have deep shared state dependencies or changes in state in one component that changes a lot of other parts of the site it won't work as well.
I'd also question if (with most modern frameworks) the framework is the primary bottleneck. I usually use hyperapp-v1 as my frontend and find that loading less and optimizing my own code usually leads to better gains than tinkering in the framework.
Not saying that one should ignore benchmarks, but they should also not be the "end-all" measure of a framework.
Also, the ZeroMQ Guide has some fun networking concepts. http://zguide.zeromq.org/page:all
Learning the basics of Ethernet would be helpful as well and is one of those foundational skills that'll make it easier to understand various protocols, commands in Linux, etc.
It's made some things a lot easier, even though I'm now forced to use the npm toolchain. Previously, I liked to just include the Vue files necessary.
I'm finding how Svelte does binding and lifecycle much easier to deal with. Vue's template system was making data flow more complicated than it needed to be, or it was just my misunderstanding that made it so. Regardless, I was able to re-create an small app (that had some template complexity causing me problems) much easier/quicker in Svelte.
We picked up the first angular, because of the “keep up mantra”. That turned out to be a complete waste of resources when the second version released. I’m not saying that it can’t be valuable, but these days we build 70% of our stuff with python, Django for web with a minimal amount of JS because it turned out our clients actually didn’t want SPAs. The rest we build in C#. When I look at the job market in my region of Denmark, almost every job is for JAVA, C# or PHP. No-one is hiring for Rust, graphql, go or any of the other hipster languages / frameworks. People are hiring for modern Angular (along with C#), but no one is hiring for the original version. So it’s frankly entirely possible to skip entire “hot tech stacks” without it being a disadvantage.
If you ask me, you shouldn’t pick up things until you need them. Unless it’s for fun, but who learns a new web-dev related framework for fun?
I do, and I suspect many others on this site too. Do you know where you’re posting?
Didn't you hear, this is a job forum now!
Seriously though, I couldn't agree more. We must even make toy frameworks to discover what new ideas are worthwhile.
I think a lot of the issues are some people trying to take the toys to work too soon. But that's another problem.
It depends a lot what kind of programming job you're looking for.
Personally, I think any programmer would learn something valuable by playing around with Rust specifically. But that's just my 2¢.
Lot of us :D
It's worth learning enough to know when you need them, and when you don't (strengths and weaknesses). That's the bare minimum for me.
The next level of understanding is pretty different, either I'm seriously considering using the technology or I'm intrinsically interested in how it was built. I often dig into the latter if I think I can learn something from how it was made.
Udviklings- og Forenklingsstyrelsen has a huge project written in Clojure, ClojureScript and R and they're hiring all the time.
Ps: I also want To find a Dane who knows vue + tailwind. Impossible to dig up so please go learn ;-)
I mean, JAVA is popular but there wasn’t a single kotlin job in 2019.
Perhaps do that with a new technology :)
I would suggest the same, building something and let it pass out to the public or contributing to the existing projects that might be using the stack that you want to work with.
You learn a lot when you share your own work to others. Good life lessons or maybe career lessons are often learned when sharing something.
"The Creative Habit"
"Creativity: Flow and the Psychology of Discovery and Invention"
If you really take it to heart, though, the Cleese video is all you need. Creativity in my mind falls into the category of "simple but not easy": you only have to do a few things, but they require hard work and thought.
1. Create time and space. Easier said than done if you have a busy life and people who expect things from you. You need to make a quiet place you go where you are not interrupted for a specific period of time. There you think, imagine, focus on your goal and work.
2. Mental clarity / confidence to play and do something not "serious." Creativity requires a playful mindset and the confidence to overcome your self-doubts and fears. Again easier said than done.
3. You have to work. Creativity is a cycle of work, examine the thing you made, and come up with more ideas / next steps. If all you do is think and you never actually work, then you might be "creative" but you aren't "creating." Alternatively if you just work and don't step back to think, you're creating but probably not doing it creatively. So you have to get into a cycle of create, observe think; create, observe, think.
Edit: Also GKE and Firebase.
It’s good to be aware of new stuff, but it’s also a good practice to have a firm command of some well established technologies that have strong support and resources behind them.
It’s been my experience that I get more work done when I can easily find sample code and multiple explanations for API calls. Experimentation and R&D to figure out some bleeding edge stuff may be fun but it’s a lot slower and less stable than using tried and true methods.
About the Tensorflow/Keras thing you mention: Imho Keras is dead with Tensorflow 2.0 and the entire Clusterfuck that came along with it made me try out Pytorch and I haven't looked back at it. I was able to convert my model from TF to Pytorch in half a day without any prior knowledge of Pytorch and it works like a charm.
I would like to pick up a Lisp that's not tied to the JVM for some things... perhaps I'll learn Common Lisp this year.
And of course, the fact that the current steward of Java and the JVM is Oracle makes me a bit uneasy.
Having used Clojure exclusively in my professional life for the last 2 years, it saddens me that we don't see more converts from JS. It's such a great language for today's reactive frontend paradigm. Everyone in the mainstream seems to want JS to turn into Java and are massively migrating to TypeScript. I can't help but feel that TypeScript is just an evolutionary dead-end.
i have no problem with parentheses. it’s the JVM that gives me pause. i feel .NET and BEAM are the better choices these days with c#/f# and elixir/erlang/lfe, respectively.
i would love to use a lisp/scheme but just don’t feel comfortable with the JVM and how much of it comes through in clojure.
Clojure has compilers for both jvm and .net
it is also unclear how to interop clojure clr with c# and f#. clojure clr doesn’t address the want of a stable vm, clear usage, and supporting toolset.
It's also very difficult to build a grass roots movement amongst coworkers because the harsh reality of lisp languages is you pretty much need some kind of "paredit-like" capability in your editor to not go insane. So people are really turned off at both needing to learn a new language and editor functionality.
I'm glad I learned Clojure and lisps in general as they've made me a better programmer. I just wish I could leverage them more.
Really? I guess things changed but I had 0 trouble setting it up recently.
> reality of lisp languages is you pretty much need some kind of "paredit-like" capability in your editor to not go insane
Every major Editor like VSCode, Atom, Vim, Emacs has this.
With cursive it's a great ide for clojure/ clojurescript.
I don't literally mean setting it up like on a dev machine. I mean getting it installed as the language to use to build new products at a company.
> Every major Editor like VSCode, Atom, Vim, Emacs has this.
Sure, but the problem is it's "yet another thing" they need to learn. They're already skeptical about learning Clojure itself because <current-language> works just fine. So dealing with parentheses adds to the hurdles. At least, in my experience. It will of course depend on the people involved.
So, for me, the next thing is trying to build something with React Native and Go as they seem to be very trendy and in increasing demand.
If you know JavaScript and want to make mobile apps, give React Native a try! It’s a good choice for most business apps, and even some games.