> Rust on the other hand is optimized for maintaining (it's right there in the name: software should be allowed to become old and "collect rust"). Rust APIs are very hard to misuse, everything is constrained and specified very explicitly. Documentation and testing live inline with your code. You know exactly what a piece of code can and can't do - you even know whether it's allowed to mutate an object you're passing it. And of course certain mistakes are impossible to make at all without (again, explicitly) dipping into unsafe { }.
A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. You could maybe make the argument that the guarantees provided by the language and compiler reduce the maintenance burden of software built in Rust, but I don't even really think that statement has been tested (via Rust being so young).
It is tiresome the frequency that legitimate language discussions for some reason turn into Rust vs. Go trash talking. It is almost certain that in 10 years, both will be used more than they are now by several x's. I think pretending you can predict what'll happen with either (and the industry) over that time is pretty silly. There will be legacy apps that people hate working with in all programming languages, and there's nothing that can save you.
My intention wasn't to trash-talk, and I admitted my bias up front. I'm just speculating, and I think that speculation is legitimate and relevant to the subject at hand.
It's my belief that whatever difficulty there is around onboarding people into Rust (setting aside the question of exactly how much of a problem that actually is or isn't) is "constant", where the difficulty of onboarding people into a legacy codebase is, shall we say, "polynomial" over time. Rust adds some constant overhead in exchange for reducing that polynomial growth, and my belief is that at some point the larger polynomials outpace it, ending up with more total difficulty for newcomers to a given legacy codebase. Of course time will tell.
This is an interesting way to look at it, but I actually think this perspective favors Go considering that there is less variety across Go projects than other ecosystems, including Rust. Of course no programming language can hold constant the business domain, but there are things like which “error handling framework”, “for loops vs iterators”, “sync vs async”, “prefer owned vs borrowed by default”, etc that apply to Rust and not to Go. And of course, Rust lets you build some gnarly abstractions which simply don’t exist in Go.
Go gives you less choice, and thus projects are more similar, and thus I suspect legacy Go code adds will be easier to maintain.
Of course this property may not endure once Go acquires generics.
It should be said that I’m a big fan of both languages, and I am especially enthusiastic about Rust in that it fits my compulsion to have code that is both very abstract and very performant.
> Go gives you less choice, and thus projects are more similar, and thus I suspect legacy Go code adds will be easier to maintain.
Side note, Go gives you less tools - but not often less choice. Eg if you need to iterate and map, you still need to iterate and map. Go didn't change your application needs simply because it inhibited your ability to execute. Instead, you do what you need despite Go. Which often amounts to repeated functions, loops of loops, functions in loops to use defers, etcetc - you reinvent wheels. Go didn't reduce the application complexity, it just gave you less tools to solve it.
While some argue less tools is easier. I argue less tools often results in poor, messy abstractions. Those are traits that fight maintenance more than ease it, in my mind.
By the end of my Go tour, i was tired and wanted off the simplicity ride. The language was a burden, to me.
Ultimately you’re expressing an anti-simplicity sentiment, which is well aligned with the parent post. Clever abstractions may appear to reduce the “burden”, but they are often fashionable and add cognitive overhead. Go does indeed often force you to do things the “dumb” way (see your own examples) but the thesis is that this is easier to understand and maintain over time.
> Ultimately you’re expressing an anti-simplicity sentiment
I disagree. First, making a language simple doesn’t make programs simpler, and often does the opposite.
I’m also not sure I buy the idea that Go is actually simple. It lacks a lot of features, but that’s not the same as being simple. I mean, it supports runtime reflection, which seems more complicated than features like traits or generics. And code using reflection is never simple.
I'm sure somebody said something like that when all those kids started to the clever abstractions that were functions instead of doing things manually in assembly.
This is just vapid snark. Of course some abstraction is helpful, but there's also a point at which abstraction impedes understanding. Ergo, we're debating where the "sweet spot" is. Note also that we can say "Go is the sweet spot for most applications" while also acknowledging that it makes certain kinds of programming difficult (e.g., writing a compiler). It's okay to recognize tradeoffs; there's no need to oversimplify or otherwise engage dogmatically.
Some developers don't want to use the ternary operator because it's "too complex".
I believe there's a middle ground to be found where further abstractions add complexity rather than reduce it. Where that middle ground is, I don't know.
That’s a strange definition of complexity. I can see people avoiding the ternary operator because the syntax is hard to read, but it’s no more complex than `if`.
Not sure what's meant by this; Rust has a standardized Result type, with dedicated syntax for early-returning errors and type checks that make sure you handle them (or at least explicitly ignore them). Go, on the other hand, has a shaky error story and from what I've heard it's a constant problem due to enforcement-by-convention.
> prefer owned vs borrowed by default
Not really sure what this means either... the owner of a value generally falls out naturally from how you're trying to use it. It's not really an either/or option. It needs to live where it will be around long enough for everything that's done with it, and everything other than the owner should get a reference to it. Maybe you're talking about passing by reference vs implementing Copy? If so, that's mostly a performance concern.
> Of course this property may not endure once Go acquires generics
Yeah- one of the few things I like about Go is that it doesn't have generics (yet). I've seen generics make TypeScript codebases impenetrable, and I think there's a decent case to be made for not having them at all.
> Not sure what's meant by this; Rust has a standardized Result type, with dedicated syntax for early-returning errors and type checks that make sure you handle them (or at least explicitly ignore them). Go, on the other hand, has a shaky error story and from what I've heard it's a constant problem due to enforcement-by-convention.
You may not like Go's convention (indeed, I don't love it although I think it works fine in practice), but the only error handling mechanism in Go is `if err != nil { ... }`. On the other hand Rust has many. This is not incompatible with your observation of "a standardized Result type". Here is a survey of the error handling landscape circa 2019: https://blog.yoshuawuyts.com/error-handling-survey/
> Not really sure what this means either... the owner of a value generally falls out naturally from how you're trying to use it. It's not really an either/or option
Or you have code which clones gratuitously out of convenience, often because some API unnecessarily asks for ownership of its arguments. Cloning is often just easier than battling the borrow checker, so in the real world with its deadlines, we tend to see a lot of clones because it's more convenient and performance is rarely a concern.
> I've seen generics make TypeScript codebases impenetrable, and I think there's a decent case to be made for not having them at all.
In fairness to TypeScript, I suspect much of this 'impenetrability' is because type annotations were added to existing JavaScript. I suspect the gratuitously complex types were already present in the original JavaScript, but the type annotations brought the pain to the surface. Similarly, I suspect TypeScript has a massive amount of developers who have only ever developed in JavaScript, many of whom are trying to shoehorn their bad JS habits into a statically typed language. You see this in other statically typed languages as well, but never on a scale that leaves a mark on the overall ecosystem.
That said, I think everyone should learn pre-generics Go if only to experience the value of an ecosystem that doesn't value egregious abstraction (again, I say this as someone who personally values egregious abstraction). And no, I don't think Java 1.0 counts (wherein people tried to shoehorn everything into implementation inheritance rather than generics).
> You may not like Go's convention (indeed, I don't love it although I think it works fine in practice), but the only error handling mechanism in Go is `if err != nil { ... }`. On the other hand Rust has many. This is not incompatible with your observation of "a standardized Result type". Here is a survey of the error handling landscape circa 2019: https://blog.yoshuawuyts.com/error-handling-survey/
By this definition, Go has many too. Go has lots of libraries to wrap error types, combine errors, preserve error data, etcetc.
Errors are one of the more similar things between Rust and Go, honestly.
> Here is a survey of the error handling landscape circa 2019
All of this is helper functions built on the same identical core that your parent was talking about.
Not that that isn't its own kind of thing, but I think that the problems are different than "standard" vs "not standard"; this problem is only possible because there is a standard, and they all interoperate well with each other.
Indeed, Rust has a very well thought-out core which enables variability (read: "complexity") of all kinds. Variability is a fine thing, but it is at odds with onboarding users from one project to another. I wasn't trying to overstate error handling in particular--I mentioned it briefly in a longer list of examples which in-aggregate affect one's ability to onboard to a new project. I also don't mean to convey that going between Rust projects is harder than in other languages on average--I don't think this is the case at all, only moreso than Go in particular.
> My intention wasn't to trash-talk, and I admitted my bias up front.
I apologize if my statement came off aggressive - I wasn't necessarily trying to say that you're shit talking specifically, just that it seems like lots of/most programming language discussions on HN devolve into some form of "Rust Good Go Bad" or "Go Good Rust Bad", which I think is usually just inflammatory.
Your prediction is 100% bias-based. There are equal (probably more) developers that would say the same thing you said, but with Go being the language that sticks and Rust being the language that's hated. The bias is the entire answer. An unbiased answer is "Who knows" and "Probably both will be loved and hated".
> Your prediction is 100% bias-based. There are equal (probably more) developers that would say the same thing you said, but with Go being the language that sticks and Rust being the language that's hated.
It actually sounds like your answer is more bias-based, because your intuition is more wrong here. There is data from the 2020 Stack Overflow survey[0] indicating a significant lead for devs who use Rust and continue to want to develop in it, vs. Go. 86.1% Rust vs. 62.3% Go.
In the context of the article, I think that can be attributed to age (go is older than rust, so trending towards the "brown field." See for example Scala, which is a little bit older, and ended up in both loved and hated lists. I'd speculate that Go will be in the same camp in 4 years or so based on polarized sentiment I've observed.
That being said, there may be something about strict/complicated languages like scala and haskell that tends to polarize developer sentiment. Rust seems like it could fall into that same pattern based on the "up front" work that it demands.
Go and Rust don’t have similar numbers of developers. My intuition is that Go has an order of magnitude more. It’s like comparing product reviews on a shopping website - 4.7 based on 20 reviews vs 4.3 based based on 200 reviews. It’s hard to say which is better. You’d have to go deeper into each of those reviews to learn if the pros and cons apply to your use case.
Another important metric, as OP pointed out, is the age of the code base these devs are working on. Rust devs are probably working on code bases they started and Go devs are maintaining someone else’s code base.
That said, I agree with the current top comment on the thread - Rust code based may prove easier to maintain when we look back 10 years from now.
> It actually sounds like your answer is more bias-based, because your intuition is more wrong here. There is data from the 2020 Stack Overflow survey[0] indicating a significant lead for devs who use Rust and continue to want to develop in it, vs. Go. 86.1% Rust vs. 62.3% Go.
That's great to hear. Unfortunately, language popularity in enterprise/production environments isn't really based around how much a developer loves or hates something.
There are more Go programs/programmers now than Rust, was the basis of my post that you're objecting to, which can be verified if you scroll up on the link you posted.
> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining.
I'm not so sure about that. (Or perhaps the definition itself needs scrutiny?) Most the languages I've seen get a reputation for being easy to learn have also subsequently earned a reputation for being a maintenance hassle: perl, ruby, python, php, javascript, etc.
Likely both. Duct tape is easy to learn, but it's not a good tool to use when building a house. Due to properties of the tool, not because it attracts bad carpenters preferring to use duct tape.
Combine both these factors and you have a real amplified problem on your hands.
Realistically, that first definition is slightly ambiguous; it may or may not mean to imply that the talk is supposed to be promotional and not derisive in order for the definition to apply. I am guessing that they probably did mean to imply that connotation, though, based on other information on the page.
I'd argue, though, that the reality is that the word's meaning is in the process of shifting from being a synonym for "promote" to being a synonym for "make out to be"; that reflects much common usage, and dictionaries always lag behind a bit in cases like this. They have to - they're a descriptive artifact, not a prescriptive one.
> It is almost certain that in 10 years, both will be used more than they are now by several x's.
That's why so many threads end up being about Rust vs. Go. They are the new(ish) languages that appear most likely to be real factors in the industry for a very long time, so they bear more discussion.
I wasn't really around for it, but I'm sure there were lots of discussions about Java vs. C++ earlier in their lifespans, for this same reason.
> I'm sure there were lots of discussions about Java vs. C++ earlier in their lifespans
Rewind to 1996. I’m at the Networld/Interop conference in Las Vegas. The steel skeleton of the Ballagio looms over desert mirages, and Java is all things to all people: a wide-open utopia to be populated by new and perfect code, a new world without concern for memory management, an abstraction from everything freeing us all from needing to know anything.
> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining.
I disagree. The things that make for good maintenance correlate with both difficulty to learn and difficulty to onboard. (The converse is not true.) Things that are easily to learn tend to be easy to start with, but end up tacking on, via frameworks or coding standards, pieces that raise both difficulty to learn and to onboard as complex projects exist.
Specifically, maintenance requires thinking like the person or people who initially created the code. The more your thinking aligns with them, the easier it is to maintain. And that act of changing to think like them is learning and onboarding.
I can learn any language in a day or two. And become proficient in it in a week.
Big part of mastering is less about knowing the language and knowing its plumbing. Quirks, unique behavior, library, tooling, etc.
Dynamism is a constant source of pain. Because it makes tooling and thus exploring language harder.
In Rust there is little such dynamism. Actual problems understanding are macros and proc macros. And finding the right Trait.
Tooling around Rust is standarized. You have cargo, rustc and they bring in the rest.
While there is some chance of Rust going nuts and adding some bizzare thing like inheritance, HKT++,
the chance that it will reach cognitive complexity of Scala or C++ is lesser.
I program in Python by day. Racket is probably the language I know best after Python, then maybe Groovy. I've had exposure to R, C, C++, D, Java, Common Lisp etc, and I find it easier to pick up new languages due to my familiarity.
While Rust has all the constructs that I'm used to from these other programming languages, I find Rust to be the most difficult one for me to learn in recent memory. The documentation is great, the book is great, the tooling with Cargo is great, but after getting through the first 15 chapters in the Book I struggled to write a program that had any sort of complexity. Sure I can add a dependency super easily to my project, but figuring out what errors everything in the library throws takes a lot of work. Sometimes I get confused about using panic!, expect, unwrap, or ? when I'm writing my own functions or interfacing with others. Swimming through the myriad of traits on different structs is confusing, and I sometimes get tripped up passing closures. And don't get me started on Macros, with great shame, they still have not clicked for me, in Lisp, or in Rust. The language just feels very different from what I'm used to, and I've never had such a hard time getting code I've written to compile correctly. I'd be totally lost without all the help from the subreddit and the book, and I appreciate everyone who has helped me.
I know this will get easier... and it has. But it will take longer for me to get comfortably with Rust then it has for other programmings languages in the same time period. This is not to say that it's a bad language. I remember one day after having debugged a Python issue that ended up being a stupid logic error on my part I exclaimed "I wish I knew a programming language that would save me from myself". I think... Or rather I hope Rust is that language in the long term for me
> The language just feels very different from what I'm used to
The reason it feels very different is... because it is very different. Then why does it feel off? Because, while it is very different, it doesn't look very different. Then why doesn't it look very different, when it is very different?
That's because, Rust developers spent conscious effort to make Rust look similar. So feeling something is off with Rust is the result of intentional design of Rust developers. In a sense this is dishonest and deceiving, but Rust without similarity engineering would be considerably less popular and hence less successful.
Rust's ambition was to change the world, not simply to discover a way to change the world and leaving actual changing to others. (Although changing the world requires discovery first.) So Rust chose to "lie".
As an example, Rust's assignment(=) looks similar, but works very different. In fact, since it is very different, it was originally written <-. It was changed to = specifically to make it look similar.
Another example is std::mem::swap. In the world of affine type system which Rust uses, swap is a primitive on an equal footing with assignment (which is actually called move). So naturally, move was written <-, and swap was written <->.
But <-> weirded people out, and people complained why Rust has so many special and strange operators. So Rust developers made it look similar to a library function. But it still is a primitive: it is impossible to implement swap yourself in safe code.
The result is that people use swap much less than they should, either because they are not aware of it, or because they think it is a specialized library function for special cases. This is significant and large cost. But it is still less than cost of looking weird. All because people won't even try languages with <->. Alas.
One of the side-effects of this is that, Reading Rust code is painful.. it is a bit like reading old perl or haskell code you haven't looked at. Especially when rust is not the day job it gets complicated/painful to remember the distinctions between "=" in say python(that's what i use most) vs "=" in rust. This is not necessarily a bad thing, but it does contribute to that previous posters' point out finding errors or bugs from libraries being used hard to find or fix. Once again, I don't care much for go, but rust is one of the languages that excite me, but trying to level up in rust(beyond the trivial tutorial code/projects) seems to need a dedicated "maker time' schedule rather than spending 30 mins- 1 hour spare time in between distractions from children.
I program in Python at my job and Rust in a hobby project. It surprised me how easy and productive actually Rust is, and I was really very sceptical initially. I know it is very subjective, and possibly a result of my longer exposure to statically typed languages, but simply Rust felt quite natural to me, while Python still feels very quirky, irregular and sometimes outright annoying, despite me spending more time with Python than Rust.
I use neither Go nor Rust and don’t have an opinion, but it’s worth pointing out that “difficult to learn” is highly contextual, e.g. Python or Ruby were probably relatively easy to learn if you already knew Perl or PHP. I found Haskell quite difficult to learn. Subsequently PureScript was very easy. Widely shared knowledge and concepts change over time and they will affect ease of adoption.
I wouldn't call Rust difficult to learn. The syntax quirks (Knowing where to put `&` etc takes time, and traits are abstract, but used all over Rust codebases). For example: Look at Python which is typically considered easy to learn. In Rust, I know that I can create a project using official tooling; specify dependencies cleanly in `Cargo.toml`; use the built-in linter, and formatter. Check the Rust docs page for any dependencies, including type signatures for all functions, and a list of struct fields. Look in the `examples` folder of a dependency's repo for code snippets.
In Python, I'm likely to find a comparative mess of sparingly-documented documented third-party tools, dependency docs, and Stack Overflow posts.
Or, look at embedded, where C is considered a simple language. In C, it's not obvious how I'd start. Use something like Cube-MX or Keil? GCC? All the options are messy and tough to learn. In Rust, I clone a template repo, cargo-install 2 or 3 tools and targets, and `cargo run` to compile and flash.
This is because you know what Rust brings you compared to what you used in the past that cause you pain.
Unfortunately, some people that have difficulty learning Rust (or hear about it) focus solely on the learning process and not what they gain by learning it.
Learning a low-level language is inherently hard because there are more at stake, it is simply more complex. For people that work where dangling pointer, data-races, is never a problem, they are learning about the problem the same time they are learning about the solution (Rust's ownership concept), and I came from that place too.
> Or, look at embedded, where C is considered a simple language. In C, it's not obvious how I'd start. Use something like Cube-MX or Keil? GCC? All the options are messy and tough to learn. In Rust, I clone a template repo, cargo-install 2 or 3 tools and targets, and `cargo run` to compile and flash.
Keil is a company that builds an IDE, compiler and debuging tools for microcontrollers. CubeMx is a configuration tool/code generator for STM microcontrollers. You comment makes no sense in regards to C language, unless you are saying that rust/cargo automagically does everything that Keil products and CubeMx do?
Wait, these 4 commands create an IDE with with JTAG debugging support, tracer and a profiler and than configure all the chip's peripherals, add low level drivers (UART, SPI, USB, FS, I2C, ETHERNET,...), setup clocking and power settings and add RTOS? I took Keil probably decades and STM years to write all that complex tooling. I'm mean it probably takes an engineer a month to bring new HW to life with the help of all those tools before they can start writing application firmware. Are you really saying 4 lines of rust tooling do the same in couple of seconds? That would be some amazing AI behind those 4 lines.
Those lines let you compile, flash, and debug. For IDE, I prefer the IntelliJ Rust plugin. Some people prefer VsCode instead. The point here is that you choose an editor suitable to the language, with the code-editing and project-management features you like.
Low level drivers are usually handled using libraries of 2 general categories: Peripheral access crates (PAC) (mostly) auto-generated from SVD files; HALs that provide an abstraction over the PAC.
A month to get started sounds... intense, depending on the project. What drove (drives?) that? Let's say I want to do a simple project using STM32. Something simple that reads sensors, has a few buttons, and outputs to a display. I'd choose parts, put together a layout in a PCB design software, and order the boards, which arrive within 2 weeks. In the meanwhile, use a dev board as required. Find a driver for the sensor, screen etc if it exists. If not, write them using the datasheet. Use a HAL to take configure clocks and peripherals, write the control flow logic (Perhaps based on interrupts). For anything the HAL doesn't support, use the Reference Manual and the PAC to set the appropriate fields.
Setting up I2C might be something like this, using a HAL:
let mut scl = gpiob.new_pin(PinNum::P6, PinMode::Alt(AltFn::Af4));
scl.output_type(OutputType::OpenDrain, &mut gpiob.regs);
let mut sda = gpiob.new_pin(PinNum::P7, PinMode::Alt(AltFn::Af4));
sda.output_type(OutputType::OpenDrain, &mut gpiob.regs);
let i2c = I2c::new(dp.I2C1, I2cDevice::One, 100_000, &clock_cfg, &mut dp.RCC);
The only thing that I did for STM32 was writing drivers for dual FLASH quad SPI external memory. Since I didn't know much about STM32 and there was no sample driver for the flash chip I was using, CubeMX helped quite a lot. It still took me a good week to get it working.
Usually when developing a new platform for our products, I/we need to bring to life: SDRAM, LCD, touch controller, external flash for code and data, SD card + FAT32, USB, ETH, plus a bunch of other components (ADC, DAC, BT, other uC, latches,...) using the usual peripherals (UART, SPI, I2C, timers,...). Keil provides a good compiler and linker, fast JTAG debugger, RTOS and a bunch of middleware libraries (some are quality, some are lacking). While I dislike its IDE for writing code, it is a lot better than VS code for debugging purposes. It also supports flashing and erasing MCUs with internal and external memory, which sometimes requires special programming algorithms.
For us stability, tooling and good library support is the most important part of doing our job. Language follows from there. C and C++ have the advantage of the GNU/Linux ecosystem of open source to draw from and they map to the hardware almost perfectly.
On higher level systems (Android, Linux) we use higher languages (with GC) which have even nicer tooling and better libraries for writing application code.
Nice. It sounds like the time sink there is writing drivers for a range of peripherals. The silver lining is next time you use that periph, it's easier.
C/C++ and Rust are both hard IMHO. D is way easier, one gets productive quite fast and there are also more advanced language features once you get proficient in it, unlike Go.
> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining.
Rust is not more "difficult to learn" or "difficult to onboard" than C++. And C++ is certainly a language with plenty of legacy, enough that you could reasonably call it "brown". Go is a rather different language that's perhaps best compared with Java as its closest "brown" counterpart.
The problem with C++ is that the various standards have encouraged changing idioms. Pre-standard, 98, 11, and 17 are significantly different when the new language features are fully leveraged. Legacy code creates inconvenient barriers when interoperating with modern stuff. Rust may be able to escape this problem.
Rust, unlike other languages I know of, has a well defined process to make breaking changes to the language. These changes are opt-in on a crate level so you don’t need to migrate an entire code base in an instant. The team also ships tools to auto fix code out there to make the migration easier.
The 2018 edition had a few small breaking changes, the 2021 edition will have none. Personally I hope the 2024 edition makes some breaking changes to make IDE development easier.
C++ is backwards compatible the same way and there was never any need to migrate your code. What happened was that c++11 brought in a major set of new features, changing the best practices of how to use the language, almost to the point of making it a new language. Mainly smart pointers, initializers, type inference, threading and lambdas, and removing tons of other small rocks in the shoe.
So that someone familiar with c++11 or newer opening up a legacy code would maybe not have a hard time understanding it but they would go "wtf is this verbose shit" and be tempted to rewrite it. Vice versa an old schooler would need to relearn these new features when opening a new code base.
I cannot write a program from scratch in Haskell. I just can't wrap my brain around it. However, every time I've needed a new feature in a program I use written in Haskell, it's been easy and a pleasure to implement.
I haven't seen anything that would indicate anything else than Go slowly declining much like Ruby has. In other words, it's still around and getting new updates, but losing mindshare.
My response was more doubting that Go is going to be used many times more than it is currently 10 years down the line, but the trend on Rust is upwards:
That doesn't mean it will ever achieve popularity, and could also go away.
However, with the Go developers' insistence on changing the language as little as possible (not good or bad, it just is), it seems unlikely that Go will see a resurgence that brings it to multiple times usage than it has now.
But, they are working toward Go2. Generics, which are the biggest talking point whenever Go is discussed, is already added in a branch and is supposed to come in a year or so. It'll be interesting to see how it'll affect the trends data after that.
Not really because the difference is that the overall trend on Rust is still upwards (it's hard to see with the two languages on the same axis). I've been investigating Rust and it looks like it's going to cure the pain points I've had around C++ on a project I'm working on and I'm quite happy with it so far.
The funny is if you use "golang" as the term it peaked at a different time (2019-2020), but then there was a very sharp drop at the beginning of this year. I wonder what the reason is?
Google is not perfect at distinguishing which queries for the word "Go" are actually about the Go programming language.
Referring to the language as golang is a secondary name, popularity driven by Google's own performance surfacing go (language) related results for the word go.
Go (programming language) has the same january drop as golang, clearer when both are viewed together:
I don't think Go actually is substantially less popular in Febuary 2021 than November 2021 (January/December, maybe due to people/student vacation time), but the google trends anomaly is not a go vs golang naming distinction.
That’s quite interesting. I’ve added Typescript and Ruby to the chart - apparently they are all declining in popularity. But I wonder, which language is the one currently rising then?
> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining.
Disagree. First, difficult to learn is not difficult to onboard. Second, unless you think Ocaml is not hard to learn, i think this is a great counterexample.
It is almost certain that in 10 years, both will be used more than they are now by several x's. I think pretending you can predict what'll happen with either (and the industry) over that time is pretty silly.
I think the "difficult to learn" and "difficult to onboard" is important to keeping rust a "Most Loved Programming Language". If only those who make it through the "difficult to onboard" phase use the language extensively, then only they will be responding to the "most loved"/"most dreaded" question.
I taught a university seminar that looked at rust and another emerging language a couple of years ago and only 2 students out of 30 said they would use rust again after the class. So the rest will never get a chance to answer the survey question about rust.
> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining
PL learnability alone is not significant as a factor for a PL to be chosen for a certain task, unless it is impossibly hard. Rust, looking at the growing community, is not a PL that is impossibly hard to learn.
A PL is chosen for a certain task for its features. The same as any other class of tool, "A is chosen for X because of A's feature".
The learning curve is simply the side-effect of the PL's minimum features need to be learnt for it to work. Rust being a low-level language + an extra layer of protection is inherently hard.
But let's see how it fares in 10 years. There have been successful projects built on Rust, firecracker, figma, discord, and many more, despite it being so young.
> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining.
I think this presumes that you have to teach people the language. But most maintenance programming is done by hiring people already familiar with the language the existing codebase is written in, and then bringing them on to work on the existing project.
Rust isn’t hard to onboard for an individual project, in the same way that a macro-laden Lisp codebase is. Once you know Rust, you know Rust. It takes more effort to “know Rust” because you have to learn all the ecosystem stuff expected of someone who “knows Rust”; but from the perspective of an employer, you can just hire “someone who knows Rust”, and they’ll come with all that knowledge.
And, in fact, an experienced Rust dev may be able to start work on a novel-to-them existing Rust project, a lot faster than (for example) an experienced C dev would on a novel-to-them existing C project, as a large stdlib / conventional ecosystem of foundational libraries (as in the case of Rust) tends to translate well to experienced developers coming into a codebase and quickly recalling everything, because it’s a bunch of the same batteries/libraries they’ve already used in the past.
The difference between a design pattern and a language feature, is that you can recall language features, while you have to recognize design patterns (i.e. grok the code in order to identify what pattern(s) it’s trying to reify.) Languages with more formalisms (either built into the language, or in common use in the ecosystem) increase the amount of recall that new maintenance programmers can do (or rather, decrease the amount of recognizing they have to do to get up-to-speed), and thus make switching a maintenance programmer between codebases “cheaper.”
—————
I bring this up not from the perspective of a Rust programmer, but from the perspective of an Erlang programmer... who also doesn’t like Go very much (though I do write quite a lot of Go! As a maintenance programmer!)
IMHO Erlang and Go aren’t all that fundamentally different runtime-wise. Presuming you’re using them for the same thing — writing highly-concurrent, fault-tolerant network servers — the main difference between the experiences of coding in Go and in Erlang, comes down to the fact that Go provides you with a bunch of concurrency primitives that you have to put together as design patterns — and where maintenance programmers then have to recognize those patterns; while Erlang actually has universal concurrency formalisms that everyone takes advantage of, and so those formalisms can simply be recalled on new projects.
I advise anyone who thinks that “recognizing design patterns” is a cheap-and-easy thing to do, to tell me what’s going on in this file: https://github.com/ethereum/go-ethereum/blob/master/eth/down... . I’ve stared at this code on-and-off for two years, and I still don’t have a mental model for it. If this code was made out of cleanly-separated named/opaque formalisms, rather than fifty design-patterns tied into a knot, I can’t even imagine how much more productive I would have been working on it.
> A language that is touted as "difficult to learn" and "difficult to onboard"
Does anyone know if there have been studies about how long it takes to learn different programming languages? I hypothesize that it would take a beginner programmer longer to learn Rust than C, but probably a similar amount of time as learning C++ (which I think is the closest “traditional” programming language to Rust).
A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. You could maybe make the argument that the guarantees provided by the language and compiler reduce the maintenance burden of software built in Rust, but I don't even really think that statement has been tested (via Rust being so young).
It is tiresome the frequency that legitimate language discussions for some reason turn into Rust vs. Go trash talking. It is almost certain that in 10 years, both will be used more than they are now by several x's. I think pretending you can predict what'll happen with either (and the industry) over that time is pretty silly. There will be legacy apps that people hate working with in all programming languages, and there's nothing that can save you.