Crustaceans, 2021 will be the year of ${TECHNOLOGY}
source link: https://lobste.rs/s/v4crap/crustaceans_2021_will_be_year_technology
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
What technology will “come into its own” this year? Is 2021 the Year of the Linux Desktop? Will Rust become the most important language ever? Will Go supplant Python? Is Ruby ready for a renaissance?
What technology is going to be the one to know in 2021 and beyond, in your learned opinion?
(This question is intentionally open-ended, in the interest of driving discussion.)
-
Backlash against Kubernetes and a call for simplicity in orchestration; consolidation of “cloud native” tooling infrastructure.
-
I’m not sure if we’ve reached peak-k8s-hype yet. I’m still waiting for k8s-shell which runs every command in a shell pipe in its own k8s node (I mean,
grep foo file | awkis such a boring way to do things!) -
I don’t know if it will happen this year or not but I’ve been saying for many years that k8s is the new cross-language J2EE, and just like tomcat and fat jars began to compete we’ll see the options you’re discussing make a resurgence. Nomad is probably one that’s already got a good following.
-
I won’t be surprised if the various FaaS offerings absorb much of the exodus. Most people just want self-healing and maybe auto-scaling with minimal yaml. Maybe more CDN edge compute backed by their KV services.
-
Which FaaS offerings are good? They are definitely less limited than they used to be, but do they deal with state well and can they warm up fast?
I haven’t seen any “reviews” of that and I think it would be interesting. Well there was one good experience from someone doing astronomy on AWS Lambda
https://news.ycombinator.com/item?id=20433315
linked here: https://github.com/oilshell/oil/wiki/Distributed-Shell
-
-
I wish, but I am not hopeful. But I have been on that bandwagon for years now. Simple deploys make the devops folks love you.
-
For those in the AWS world, I like what I’ve seen so far of Amazon ECS, though I wish that Fargate containers would start faster (i.e. 5 seconds or less).
-
I understand where you’re coming from but I don’t think it’s likely. Every huge company I’ve worked with has idiosyncratic requirements that make simple deployment solutions impossible. I’m sure there will be some consolidation but the complexity of Kubernetes is actually needed at the top.
-
-
Boring prediction: TypeScript. By the end of 2021 TypeScript will broadly be seen as an essential tool for front-end teams that want to move faster without breaking stuff.
The alternatives which launched around the same time (Reason, Elm, Flow, etc…) have all fallen by the wayside, and at this point TS is the clear winner. The investment is there, the ecosystem is there, the engineers (increasingly) are there. The broad consensus isn’t quite there in wider world of all Javascript engineers, but I think it’s coming.
Eventually good engineers will leave teams that won’t switch to TypeScript, ultimately hobbling those companies. Their lunch will be eaten by the competitors who’re using TypeScript. But there’ll be money to made dealing with legacy messes of JS / Coffeescript, Backbone, jQuery etc, for the people who’re willing to do it. It’ll be a long-lived niche.
Knock-on effects will include decreased use of Python in an application / API server role (I know there’s MyPy, but I think TypeScript is ahead) except where it’s coupled to data-sciency stuff. I think something similar will be seen with Go. I don’t know how big these effects will be.
Unrelated prediction: Mongo will make a comeback. I’ve really disliked working with Mongo, but I was completely wrong about the price of Bitcoin this year so I assume Mongo’s comeback is inevitable.
-
Agreed. Although TypeScript is a bit OO for my taste, JavaScript libraries have grown sufficiently complex as to warrant strong typing. The adoption rate is undeniable. Vue, Deno, Babylon… When your stack is written in TypeScript, the cost/benefit scale tips in favor of adopting it downstream.
Also, Cosmos is heating up, so you could make a case for Mongo’s revival by extension.
-
Although TypeScript is a bit OO for my taste
My limited experience with TypeScript is that it’s only as OO as it would be if you were writing plain JavaScript. Not sure if that makes sense - another way of saying it would be: JS has adopted some OO trappings, like
class, but if you aren’t using them in your JS then TypeScript isn’t going to push you in that direction - you can write functional TS to the extent that you could write functional JS; and OO TS to the extent that you could write OO JS.Unless you’re refering more to the naming of new keywords, like
interface? I see how those could be associated with popular OO languages, but really there’s nothing making you write actual OO code.-
My limited experience with TypeScript is that it’s only as OO as it would be if you were writing plain JavaScript.
Anecdotally, after working at a Java and C# shop that picked up TypeScript, everyone’s happy having things work more like those languages (well, mostly C# ;) than like JS. I just wish TypeScript would get typed exceptions already.
-
Yes, it is possible to write non-OO TypeScript. And yes, I’m pointing out its emphasis on interfaces and other OO features like class property modifiers.
I realize that the choice to make TypeScript a superset of JavaScript means that its roots in Scheme are still present. I also realize that typing a Scheme-ish language makes it (if one squints hard enough) an ML-ish language. Nevertheless, we should not be surprised if most TypeScript in the wild looks a lot more like C# and a lot less like fp-ts.
-
-
-
Eventually good engineers will leave teams that won’t switch to TypeScript, ultimately hobbling those companies. Their lunch will be eaten by the competitors who’re using TypeScript. But there’ll be money to made dealing with legacy messes of JS / Coffeescript, Backbone, jQuery etc, for the people who’re willing to do it. It’ll be a long-lived niche.
This is quite the prediction. I think I can see it happening. Working with a large, untyped JS codebase is a nightmare and can eat through morale quickly.
-
-
-
I really really want 2021 to be the year of Nix.
-
See also: “backlash against Kubernetes”
-
I struggle to see how building infrastructure on top of a library with howmanythousandslinesofcode of some Standard ML derivative and bash constitutes simplicity in orchestration.
NixOS is neat, but it’s not simple.
-
Hot take: I’d prefer building systemd units that automatically get managed over orchestrating k8s pods any day. Nothing is simple, but Nix provides another approach to managing complexity well.
-
I had an idea to rebuild what was once CoreOS’s
fleetctl. Orchestration built on top of systemd, without anything more fancy on top.-
I think people generally complain about systemd, among many reasons, because distros started with /etc/init.d, picked up systemd, and started using it in the same way. So “why do we need all this crap” makes sense when all the distro uses is the init system features. But systemd, for better or worse, is really a daemon manager, and the argument for systemd vs. sysvinit with NixOS or a tool like that is much stronger.
-
-
-
-
And a blow against Ansible, Terraform, Salt etc. for free!
-
-
-
I think it’s going to be the year (and decade) of shell scripts written in YAML … Github Actions, Gitlab runners, Kubernetes config, sourcehut, etc. :)
I have a few blog posts coming up about that …
-
I already spend too much time being a YAMLgineer.
-
The year of Prolog! Yes, I’m seriuous, last years we’ve seen flourish a new wave of Prolog environments (Tau, Trealla and Scryer) which this year can reach a production-ready status. At least, that’s what I hope and I’m helping this environments with some patches as well.
-
year_of(prolog, 2021).
-
There was even a new stable release of Mercury late last year. It’s, uh, I’m not personally betting on it getting wide scale adoption, but I do personally feel that it’s one of the most aesthetically pleasing bits of technology I’ve ever tried.
-
A couple years ago I hacked on a Python type inferencer someone wrote in Prolog. I wasn’t enlightened, despite expecting to be, from a bunch of HN posts like this.
https://github.com/andychu/hatlog
For example, can someone add good error messages to this? It didn’t really seem practical. I’m sure I am missing something, but there also seemed to be a lot of deficiencies.
In fact I think I learned the opposite lesson. I have to dig up the HN post, but I think the point was “Prolog is NOT logic”. It’s not programming and it’s not math.
(Someone said the same thing about Project Euler and so forth, and I really liked that criticism. https://lobste.rs/s/bqnhbo/book_review_elements_programming )
Related thread but I think there was a pithy blog post too: https://news.ycombinator.com/item?id=18373401 (Prolog Under the Hood)
Yeah this is the quote and a bunch of the HN comments backed it up to a degree:
Although Prolog’s original intent was to allow programmers to specify programs in a syntax close to logic, that is not how Prolog works. In fact, a conceptual understanding of logic is not that useful for understanding Prolog.
I have programmed in many languages, and I at least have a decent understanding of math. In fact I just wrote about the difference between programming and math with regards to parsing here:
But I had a bad experience with Prolog. Even if you understand programming and math, you don’t understand Prolog.
I’m not a fan of the computational complexity problem either; that makes it unsuitable for production use.
-
-
Distributed content technology. I want to see more Activity Pub, more PeerTube, Pleroma, Mastodon, Pixelfed.
I want to see more regular people get good alternatives to Google, Apple and FB Services. I want to see tools to help route around censorship and give us a more free Internet.
-
I can see this happening but I think it will be in the form of separate forums and clones of popular sites, not as something federated
-
-
2021 will be the year of the ARM workstation.
-
The Linux Desktop! For the 20th year running…
-
-
No better time to contribute to: https://asahilinux.org/ :)
-
I had no idea this existed. I thought it was a non-starter. yey. \o/
Also, the developer has a serious history of successfully doing this sort of thing. Suddenly I am even more excited by Apple Silicon.
-
After 17 years of no better time contribute to $linuxthing I think it’s time I had a break from all this :-).
(Edit: well, I’m still going to use Linux for all sorts of embedded gadgets. And there’s a driver I wrote, which I’m maintaining, and I’ve been putting off adding support for a new device for a few months now, what with all the global shipping kerfuffle. So I won’t have a break from Linux – what I do want, and will hopefully get, is a break from dealing with… everything else, from systemd to xdg-whatever and from GTK to Wayland, in my spare time. I’ve got a bad case of perpetual beta fatigue.).
-
-
-
-
What was 2020 the year of?
(Not rhetorical, asking as calibration.)
-
The year of remote working?
-
On the front-end side I think it was another year of “no new flavour of the week”. From where I sit it looks like React is still the dominant UI framework, with Angular trucking along beside it. Those ships have been sailing pretty steadily for a while now. Soon people are going to have to come up with a new trope to make fun of those who work with Javascript ;)
-
-
I hope that 2021 will be a year of slower technology popularisation/adoption as the lag between the technology that is available and the most developer’s understanding is unsustainably large.
Please, nothing new! We don’t need it, we’re all still getting to grips with the old stuff!
-
2021 will be the year of serverless. I think that until somewhat recently you were either all in or not because many execution environments were very bespoke. In 2021 I think that people will be shoving basically everything they can into lambdas/cloudrun/knative/workers and you’ll run your app as far “up” the stack as possible.
-
For companies, maybe, but people still like craft beers and craft servers.
-
+1 for this. Especially considering lambda containers runtimes and aurora pg/mysql serverless
-
-
Julia hopefully. I hate Python with a passion and don’t want to learn R, so I really want to see Julia emerge as a viable alternative in scientific computing. I love its Lispiness as well. The ecosystem needs some polishing but it is very promising.
Bayesian modelling. I’m a big fan of explainable models, and Bayesian modelling and credible intervals are both intuitive and rich. With advances in MCMC sampling and ergonomics (with libraries like Stan, Turing.jl, PyMC3, Edward, and Pyro) hopefully we can see a growing number of Bayesian models.
-
MIT just did a course on it! I think Julia has been on a slow, successful burn for a while now, and I hope that continues happening!
Also, have you by any chance read Bayesian Statistics the Fun Way? I read it with a friend and it’s got me interested in pretty much the same niches you’re describing (Julia & Bayesian modelling).
-
-
- RISC-V CPUs. Because open standards encourage co-operation across borders.
- Zig. Because people want to replace C with something more secure, but in a gradual process, and Zig includes a C compiler.
- MIDI over Bluetooth 4. Because it’s handy.
- The Gemini protocol, since retrominimalism is still fun.
- Godot for game development, because it has matured enough.
- TOML since it seems to be the least disliked configuration format.
-
I’ll take a shot at this.
What technology will “come into its own” this year?
RISC-V will accelerate in a significant manner. This is because there will be a bunch of low-cost linux-capable SBCs released this year. There were none in the past decade of RISC-V.
Is 2021 the Year of the Linux Desktop?
No. It’s hopeless. YoLD will never happen. At this point, I’m certain some other system will actually do what Linux just couldn’t.
Will Rust become the most important language ever?
Doubtful. It is still a new language. Languages take time to gain support; Most just disappear. There’s a small chance that, about ten years from now, this will be a relevant question.
Will Go supplant Python?
They’re too different (typing) for this to even be considered.
Is Ruby ready for a renaissance?
I’m not optimistic for Ruby.
What technology is going to be the one to know in 2021 and beyond, in your learned opinion?
HDLs in general (relevance of specialized-purpose hardware, FPGA or ASIC based, will go up, alongside open hardware).
seL4, and operating systems built on 3rd generation microkernels.
And, RISC-V will become big, so it’ll then be good to have some early experience to show with it.
-
This is going to sound a whole lot like self-promoting (and frankly it is), but I’m hoping to come around to finally make secure boot more accessible for people. Mostly the aversion to secure boot is the poor tooling and the bundle of documentation you need to get around to using it. You shouldn’t need to understand UEFI implementation details to utilize it.
Most of this work is being written in Go in the form of
sbctlandgo-uefi. -
The fantasy: people realizing that Linux is insecure and switching to a model like seL4 for critical systems.
The reality: more proprietary Linux drivers for OEM hardware. :-(
Meta: this post’s ID is “v4crap,” do with that information what you will.
-
I’m not going to be so brazen as to declare “the one to know.” As someone who’s spent a long time doing web development and the last year neck deep in WebGL, I’d say I’m interested in:
- WebGPU: Writing vanilla WebGL is a pretty unpleasant. A framework like Babylon or Three is pretty much a necessity to be a productive web graphics developer. WebGPU promises a much better abstraction for graphics on the web. Now that Apple, Google, and Microsoft are all behind it, it seems like it’s actually going to happen.
- glTF: The chief obstacle to the adoption of 3D content on the web is a common format. The development of this format and its industry adoption is very promising.
- WebAssembly: There was a lot of talk about “isomorphic” or “universal” JavaScript about seven years ago. That dream never quite materialized for most teams, in part because JavaScript was derided by established backend developers, but mostly because node’s module system never caught on in the frontend development community. Most seasoned frontend developers who were around back then have Browserify horror stories they can share. (I certainly do.) WebAssembly’s been around for a while. The debugging story is still pretty crude, but the momentum behind Rust, the announcement of the Bytecode Alliance, discussions about supporting garbage collection, and several recent announcements about running wasm on the backend and CDN layers give me hope that there’s enough momentum behind this standard that we can eventually pick languages based on their own merits rather than what runtime for which they happen to be suited.
-
Perl is glissading in the far North as Ruby remains buried deep in the bedrock to be found again. Again and again. But things fall apart; the center cannot hold.
-
Yes, but this question was specifically about what rough beast you think will slouch toward Bethlehem to be born this year. ;)
-
Oh, the beast…hmmm. Rust. I love rg, for sure. But Rust is approaching that era of “this will solve no matter what problem I throw at it!” Also, it’s “new” and “fast”. I will say, rg has been a JOY. And that’s probably Rust “written well”. Not that I have any idea how “well” written Rust should look.
-
-
-
P2P. Maybe it’s still early, but it there was a lot of momentum in late 2019 / 2020, and a lot seems to be coming together. Just off the top of my head:
- The Dat / Hypercore protocol provides a nice layer for building P2P applications, and made some big strides last year: https://hypercore-protocol.org/. Beaker Browser hit 1.0 last year.
- Matrix launched an early version of their P2P implementation last summer, and it sounds like they’re making good progress on it.
- Radicle launched P2P git hosting at the tail end of last year.
- Working remotely means real-time collaborative tech is more necessary. Collaborative data structures like CRDTs don’t need a central server – each peer has the history necessary to reconstruct the document. There’s a lot of overlap between collaborative editing research and P2P tech.
There are big issues, some probably unsolvable, but the energy seems to be there in a way that it wasn’t 5 years ago. I’m surprised that it seems like progress seemed to slow down so much after BitTorrent, but as someone who’s dissatisfied with large tech platforms and doesn’t see federation as the solution, I’m excited to see the progress.
-
What technology will “come into its own” this year?
Belt drive 3D printers. Hopefully, 2021 will be a good year for me to play with my Creality 3D Ender-pro 3D printer, but will need to spend some time learning OpenSCAD for my CAD modelling.
Is 2021 the Year of the Linux Desktop?
2021 will continue to be the year of the OpenBSD Desktop for me ;~)
-
learning OpenSCAD for my CAD modelling
Honestly, even though “3d models as code” sounds awesome in theory, I much prefer FreeCAD (PartDesign). Maybe it’s just because I was never good at geometry, but designing parts visually with a “feature editing” workflow is much easier and faster.
(btw, there are interesting alternatives in the model-as-code space too)
-
-
This question was prompted by a discussion I had about how I felt like all the momentum in programming languages is pointing toward Rust these days, and I felt like there’s no point in keeping my Go current (it’s been languishing for a couple of years now anyway).
So, I asked this question to see (among other things) if I’m right or wrong.
-
What is driving that feeling? Genuinely curious, because I feel the opposite. I am seeing more and more enterprises adopt Go. In conversations I have with other engineers, Rust still feels a little underground.
I also think that Go and Rust have slightly different use cases & target audiences.
-
Well, lobste.rs, for one. I feel like everywhere I look on here people talk about how they’d re-do everything in Rust if they could. The number of Rust advocates I see here seems to dwarf the number of Go advocates. Maybe that’s perception because Rust is “newer” and its advocates louder, but who knows.
The things that really stuck with me, though, were Linus indicating that he’d be open to allowing Rust in the kernel, Microsoft starting to switch to Rust for infrastructure, and Dropbox migrating their core technologies to Rust.
I just don’t see stories like that for Go. I don’t know if I’m not looking in the right place, or what.
-
Go and Rust more or less solve the same problem (although the overlap isn’t 100%), just in different ways, not too dissimilar to how Perl and Python more or less solve the same problems in very different ways.
I have the impression that, on average, Go tends to attract people who are a little bit jaded by the Latest Hot New Thing™ churn for 20 years and just want to write their
ifs andfors and not bother too much with everything else. This is probably one reason why the Go community has the (IMHO reasonably deserved) reputation for being a bunch of curmudgeonly malcontents. These are not the sort of people who go out and enthusiastically advocate for Go, or rewrite existing tools in Go for the sake of it: they’re happy with existing tools as long as they work.Another reason I don’t really like to get involved in Go discussions is because some people have a massive hate-on for it and don’t shy away from telling everyone that Go is stupid and so is anyone using it every chance they get. It gets very boring very fast and I have better things to do than to engage with that kind of stuff, so I don’t. There’s some people like that on Lobsters as well, although it’s less than on HN or Reddit. It’s a major reason why I just stopped checking /r/programming altogether, because if the top comment of damn near every post is “lol no generics” followed by people ranting about “Retards in Go team don’t think generics are useful” (which simply isn’t true) then … yeah… Let’s not.
-
Go and Rust more or less solve the same problem
Hard disagree, rust is way more useful for actual problems like c/c++ are. I can write kernel modules in it, there is almost no way i’d want to do that with go. Having a garbage collector, or even really a runtime in go means a different use case entirely to being able to run without an os and target minis. Yes I know go can be used for that too but just due to having a GC you’re limited on how far down the horsepower wagon you can go.
I hold no views outside of that rust actually has solutions and community drive (aka people using it for that upstreaming things) for programming things like avr processors etc… I don’t hate go it just strikes me as redundant and not useful for my use cases. Kinda like if you learn python not much use for learning ruby too kind of a deal. And if I’m already using rust for low level stuff, why not high level too?
I don’t however miss debugging goroutine and channel bugs though, go is way easier to shoot yourself in a concurrent foot without realizing it. It might be ‘simple’ but that doesn’t mean its without its own tradeoffs. I can read and write in it but prefer the rust compiler telling me i’m an idiot for trying to share data across threads to goroutine debugging where two goroutines read off one channel and one of ems never gonna complete cause the other already got it. I’m sure “I’m holding it wrong” but as I get older these strict and more formal/functional languages like rust/haskell/idris/blah strike my fancy more. I”m not talking about generics really but stuff like Monads (Option/Result essentially) read to me way better than the incessant if the thing i did isn’t nil constantly. Its closer to what I’ve done in the past in C with macros etc…
Its not that I hate it though, just that the language seems a step back in helping me do things. Idris as an example though is the coolest thing I’ve used in years in that using it was like having a conversation with the compiler and relearning how to move my computation to the type system. It was impressive how concise you can make things in it.
As a recovering kernel/c hacker, you’d think go would appeal but to be honest it just seems more of the same as c with less ways of stopping me from shooting myself in the foot needlessly.
But to each their own, functional languages with types just strike me as actually doing a lot of things that OO languages from the mid 90’s always said could be done with open form polymorphism but never seemed to happen.
In 10 years we’ll see where the ball landed in the outfield so whatever.
-
Yes, hence the “more or less”. Most people aren’t writing kernel modules; they’re writing some CLI app, network service, database app, and so forth. You can do that with both languages. TinyGo can be used for microcontrollers, although I don’t know how well it works in practice – it does still have a GC and a (small) runtime (but so has e.g. C).
I don’t however miss debugging goroutine and channel bugs though, go is way easier to shoot yourself in a concurrent foot without realizing it.
Yeah, a lot of decisions are trade-offs. I’ve been intending to write a “why Go is not simple”-post or some such, which argues that while the syntax is very simple, using those simple constructs to build useful programs is a lot less simple. In another thread yesterday people were saying ‘you can learn Go in two days”, but I don’t think that’s really the case (you can only learn the syntax). On the other hand, I’ve tried to debug Rust programs and pretty much failed as I couldn’t make sense of the syntax. I never programmed much in Rust so the failure is entirely my own, but it’s a different set of trade-offs.
In the end, I think a lot just comes down to style (not everything, obviously, like your kernel modules). I used to program Ruby in a previous life, which is fairly close to Rust in design philosophy, and I like Ruby, but it’s approach is not without its problems either. I wrote something about that on HN a few weeks ago (the context being “why isn’t Ruby used more for scripting?”)
-
-
There’s just a lot of toxicity about programming languages out there, and subjectively it feels particularly bad here. Rust has a lot to like and enough to dislike (abandoned libraries, inconsistent async story, library soup, many ways to do the same thing), but something about its culture just brings out the hawkers. I still heartily recommend giving Rust a try, though you won’t be super impressed if you’ve used Haskell or Ocaml in the past.
-
-
I’ve been using Go since around the 1.0 release and Rust for the last year or so. I don’t think either of them is going away any time soon. Go has less visible advocates, but it’s definitely still used all over the place. Datadog has a huge Go repo, GitHub has been looking for Go engineers, etc.
Rust is more visible because it’s newer and fancier, but it still loses for me in multiple aspects:
- Development speed - It’s a much pickier language and is much slower to develop in, though it forces you to get things right (or at least handle every case). Rust-Analyzer is great, but still fairly slow when compared to a simpler language.
- Compilation speed - Go compiles way faster because it’s a much simpler language.
- Library support/ecosystem - Because Go has been around for quite a while, there are a wealth of libraries to use. Because Rust hasn’t been around as long, many of the libraries are not as mature and sometimes not as well maintained.
However, Rust makes a number of improvements on Go.
- Error handling - Rust’s error handling is miles above Go.
if err != nilwill haunt me to the end of my days. - Pattern matching - extremely powerful. This is an advantage Rust has, but I’m not sure how/if it would fit in to Go.
- Generics - In theory coming to Go soon… though they will be very different feature-set wise
They’re both great languages, and they have different strengths. For rock-solid systems software, I’d probably look at Rust. For web-apps and services, I’d probably look to Go first.
-
Spot on. They both have their annoyances and use cases where they shine.
-
A further difference is that Go code is hard to link with other languages due to its idiosyncratic ABI, threading and heaps. Rust fits in better. Not just in OS kernels but in mobile apps and libraries. (I’m still not a fan of Rust, though; Nim fits in well too and just feels a lot easier to use.)
-
-
-
As someone who dislikes Go quite a lot, and is really enjoying Rust: I think they are different enough they serve different use cases.
Go is much faster to learn, doesn’t require you to think about memory management or ownership (sometimes good, sometimes very very bad, Go code tends to be full of thread-safety bugs), is usually fast enough. For standard web app that is CPU-bound it’ll work just fine, without having to teach your team a vast new language scope.
On the flip side, I’m working on a LD_PRELOADed profiler that hooks malloc(), and that’s basically impossible with Go, and I also need to extract every bit of performance I can. So Rust is (mostly) great for that—in practice I need a little C too because of Reasons. More broadly, anytime you want to write an extension for another language Go is not your friend.
-
Go comes with a built-in race detector. What sources do you have for “tends to be full of thread-safety bugs”?
-
As someone with a fair bit of go experience: the race detector only works on races you can reproduce locally, as it’s too slow to run in production.
Rust stops you from doing things that can race; go gives you a flashlight to look for one after you accidentally introduce it.
-
-
-
-
-
Will be the year of Notion once their API is publicly available and integrations start to come.
Sounds depressing, I know, it’s the industry we live in.
-
I wish they just made Android widgets already.. and optimized startup time on Android more.
-
-
It’s been a while since I had a hot, new web framework to kick the tires on. Here’s hoping someone builds Rails for Rust or something like that and it completely takes over the world.
-
TypeScript will become even bigger. As JS codebases keep growing rapidly, old object oriented approaches will start to appear more on JS code bases. Teams trying to use purely functional approaches will start to appreciate the multi paradigm nature of JS.
-
Tools like Render will gain a lot of popularity.
-
Weren’t these more popular in the past, when Heroku and App Engine were new? I’m not sure why there would be a huge resurgence of PaaS, or if just the pricing of Render can start that trend again..
-
-
There will be a massive surge of interest in security tools after the recent SolarWinds attacks.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK