24 ms·

I think there's a lot of truth to this, but I'm going to make an additional suggestion that I'll readily admit is biased by my own feelings: I think Go is in a

I think there's a lot of truth to this, but I'm going to make an additional suggestion that I'll readily admit is biased by my own feelings: I think Go is in a honeymoon phase and people will hate it in 10 years; I think Rust will continue to be liked even when it's a legacy language (perhaps no language can continue being loved once it becomes "brown", but I think Rust will be a lot less dreaded than others). Go, like Ruby (mentioned at the end of the article), is optimized for building. You can do things quickly and easily with minimal ceremony. Some people love that. But that's exactly the trait that's starting to weigh on Ruby, and it's exactly the trait that has put PHP and Perl in the "dread" category over time (remember when people were in love with those?). 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 { }. This kind of forethought is what makes a language that survives the honeymoon phase.

foolfoolz 6y ago
this sounds entirely like personal preference based on the projects you’ve worked with. all languages are capable of producing maintainable software. it’s much more about the authors skill than the language itself. yes statically typed languages scale better, but ide support on dynamic languages is still good. i don’t buy the “rust solves all problems” idea. that is the hype curve
- tpm 6y ago
  For projects with a large number of contributors and long development time there will inevitably be some less maintainable code and that is where the quality of the language itself will become important. No language solves all problems obviously, but clearly some are better than others in nthat regard. I have no experience in Rust but many years with Perl and Java (and others). Perl in the hands of a small, very experienced team had the highest productivity and quality I have seen - but I would not want use Perl in a project with higher developer churn and lots of inexperienced coders.
  - athenot 6y ago
    > Perl in the hands of a small, very experienced team had the highest productivity and quality I have seen - but I would not want use Perl in a project with higher developer churn and lots of inexperienced coders. This has been my experience as well. I think that's why "medium powered" languages such as Python and Java tend to get the widest adoption over time. They are less expressive but also have fewer gotchas, and in a team of 100s or 1000s of good-but-not-stellar developers who come and go, they end up being the least painful for the organization.
- citrin_ru 6y ago
  I agree that it is possible to write maintainable code in any language and it is possible to make a mess in any language too. But some languages to some extent trying to force this, which may move an average project, even if only a little, to more maintainable shape. Examples of such languages are Go and Python: both to some extent enforce code formatting - Python with indentation being part of the syntax, Go with gofmt being almost universally used tool. Both try to maintain one preferred way to do things - opposite to "There's more than one way to do it" in Perl.
- oblio 6y ago
  In discussions about programming languages, you have to always remember to add "equally"/"to the same degree" to statements such as this one: > all languages are capable of producing maintainable software Once you add that, you understand what the original poster actually meant.
titzer 6y ago
I predict exactly the opposite. Baking ownership into the type system makes API design and refactoring hard, while having GC makes memory management entirely orthogonal and easy to change. Go is already over 10 years old and designed by people who have worked on software for 30, sometimes 40, years. Go changes slowly and Rust is still evolving.
- guscost 6y ago
  If your opinion is as simple as “Go will be more better than Rust”, or the opposite, it is far too simple to be correct. Rust is unbeatable for services you want to deploy, stabilize, and forget about forever. Go is pretty darn good for building out complicated/messy services in an iterative process.
  - throwaway09223 6y ago
    Go is the optimal language for a company that wants one (or more) microservice per engineer. It's a great language for padding out bulletpoints for a promo packet.
  - dnautics 6y ago
    > Rust is unbeatable for services you want to deploy, stabilize, and forget about forever. Erlang.
    - guscost 6y ago
      More expensive, and not always necessary. But great point.
      - dnautics 6y ago
        You will never have a stabilized system unless you are multinode. Hardware will fail. Rust is not good at this.
- gpm 6y ago
  > and refactoring hard The opposite, it makes refactoring really easy, because it's so hard to screw up mechanical changes. The memory management aspect of refactoring is slightly more tedius in rust (compared to go), because you have to update lifetime annotations sometimes. This is a mechanical process and not hard. The trade off is that the existence of lifetimes and ownerships means that many of the rest of refactoring tasks (getting locks right, not introducing data races, making sure you're not doing something dumb like accessing a freed fd, etc) are much simpler. Rust is also better than go at refactoring because go's ducktyping (and reflection) means that there is frequently action at a distance that is hard to track down. Changing the name of a field of a struct can change behavior in another file that never mentions the field by name. Go is in the middle of adding generics to the language, I don't think Rust has made a change of that magnitude since it hit 1.0...
bradleyjg 6y ago
I don’t know that people love ada and it was designed with the same goals in mind.
void_mint 6y ago
> 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.
- sanderjd 6y ago
  > 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.
  - ehvatum 6y ago
    > 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.
Laremere 6y ago
It seems reasonable to argue the exact opposite: (edit: for clarification, I think this argument is roughly equal in strength to the parent. My bias is definitely showing, but my main point is that knowing which will be true is hard.) Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans. It mostly remixes what has proven to work into a cohesive package. It's only as large as it absolutely needs to be (so new devs can learn it quickly), and has a strong focus on developer UX (gofmt, build speed, godoc). Rust on the other hand is a far more ambitious language. It's trying to statically solve many types of problems which are typically solved through testing and experience. Using Rust productively requires much more Rust specific learning. With how Rust is changing and having multiple approaches to things as the language is defined, long living code bases are going to accrue different methodologies from whatever was popular when each component was written. I think in 10 years a few experienced devs will do to Rust what Go did to C: Take the bits that obviously worked well, add a few ideas from other languages to soften some rough corners, and present it is a smaller, easy to use package. Though I also in general hope old languages are being replaced by new languages, as that must happen if as an industry we are getting better at building software. But also because I'm making a programming language and I have to believe I've found room for improvement for that to be a good idea.
- gameswithgo 6y ago
  >Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans. So have all languages, with wildly different philosophies about how to do that. We collectively just don't have any idea what we are doing. Clearly nobody has stumbled on a big win or one particular language would start dominating the industry due to the productivity bump.
  - deleted 6y ago
    [deleted]
  - BobbyJo 6y ago
    >So have all languages, with wildly different philosophies about how to do that. I think what you refer to as differing philosophies are in fact differing goals, and the goal of Golang is very different from pretty much all other modern languages: simplicity. I think boiling everything down to 'they are all trying to do it better' misses the fact that the 'it' they are trying to do better is very different in some cases.
nemo1618 6y ago
I think you have this backwards. Go is explicitly optimized for software engineering; in fact, it's the only language I'm aware of that makes large-scale engineering its north star. Here's Rob Pike discussing how Go's design decisions make building and maintaining large programs easier: https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article (AFAICT, Rust was not named after "collecting Rust," and long-term maintenance is not one of its primary design goals.) As an example, one celebrated feature of Go is that "all Go programs looks familiar," i.e. it's easier to get oriented in an unfamiliar Go codebase than just about any other mainstream language. Partly this is due to `gofmt`, but also the fact that the language itself is relatively spartan, with few dark corners. It's an "unsophisticated" language, which obviously cuts both ways. Rust, by comparison, is a highly complex language. It allows for very powerful abstractions -- as well as very bespoke and "clever" constructs. I think Rust will develop a solid reputation for correctness, much like Haskell; Rust programs will run for many years without bugs or performance issues. But, again like Haskell, Rust will also have a reputation for allowing clever programmers to write too-clever code. That's why Go will prove to be the more maintainable language: because it intentionally limits expressiveness (a highly unpopular decision, unsurprisingly) and thereby limits the amount of "damage" any given programmer can do.
- alricb 6y ago
  Eiffel might be another.
  - nemo1618 6y ago
    I don't know much about Eiffel; do you know of any articles or talks that discuss its design tradeoffs?
    - Jtsummers 6y ago
      Eiffel's bigger contributions are probably: Design-by-contract. The contracts aren't just comments, they aren't haphazardly enforced by adding asserts to the code. They're explicit parts of the language which allows for a lot of interesting consequences when utilized. Testing can be semi-automated directly from the code, some elements of the program design can be proved to be satisfied statically without the need for compilation and execution. The ability to encode your specification into the language is incredibly useful. Command-query separation. If methods return a value (queries) they should be referentially transparent, having no side effects. This is a principle so not an explicit language feature, but it can be enforced using DbC.
13415 6y ago
I'm going to be the heretic and predict the opposite about Go and Rust. The reason is that Rust is overengineered, allows for macros, and is getting more and more complicated all the time. It's going to be as complicated as C++ in 10 years from now. Go is kept simple, the team is reluctant to introduce large changes, and it was from the beginning planned as an "easier C" with automatic memory management. I'd also like to challenge the idea that Rust is optimized for maintaining. It's optimized for backwards compatibility. IMHO Ada is way better for long-term maintainability and in that respect beats every other language I know.
- brundolf 6y ago
  That's actually a great point about macros. I have extremely mixed feelings about Rust's macros, but one of those feelings is that if anything is going to compromise its status as "the maintainable language" down the line, macros are the most likely.
  - 13415 6y ago
    That's also my impression about CommonLisp, which I otherwise like a lot. Macros are really handy but in the long run they force new programmers to learn DSLs forever. The same for templates, of course. They increase programmer comfort but decrease long-term maintainability. It's always a trade-off.
    - jcelerier 6y ago
      > in the long run they force new programmers to learn DSLs forever. but... that's a good thing. programs should be built as a collection of small DSLs tailored to the specific tasks of that program
- zozbot234 6y ago
  You think macros are overly complicated? Have you looked at how people use C++ templates?
  - 6y ago
hnlmorg 6y ago
I've lost count of the number of times people have said that about a new language that has since fallen out of favour.
benreesman 6y ago
There was this wonderful 6-8 year period after every thread on programming stopped being dominated by Ruby advocacy and before it started up with Rust. Why cram a Rust advocacy soundbite into a thread about maintenance vs. prototyping?
- mohanmcgeek 6y ago
  Coincidentally it's all those Ruby people who are high profile Rust people.
potta_coffee 6y ago
It doesn't seem to me that Rust and Go are really trying to solve the same problems and they don't appeal to the same demographic. The Rust vs Go conversation is tired and pretty much pointless, and I've avoided Rust simply because of the Rust community, which emanates a vibe that turns me off. I think the weight of software that is written in Go means it's going to be around a while (K8s / Docker / Terraform / etc) and I hope it stays because it feels like a breath of fresh air to me and I enjoy working with it.
- mohanmcgeek 6y ago
  Yes. The Rust users seem to be spending all their time making Rust vs Go posts on the internet instead of making something killer enough to get people to use Rust.
tinco 6y ago
When Ruby was "hot", it was bringing a lot of new things to the table, things new developers take for granted now. If you start a new project in typescript, or even C#, you'll get almost all of the things that made Ruby great in 2006. When I introduce a new developer to Ruby, all I've got to argue in favour of it is that it's a beautifully designed and powerfully expressive language with a library ecosystem chock full of de-facto standardised gems. Relatively vague things, and any newbie can hit me back with its downsides: mediocre performance, no type definitions, and no evented I/O baked into the language. I do dread the day that I can't start a new project in Ruby, simply because my hiring pool would turn into a mire of people dreading to work on it.
- reedjosh 6y ago
  > mediocre performance, no type definitions, and no evented I/O baked into the language Ruby 3 addresses each of those issues. https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/ https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-rele...
  - tinco 6y ago
    Definitely interesting new features, and Ruby is putting up a good fight. But if it was really a ruby feature, and not just something tacked on to stay relevant, that code example would've looked like this: require 'async' require 'net/http' require 'uri' ["ruby", "rails", "async"].each.parallel do |topic| Net::HTTP.get(URI "https://www.google.com/search?q=#{topic}") end I can't tell someone Ruby is beautiful, and then in the next sentence explain how you need to type Async twice just to get something to run asynchronously. Same of course for Ruby types, we're just not yet on the point for a truly new way of writing Ruby for Ruby 3. Maybe we'll finally get something like this could be in Ruby 4, but I fear the spectre of backwards incompatibility is going to stand in the way of something that's both truly Ruby and truly in the 2020's.
    - d3nj4l 6y ago
      Amen. As a massive ruby fan, I couldn’t put a finger on why I disliked ruby async, but you’ve got it exactly right.
JulianMorrison 6y ago
Go thinks that having a simple language, one way to do a thing, standard formatting, low boilerplate, and coupling minimised using interfaces and explicit exports all adds up to maintainability. Time will tell if it's right.
- stouset 6y ago
  Two of those in particular are what the overwhelming majority of detractors find issue with. A “simple” language frequently offloads more work onto its users. In my experience with golang, this is true. Meaningful abstraction is punished or impossible, so every solution to every problem—no matter how many times it’s been solved before—becomes a computer science exercise where every detail has to be dealt with and remains on full display. Reading golang is a chore because you can’t zoom out and look at the high-level flow, it’s only low-level minutiae at every level of the code. It’d be like an architect having to write the molecular layout of a skyscraper into the blueprints. Chemical formulae everywhere but no picture of walls, floors, or a building anywhere to be found. Second, claiming golang has “low boilerplate” is the programming language equivalent of Stockholm syndrome. Look up any popular project. Something like fifty percent is if res, err := func(…); err != nil { return nil, fmt.Errorf(“Look ma, I’m a human exception handler: %w”, err) } That’s not an exaggeration. 50% seems to be the trend from the projects I’ve sampled. It actually makes it frustratingly difficult to follow what a function is supposed to do because the logic is lost in a sea of nearly-identical error handling. Spotting a bug in one stanza of code that’s in a sequence of nearly-identical visual blocks is hard because your brain starts glossing over the details that are repeated.
  - Seb-C 6y ago
    I wish there was a standard one-liner pattern to handle errors, that would improve it a bit visually. Go has a LOT of boilerplate. And that is why I love it. No magic. No implicit behavior. No weird stuff that will bite me if I don't know that something in a completely unrelated file is changing the behavior of my code. It allows me to write high quality code and care about all the millions of details I should be thinking about. Yes, 50% of go code is about handling specific cases and errors. And that's a good thing, because unexpected cases and error handling is 50% of the work that a developer should be doing. But often it is just neglected or difficult to spot in other languages (until it bites you).
coldtea 6y ago
>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"). I think the name Rust is rather a pun because it was designed to be "close to the metal".
- brundolf 6y ago
  It's had various adjacent meanings over the years (and I may have embellished a little bit in my original interpretation), but here's one explanation which isn't far off: https://tim.dreamwidth.org/1784423.html https://tim.dreamwidth.org/1784423.html > Also, calling Rust a research language is funny to me because -- as its name reflects -- we've tried hard to avoid incorporating new technology into it. We haven't always succeeded at failing to be novel, but we have a rule of thumb of not including any ideas in the language that are new as of the past ten years of programming language research. The field of programming language is full of old technology that hasn't been put to use in solving problems that it's exactly suited for. The goals with Rust were to avoid reinventing wheels, and see what the past had to teach us.
pojntfx 6y ago
I have to disagree with this. I'd even argue that the direct opposite is the case: Go is so conservative in it's decisions, it's hard to find a project from years ago which doesn't "just work" with `go run`. The syntax and semantics are very simple and tend not to change much/haven't really changed since the initial release, which is definitely not the case with Rust, where stuff moves really quickly (not a bad thing by definition, but IMHO not the best for maintaining an already existing project)
- srparish 6y ago
  > it's hard to find a project from years ago which doesn't "just work" with `go run` That's not been my experience. On a team I was on, even code from six months prior would sometimes be difficult to compile. They keep changing how GOPRIVATE works, or how modules work, or how vendoring works with modules.
- carols10cents 6y ago
  Rust takes backwards compatibility very seriously; if you ever come across a Rust project that doesn't build with the latest compiler, please file a bug.
kardianos 6y ago
Go is great for maintenance. It's actually annoying sometimes to build.
emodendroket 6y ago
I feel the opposite way about Go. Reading other people's code is relatively easy but the tedium of writing it can be draining.
bakatubas 6y ago
I think that is true regarding language popularity—but not their viability for intended purpose. Perl is a great example because although it has its quirks and the ecosystem shows some age, there really isn’t anything like Perl. It is a very good language for interacting in the console and with data of many types. It’s $_ variable which is based on implied context (much like in language we short-form speech when context is implied). Those are features something like rust (or go) simply isn’t designed for. Hell, people still use and enjoy programming in C or Basic or Pascal. They just aren’t “popular” because developers are eager to put their comp-sci to use and invent more languages :)
megameter 6y ago
I can confidently predict that both Go and Rust will be seen as the "old brown stuff" in not so many years and some hot new thing will have come along that everyone wants to build in. Rust's main claim to fame - safe manual memory - is already being re-examined. There is definitely interest in and pursuit of a lower-boilerplate means of getting the same, and there are some candidates out there already. Further, a language being successfully used by experts and popularized tends to precede an accumulation of low quality contributions that negate base improvements to maintenance. In due course, a popular Rust will become "enterprised" with an accretion of tooling and frameworks - although it might not look the same as "enterprise Java", it will have the same kinds of effects in creating barriers to entry and sucking the sense of "fun" out of the day-to-day workflow. Lastly, the application categories will change. There will be demand for "glue" again, applications that are just frontends to library code(perhaps code written in Go or Rust). The new language will be something not systems-focused, and perhaps aim to be mostly focused on content and presentation (as HTML was in inception).
- aw1621107 6y ago
  > There is definitely interest in and pursuit of a lower-boilerplate means of getting the same, and there are some candidates out there already. What are some of those candidates?
obviouslynotme 6y ago
Rust doesn't add anything that increases maintainability beyond memory safety. This is nice, but it's not even 1% of what maintenance work looks like. Maintaining a decades old code base means adding features without blowing up the beast. This involves: (1) digging through the code to find the area that does something close to the new feature, (2) trying to understand what is going on, (3) figuring out the style of it for conformity, and (4) slapping that bad boy in. Of these, (4) is by far the easiest part and the only one Rust will help you in. The digging for understanding is far more time consuming. The other parts require art, discipline, and linters.
- dnautics 6y ago
  Yes, for example this week I had to uncover a bug why a backend was occasionally delivering duplicated database rows to a frontend, in code I hadn't written. I couldn't replicate the problem in test, or in dev, it was only in prod and stage (because the data in stage and prod was the right shape to trigger a UB wontfix in the postgres query optimizer). Rust would not be friendly towards producing a RCA on this issue.
xh-dude 6y ago
I don’t know, of course, but I have a different sense of where Go will be if it survives generics. The lack of change will mean it’s reliable, it was never as pretty as some other things, and it doesn’t go too far out of its niche. A lot of languages that suffer past the honeymoon, it isn’t survival of the fittest, it’s just evolving bloat or ending up with vestigial organs - this is hard to get on board with for new developers.
geodel 6y ago
> I think Go is in a honeymoon phase and people will hate it in 10 years; .. I wrote some Go code for talking LDAPs and doing some CRUD Ops. Do I love this code? Nope. Do I love the product that I built? Very Much. I think love of language is somehow very much a Rust thing at least compared to Go. > Rust on the other hand is optimized for maintaining This seems to be a tall claim. So often in Rust some or other library, web framework goes defunct or abandoned. And they are not exactly in finished state so no maintenance is required. Same thing happens with other languages too. But Rust is quite young, even then we have abandoned projects. In 10 years I am not sure how Rust codebases will be more maintained not less. Now one can say maintenance point is about commercial projects where people are paid to maintain. Still then not sure how loved it would be by maintainers when original developers are long gone.
eternalban 6y ago
That's some honeymoon! The wife is gonna be mad at me for taking the moon bit literally. It's been more than a decade now for Go. What honeymoon is this? When I first saw Rust 1.0 spec, I made a mental note that "this will end in tears". (Do tears rust metal?) I made a similar prediction during Scala's honeymoon days: "This will be the JVM's C++". Go will have a Java-lite career trajectory: it has a pretty wide sweet spot (in various dimensions) that more than compensate for its shortcomings. The actual issue in this industry has been, and remains, the fact that it requires workers with above average intelligence that are tasked with building repetitive glorified book keeping applications. And in every programmer with a heart-beat's career, there comes a time when job boredom unconsciously lends a seductive glimmer to the shiny new thing. Java, Ruby, and Go all were in fact adopted because of the ambitious, smart, but bored, geeks decided they needed a brand new toy. (So taking your honeymoon metaphor, these trends are like mid-life crisis for programmers.) And, compounding the issue is the fact that those minding the programmers were and remain (in the best cases) mostly behind the curve -- they're in meetings all day, after all -- and are simply not in a position to authoritatively smack down "let's use X!" enthusiasms. (In the general case, they are entirely clueless.) Rust, like Scala, and Haskell, add an additional hook in that they offer the programming world's version of 'intellectual virtue signaling'. Case in point being your bon mot of "optimized for building". Seriously, that's the actual job description for 99% of worker bees in this field: building things! So, I'll make the prediction that Rust will go the way of Scala and Haskell, and there will come a brand new shiny and intellectually satisfying new thing and we'll have HN (in a typically forgetful fashion) dissing Rust and heaping praise on the new comer. This too shall pass. [p.s. I have a self-contract to only post 1 message in a 24 hour period on the entire internet and this was it for tonight. /over & out]
- mohanmcgeek 6y ago
  > And, compounding the issue is the fact that those minding the programmers were and remain (in the best cases) mostly behind the curve -- they're in meetings all day, after all -- and are simply not in a position to authoritatively smack down "let's use X!" enthusiasms. (In the general case, they are entirely clueless.) I don't think them smacking the "let's use x" is a good idea since it's the Devs who'll be writing the code. The org needs a framework that answers: 1. How easy is it to train someone to use this stack? How long would it take for someone to start writing good code 2. How much time would it save us when building something new? 3. How easy is it for someone completely new to the codebase to start contributing? 1 and 2 can be easily measured within the org You can use OSS as a proxy for 3
bch 6y ago
> it's right there in the name: software should be allowed to become old and "collect rust" Of course, names or intentions of things don’t really determine their quality, or we’d all be running our software on the alpha processor, namely the DEC Alpha. My pedantic comment is worth about as much, but might be interesting to some: Rust isn’t named after iron oxide, it’s named after fungus[0][1][2]. [0] https://stackoverflow.com/questions/16494822/why-is-it-called-rust#16503989 https://stackoverflow.com/questions/16494822/why-is-it-calle... [1] https://en.wikipedia.org/wiki/Rust_(fungus) https://en.wikipedia.org/wiki/Rust_(fungus) [2] https://www.reddit.com/r/rust/comments/27jvdt/internet_archaeology_the_definitive_endall_source/ https://www.reddit.com/r/rust/comments/27jvdt/internet_archa...
_james_33_22__ 6y ago
Oh my, here we go again: The first post on a general language thread is bashing Go and hyping Rust ... that in itself is a very sad and problematic story as some inexperienced devs fall into the trap of this kind of promotion that Rust is the silver bullet for all kind of applications / projects. Rust has it's place. Go has it's place. Java has it's place. There's so much more than pure language feature for successful projects. The language is not even in the top 3. But more importantly I disagree to your actual assessment: Go code is very easy to read and understand. You're at the core of the problem at hand at once. No over abstractions or complex syntax or complex language features. Go has very few quirks (every language has them, people thinking "their" language is free of them are just being ignorant). I found very few real world issues caused by language quirks in Go production code (just as with Java or .NET). Much more important for quality code are engineering decisions, structure and processes. As Go is easy to write, read and understand it leaves more mental capacity to those often underrated areas. Go is a memory managed language. That alone makes it much easier to understand and maintain than every other language where you need to do it yourself. Again, more room for engineering decisions. As Go has a very large and extremely useful standard lib you have much less issues with unmaintained third party libs. Imaging a large Rust codebase and all it's dependencies to one-person-maintained libs. A maintenance nightmare thinking 10 years ahead. Just look at some good quality Go code, e.g. Hugo https://github.com/gohugoio/hugo/blob/master/navigation/menu.go https://github.com/gohugoio/hugo/blob/master/navigation/menu... I've picked an arbitrary file. There might be issues in it, but look how easy to read and understand it is. Regarding Rust: I have no general interest in talking bad about it, but need to make a point. Just as a real world reminder think of the Actix story. One part is the unsafe issue. How many people in the world would be able to understand the actual code and could have cleaned it up? Maybe 50? Fortunately there was a happy end. But how much time and energy did it take to get it on track again? What if Actix had not been the most popular and known framework? All our companies Go servers (still mostly Java apps) are build with the standard lib. One thing less to worry about in the long run.
fonzi_3311 6y ago
>> I think Go is in a honeymoon phase and people will hate it in 10 years; >> Rust on the other hand is optimized for maintaining How come this post isn't flagged? Crazy ... How can someone more aggressively start a language flame war? These kind of posts of an individual are the reason for the bad reputation of the Rust community. Looking at the facts regarding the industrial usage and growth of Go and Rust in the real world one can only conclude that Go's honeymoon hasn't started yet. There are so many reason why Go is much more likely to be maintainable 10 years from now: - easier language - massive standard lib - professional maintainers at google - garbage collector - much, much more devs available - very sensible maintainers to keep Go stable - much more mature despite being not that much older - ...
zibzab 6y ago
> Rust on the other hand is optimized for maintaining I completely DISAGREE with this statement! I have already seen many year-old Rust projects fail to build due to changes to language, compiler and core libraries.
- aw1621107 6y ago
  Out of curiosity, would you be able to provide concrete examples of those build failures?
  - zibzab 6y ago
    Just try random project from github without using nightly, alternatively try a project from 2018 with a current rustc. Specially the debian/Ubuntu Rust packages have hard time compiling many recent projects.
    - steveklabnik 6y ago
      These two issues sound totally different, a 2018 project that doesn’t use nightly should absolutely compile today, unless there was a soundness issue. (And the vast majority of projects don’t use nightly features.) The latter bit is the opposite, that is, old compilers can’t possibly know about new features, and that’s not a compatibility issue. That’s an older tool chain issue, or maybe a “community prefers newer tool chains than distros do” issue.
      - zibzab 6y ago
        But how in gods name can you call a language "maintainable" if just compiling it after certain time requires some detective work to find the right rustc/cargo versions? And that's only the first problem with maintaining old Rust projects. There are so many other issues, specially with projects created in very early Rust days. Tell me, have you ever seen a go project failing due to similar issues? Python had this problem once (2 to 3) and they are still apologising for it. (Not trying to start a language flame war. I like Rust and want it to succeed. But right now things are a bit chaotic)
mohanmcgeek 6y ago
Go was in the honeymoon phase between 2013-2016. Considering how much unnecessary attention Rust gets in this forum despite being a terrible language to learn would suggest that Rust is the language currently in the honeymoon phase. It's Rust that carries Ruby's and Scala's legacy of putting everything into the language. There's no forethought if it's a kitchen sink
- pkolaczk 6y ago
  I don't know about Ruby, but saying Scala and Rust put everything into the language is just totally incorrect. Both are designed with philosophy of building minimal set of features with very strong expressivity. For example Scala 3 removed a lot from the language and unified many features. As for Rust. Is there inheritance in Rust? No. Overloading? No. Global or static (like Java static) variables? No. GC? No. Exceptions as the main error handling feature? No. N ways of casting to a different type? No. 5 or 6 ways of building dataclasses like in Python? No. 20 ways of packaging / building a project? Again - nope. I think this is already enough to say they didn't put everything into the language, and they are actually very careful not to introduce unnecessary features. Actually I find Rust quite small, compared to e.g. Java or C++, but it has much better expressivity.

foolfoolz 6y ago

this sounds entirely like personal preference based on the projects you’ve worked with. all languages are capable of producing maintainable software. it’s much more about the authors skill than the language itself. yes statically typed languages scale better, but ide support on dynamic languages is still good. i don’t buy the “rust solves all problems” idea. that is the hype curve

tpm 6y ago
For projects with a large number of contributors and long development time there will inevitably be some less maintainable code and that is where the quality of the language itself will become important. No language solves all problems obviously, but clearly some are better than others in nthat regard. I have no experience in Rust but many years with Perl and Java (and others). Perl in the hands of a small, very experienced team had the highest productivity and quality I have seen - but I would not want use Perl in a project with higher developer churn and lots of inexperienced coders.
- athenot 6y ago
  > Perl in the hands of a small, very experienced team had the highest productivity and quality I have seen - but I would not want use Perl in a project with higher developer churn and lots of inexperienced coders. This has been my experience as well. I think that's why "medium powered" languages such as Python and Java tend to get the widest adoption over time. They are less expressive but also have fewer gotchas, and in a team of 100s or 1000s of good-but-not-stellar developers who come and go, they end up being the least painful for the organization.
citrin_ru 6y ago
I agree that it is possible to write maintainable code in any language and it is possible to make a mess in any language too. But some languages to some extent trying to force this, which may move an average project, even if only a little, to more maintainable shape. Examples of such languages are Go and Python: both to some extent enforce code formatting - Python with indentation being part of the syntax, Go with gofmt being almost universally used tool. Both try to maintain one preferred way to do things - opposite to "There's more than one way to do it" in Perl.
oblio 6y ago
In discussions about programming languages, you have to always remember to add "equally"/"to the same degree" to statements such as this one: > all languages are capable of producing maintainable software Once you add that, you understand what the original poster actually meant.

titzer 6y ago

I predict exactly the opposite. Baking ownership into the type system makes API design and refactoring hard, while having GC makes memory management entirely orthogonal and easy to change. Go is already over 10 years old and designed by people who have worked on software for 30, sometimes 40, years. Go changes slowly and Rust is still evolving.

guscost 6y ago
If your opinion is as simple as “Go will be more better than Rust”, or the opposite, it is far too simple to be correct. Rust is unbeatable for services you want to deploy, stabilize, and forget about forever. Go is pretty darn good for building out complicated/messy services in an iterative process.
- throwaway09223 6y ago
  Go is the optimal language for a company that wants one (or more) microservice per engineer. It's a great language for padding out bulletpoints for a promo packet.
- dnautics 6y ago
  > Rust is unbeatable for services you want to deploy, stabilize, and forget about forever. Erlang.
  - guscost 6y ago
    More expensive, and not always necessary. But great point.
    - dnautics 6y ago
      You will never have a stabilized system unless you are multinode. Hardware will fail. Rust is not good at this.
gpm 6y ago
> and refactoring hard The opposite, it makes refactoring really easy, because it's so hard to screw up mechanical changes. The memory management aspect of refactoring is slightly more tedius in rust (compared to go), because you have to update lifetime annotations sometimes. This is a mechanical process and not hard. The trade off is that the existence of lifetimes and ownerships means that many of the rest of refactoring tasks (getting locks right, not introducing data races, making sure you're not doing something dumb like accessing a freed fd, etc) are much simpler. Rust is also better than go at refactoring because go's ducktyping (and reflection) means that there is frequently action at a distance that is hard to track down. Changing the name of a field of a struct can change behavior in another file that never mentions the field by name. Go is in the middle of adding generics to the language, I don't think Rust has made a change of that magnitude since it hit 1.0...

bradleyjg 6y ago

I don’t know that people love ada and it was designed with the same goals in mind.

void_mint 6y ago

> 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.

sanderjd 6y ago
> 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.
- ehvatum 6y ago
  > 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.

Laremere 6y ago

It seems reasonable to argue the exact opposite: (edit: for clarification, I think this argument is roughly equal in strength to the parent. My bias is definitely showing, but my main point is that knowing which will be true is hard.) Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans. It mostly remixes what has proven to work into a cohesive package. It's only as large as it absolutely needs to be (so new devs can learn it quickly), and has a strong focus on developer UX (gofmt, build speed, godoc). Rust on the other hand is a far more ambitious language. It's trying to statically solve many types of problems which are typically solved through testing and experience. Using Rust productively requires much more Rust specific learning. With how Rust is changing and having multiple approaches to things as the language is defined, long living code bases are going to accrue different methodologies from whatever was popular when each component was written. I think in 10 years a few experienced devs will do to Rust what Go did to C: Take the bits that obviously worked well, add a few ideas from other languages to soften some rough corners, and present it is a smaller, easy to use package. Though I also in general hope old languages are being replaced by new languages, as that must happen if as an industry we are getting better at building software. But also because I'm making a programming language and I have to believe I've found room for improvement for that to be a good idea.

gameswithgo 6y ago
>Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans. So have all languages, with wildly different philosophies about how to do that. We collectively just don't have any idea what we are doing. Clearly nobody has stumbled on a big win or one particular language would start dominating the industry due to the productivity bump.
- deleted 6y ago
  [deleted]
- BobbyJo 6y ago
  >So have all languages, with wildly different philosophies about how to do that. I think what you refer to as differing philosophies are in fact differing goals, and the goal of Golang is very different from pretty much all other modern languages: simplicity. I think boiling everything down to 'they are all trying to do it better' misses the fact that the 'it' they are trying to do better is very different in some cases.

nemo1618 6y ago

I think you have this backwards. Go is explicitly optimized for software engineering; in fact, it's the only language I'm aware of that makes large-scale engineering its north star. Here's Rob Pike discussing how Go's design decisions make building and maintaining large programs easier: https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article (AFAICT, Rust was not named after "collecting Rust," and long-term maintenance is not one of its primary design goals.) As an example, one celebrated feature of Go is that "all Go programs looks familiar," i.e. it's easier to get oriented in an unfamiliar Go codebase than just about any other mainstream language. Partly this is due to `gofmt`, but also the fact that the language itself is relatively spartan, with few dark corners. It's an "unsophisticated" language, which obviously cuts both ways. Rust, by comparison, is a highly complex language. It allows for very powerful abstractions -- as well as very bespoke and "clever" constructs. I think Rust will develop a solid reputation for correctness, much like Haskell; Rust programs will run for many years without bugs or performance issues. But, again like Haskell, Rust will also have a reputation for allowing clever programmers to write too-clever code. That's why Go will prove to be the more maintainable language: because it intentionally limits expressiveness (a highly unpopular decision, unsurprisingly) and thereby limits the amount of "damage" any given programmer can do.

alricb 6y ago
Eiffel might be another.
- nemo1618 6y ago
  I don't know much about Eiffel; do you know of any articles or talks that discuss its design tradeoffs?
  - Jtsummers 6y ago
    Eiffel's bigger contributions are probably: Design-by-contract. The contracts aren't just comments, they aren't haphazardly enforced by adding asserts to the code. They're explicit parts of the language which allows for a lot of interesting consequences when utilized. Testing can be semi-automated directly from the code, some elements of the program design can be proved to be satisfied statically without the need for compilation and execution. The ability to encode your specification into the language is incredibly useful. Command-query separation. If methods return a value (queries) they should be referentially transparent, having no side effects. This is a principle so not an explicit language feature, but it can be enforced using DbC.

13415 6y ago

I'm going to be the heretic and predict the opposite about Go and Rust. The reason is that Rust is overengineered, allows for macros, and is getting more and more complicated all the time. It's going to be as complicated as C++ in 10 years from now. Go is kept simple, the team is reluctant to introduce large changes, and it was from the beginning planned as an "easier C" with automatic memory management. I'd also like to challenge the idea that Rust is optimized for maintaining. It's optimized for backwards compatibility. IMHO Ada is way better for long-term maintainability and in that respect beats every other language I know.

brundolf 6y ago
That's actually a great point about macros. I have extremely mixed feelings about Rust's macros, but one of those feelings is that if anything is going to compromise its status as "the maintainable language" down the line, macros are the most likely.
- 13415 6y ago
  That's also my impression about CommonLisp, which I otherwise like a lot. Macros are really handy but in the long run they force new programmers to learn DSLs forever. The same for templates, of course. They increase programmer comfort but decrease long-term maintainability. It's always a trade-off.
  - jcelerier 6y ago
    > in the long run they force new programmers to learn DSLs forever. but... that's a good thing. programs should be built as a collection of small DSLs tailored to the specific tasks of that program
zozbot234 6y ago
You think macros are overly complicated? Have you looked at how people use C++ templates?
- 6y ago

hnlmorg 6y ago

I've lost count of the number of times people have said that about a new language that has since fallen out of favour.

benreesman 6y ago

There was this wonderful 6-8 year period after every thread on programming stopped being dominated by Ruby advocacy and before it started up with Rust. Why cram a Rust advocacy soundbite into a thread about maintenance vs. prototyping?

mohanmcgeek 6y ago
Coincidentally it's all those Ruby people who are high profile Rust people.

potta_coffee 6y ago

It doesn't seem to me that Rust and Go are really trying to solve the same problems and they don't appeal to the same demographic. The Rust vs Go conversation is tired and pretty much pointless, and I've avoided Rust simply because of the Rust community, which emanates a vibe that turns me off. I think the weight of software that is written in Go means it's going to be around a while (K8s / Docker / Terraform / etc) and I hope it stays because it feels like a breath of fresh air to me and I enjoy working with it.

mohanmcgeek 6y ago
Yes. The Rust users seem to be spending all their time making Rust vs Go posts on the internet instead of making something killer enough to get people to use Rust.

tinco 6y ago

When Ruby was "hot", it was bringing a lot of new things to the table, things new developers take for granted now. If you start a new project in typescript, or even C#, you'll get almost all of the things that made Ruby great in 2006. When I introduce a new developer to Ruby, all I've got to argue in favour of it is that it's a beautifully designed and powerfully expressive language with a library ecosystem chock full of de-facto standardised gems. Relatively vague things, and any newbie can hit me back with its downsides: mediocre performance, no type definitions, and no evented I/O baked into the language. I do dread the day that I can't start a new project in Ruby, simply because my hiring pool would turn into a mire of people dreading to work on it.

reedjosh 6y ago
> mediocre performance, no type definitions, and no evented I/O baked into the language Ruby 3 addresses each of those issues. https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/ https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-rele...
- tinco 6y ago
  Definitely interesting new features, and Ruby is putting up a good fight. But if it was really a ruby feature, and not just something tacked on to stay relevant, that code example would've looked like this: require 'async' require 'net/http' require 'uri' ["ruby", "rails", "async"].each.parallel do |topic| Net::HTTP.get(URI "https://www.google.com/search?q=#{topic}") end I can't tell someone Ruby is beautiful, and then in the next sentence explain how you need to type Async twice just to get something to run asynchronously. Same of course for Ruby types, we're just not yet on the point for a truly new way of writing Ruby for Ruby 3. Maybe we'll finally get something like this could be in Ruby 4, but I fear the spectre of backwards incompatibility is going to stand in the way of something that's both truly Ruby and truly in the 2020's.
  - d3nj4l 6y ago
    Amen. As a massive ruby fan, I couldn’t put a finger on why I disliked ruby async, but you’ve got it exactly right.

JulianMorrison 6y ago

Go thinks that having a simple language, one way to do a thing, standard formatting, low boilerplate, and coupling minimised using interfaces and explicit exports all adds up to maintainability. Time will tell if it's right.

stouset 6y ago
Two of those in particular are what the overwhelming majority of detractors find issue with. A “simple” language frequently offloads more work onto its users. In my experience with golang, this is true. Meaningful abstraction is punished or impossible, so every solution to every problem—no matter how many times it’s been solved before—becomes a computer science exercise where every detail has to be dealt with and remains on full display. Reading golang is a chore because you can’t zoom out and look at the high-level flow, it’s only low-level minutiae at every level of the code. It’d be like an architect having to write the molecular layout of a skyscraper into the blueprints. Chemical formulae everywhere but no picture of walls, floors, or a building anywhere to be found. Second, claiming golang has “low boilerplate” is the programming language equivalent of Stockholm syndrome. Look up any popular project. Something like fifty percent is if res, err := func(…); err != nil { return nil, fmt.Errorf(“Look ma, I’m a human exception handler: %w”, err) } That’s not an exaggeration. 50% seems to be the trend from the projects I’ve sampled. It actually makes it frustratingly difficult to follow what a function is supposed to do because the logic is lost in a sea of nearly-identical error handling. Spotting a bug in one stanza of code that’s in a sequence of nearly-identical visual blocks is hard because your brain starts glossing over the details that are repeated.
- Seb-C 6y ago
  I wish there was a standard one-liner pattern to handle errors, that would improve it a bit visually. Go has a LOT of boilerplate. And that is why I love it. No magic. No implicit behavior. No weird stuff that will bite me if I don't know that something in a completely unrelated file is changing the behavior of my code. It allows me to write high quality code and care about all the millions of details I should be thinking about. Yes, 50% of go code is about handling specific cases and errors. And that's a good thing, because unexpected cases and error handling is 50% of the work that a developer should be doing. But often it is just neglected or difficult to spot in other languages (until it bites you).

coldtea 6y ago

>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"). I think the name Rust is rather a pun because it was designed to be "close to the metal".

brundolf 6y ago
It's had various adjacent meanings over the years (and I may have embellished a little bit in my original interpretation), but here's one explanation which isn't far off: https://tim.dreamwidth.org/1784423.html https://tim.dreamwidth.org/1784423.html > Also, calling Rust a research language is funny to me because -- as its name reflects -- we've tried hard to avoid incorporating new technology into it. We haven't always succeeded at failing to be novel, but we have a rule of thumb of not including any ideas in the language that are new as of the past ten years of programming language research. The field of programming language is full of old technology that hasn't been put to use in solving problems that it's exactly suited for. The goals with Rust were to avoid reinventing wheels, and see what the past had to teach us.

pojntfx 6y ago

I have to disagree with this. I'd even argue that the direct opposite is the case: Go is so conservative in it's decisions, it's hard to find a project from years ago which doesn't "just work" with `go run`. The syntax and semantics are very simple and tend not to change much/haven't really changed since the initial release, which is definitely not the case with Rust, where stuff moves really quickly (not a bad thing by definition, but IMHO not the best for maintaining an already existing project)

srparish 6y ago
> it's hard to find a project from years ago which doesn't "just work" with `go run` That's not been my experience. On a team I was on, even code from six months prior would sometimes be difficult to compile. They keep changing how GOPRIVATE works, or how modules work, or how vendoring works with modules.
carols10cents 6y ago
Rust takes backwards compatibility very seriously; if you ever come across a Rust project that doesn't build with the latest compiler, please file a bug.

kardianos 6y ago

Go is great for maintenance. It's actually annoying sometimes to build.

emodendroket 6y ago

I feel the opposite way about Go. Reading other people's code is relatively easy but the tedium of writing it can be draining.

bakatubas 6y ago

I think that is true regarding language popularity—but not their viability for intended purpose. Perl is a great example because although it has its quirks and the ecosystem shows some age, there really isn’t anything like Perl. It is a very good language for interacting in the console and with data of many types. It’s $_ variable which is based on implied context (much like in language we short-form speech when context is implied). Those are features something like rust (or go) simply isn’t designed for. Hell, people still use and enjoy programming in C or Basic or Pascal. They just aren’t “popular” because developers are eager to put their comp-sci to use and invent more languages :)

megameter 6y ago

I can confidently predict that both Go and Rust will be seen as the "old brown stuff" in not so many years and some hot new thing will have come along that everyone wants to build in. Rust's main claim to fame - safe manual memory - is already being re-examined. There is definitely interest in and pursuit of a lower-boilerplate means of getting the same, and there are some candidates out there already. Further, a language being successfully used by experts and popularized tends to precede an accumulation of low quality contributions that negate base improvements to maintenance. In due course, a popular Rust will become "enterprised" with an accretion of tooling and frameworks - although it might not look the same as "enterprise Java", it will have the same kinds of effects in creating barriers to entry and sucking the sense of "fun" out of the day-to-day workflow. Lastly, the application categories will change. There will be demand for "glue" again, applications that are just frontends to library code(perhaps code written in Go or Rust). The new language will be something not systems-focused, and perhaps aim to be mostly focused on content and presentation (as HTML was in inception).

aw1621107 6y ago
> There is definitely interest in and pursuit of a lower-boilerplate means of getting the same, and there are some candidates out there already. What are some of those candidates?

obviouslynotme 6y ago

Rust doesn't add anything that increases maintainability beyond memory safety. This is nice, but it's not even 1% of what maintenance work looks like. Maintaining a decades old code base means adding features without blowing up the beast. This involves: (1) digging through the code to find the area that does something close to the new feature, (2) trying to understand what is going on, (3) figuring out the style of it for conformity, and (4) slapping that bad boy in. Of these, (4) is by far the easiest part and the only one Rust will help you in. The digging for understanding is far more time consuming. The other parts require art, discipline, and linters.

dnautics 6y ago
Yes, for example this week I had to uncover a bug why a backend was occasionally delivering duplicated database rows to a frontend, in code I hadn't written. I couldn't replicate the problem in test, or in dev, it was only in prod and stage (because the data in stage and prod was the right shape to trigger a UB wontfix in the postgres query optimizer). Rust would not be friendly towards producing a RCA on this issue.

xh-dude 6y ago

I don’t know, of course, but I have a different sense of where Go will be if it survives generics. The lack of change will mean it’s reliable, it was never as pretty as some other things, and it doesn’t go too far out of its niche. A lot of languages that suffer past the honeymoon, it isn’t survival of the fittest, it’s just evolving bloat or ending up with vestigial organs - this is hard to get on board with for new developers.

geodel 6y ago

> I think Go is in a honeymoon phase and people will hate it in 10 years; .. I wrote some Go code for talking LDAPs and doing some CRUD Ops. Do I love this code? Nope. Do I love the product that I built? Very Much. I think love of language is somehow very much a Rust thing at least compared to Go. > Rust on the other hand is optimized for maintaining This seems to be a tall claim. So often in Rust some or other library, web framework goes defunct or abandoned. And they are not exactly in finished state so no maintenance is required. Same thing happens with other languages too. But Rust is quite young, even then we have abandoned projects. In 10 years I am not sure how Rust codebases will be more maintained not less. Now one can say maintenance point is about commercial projects where people are paid to maintain. Still then not sure how loved it would be by maintainers when original developers are long gone.

eternalban 6y ago

That's some honeymoon! The wife is gonna be mad at me for taking the moon bit literally. It's been more than a decade now for Go. What honeymoon is this? When I first saw Rust 1.0 spec, I made a mental note that "this will end in tears". (Do tears rust metal?) I made a similar prediction during Scala's honeymoon days: "This will be the JVM's C++". Go will have a Java-lite career trajectory: it has a pretty wide sweet spot (in various dimensions) that more than compensate for its shortcomings. The actual issue in this industry has been, and remains, the fact that it requires workers with above average intelligence that are tasked with building repetitive glorified book keeping applications. And in every programmer with a heart-beat's career, there comes a time when job boredom unconsciously lends a seductive glimmer to the shiny new thing. Java, Ruby, and Go all were in fact adopted because of the ambitious, smart, but bored, geeks decided they needed a brand new toy. (So taking your honeymoon metaphor, these trends are like mid-life crisis for programmers.) And, compounding the issue is the fact that those minding the programmers were and remain (in the best cases) mostly behind the curve -- they're in meetings all day, after all -- and are simply not in a position to authoritatively smack down "let's use X!" enthusiasms. (In the general case, they are entirely clueless.) Rust, like Scala, and Haskell, add an additional hook in that they offer the programming world's version of 'intellectual virtue signaling'. Case in point being your bon mot of "optimized for building". Seriously, that's the actual job description for 99% of worker bees in this field: building things! So, I'll make the prediction that Rust will go the way of Scala and Haskell, and there will come a brand new shiny and intellectually satisfying new thing and we'll have HN (in a typically forgetful fashion) dissing Rust and heaping praise on the new comer. This too shall pass. [p.s. I have a self-contract to only post 1 message in a 24 hour period on the entire internet and this was it for tonight. /over & out]

mohanmcgeek 6y ago
> And, compounding the issue is the fact that those minding the programmers were and remain (in the best cases) mostly behind the curve -- they're in meetings all day, after all -- and are simply not in a position to authoritatively smack down "let's use X!" enthusiasms. (In the general case, they are entirely clueless.) I don't think them smacking the "let's use x" is a good idea since it's the Devs who'll be writing the code. The org needs a framework that answers: 1. How easy is it to train someone to use this stack? How long would it take for someone to start writing good code 2. How much time would it save us when building something new? 3. How easy is it for someone completely new to the codebase to start contributing? 1 and 2 can be easily measured within the org You can use OSS as a proxy for 3

bch 6y ago

> it's right there in the name: software should be allowed to become old and "collect rust" Of course, names or intentions of things don’t really determine their quality, or we’d all be running our software on the alpha processor, namely the DEC Alpha. My pedantic comment is worth about as much, but might be interesting to some: Rust isn’t named after iron oxide, it’s named after fungus[0][1][2]. [0] https://stackoverflow.com/questions/16494822/why-is-it-called-rust#16503989 https://stackoverflow.com/questions/16494822/why-is-it-calle... [1] https://en.wikipedia.org/wiki/Rust_(fungus) https://en.wikipedia.org/wiki/Rust_(fungus) [2] https://www.reddit.com/r/rust/comments/27jvdt/internet_archaeology_the_definitive_endall_source/ https://www.reddit.com/r/rust/comments/27jvdt/internet_archa...

_james_33_22__ 6y ago

Oh my, here we go again: The first post on a general language thread is bashing Go and hyping Rust ... that in itself is a very sad and problematic story as some inexperienced devs fall into the trap of this kind of promotion that Rust is the silver bullet for all kind of applications / projects. Rust has it's place. Go has it's place. Java has it's place. There's so much more than pure language feature for successful projects. The language is not even in the top 3. But more importantly I disagree to your actual assessment: Go code is very easy to read and understand. You're at the core of the problem at hand at once. No over abstractions or complex syntax or complex language features. Go has very few quirks (every language has them, people thinking "their" language is free of them are just being ignorant). I found very few real world issues caused by language quirks in Go production code (just as with Java or .NET). Much more important for quality code are engineering decisions, structure and processes. As Go is easy to write, read and understand it leaves more mental capacity to those often underrated areas. Go is a memory managed language. That alone makes it much easier to understand and maintain than every other language where you need to do it yourself. Again, more room for engineering decisions. As Go has a very large and extremely useful standard lib you have much less issues with unmaintained third party libs. Imaging a large Rust codebase and all it's dependencies to one-person-maintained libs. A maintenance nightmare thinking 10 years ahead. Just look at some good quality Go code, e.g. Hugo https://github.com/gohugoio/hugo/blob/master/navigation/menu.go https://github.com/gohugoio/hugo/blob/master/navigation/menu... I've picked an arbitrary file. There might be issues in it, but look how easy to read and understand it is. Regarding Rust: I have no general interest in talking bad about it, but need to make a point. Just as a real world reminder think of the Actix story. One part is the unsafe issue. How many people in the world would be able to understand the actual code and could have cleaned it up? Maybe 50? Fortunately there was a happy end. But how much time and energy did it take to get it on track again? What if Actix had not been the most popular and known framework? All our companies Go servers (still mostly Java apps) are build with the standard lib. One thing less to worry about in the long run.

fonzi_3311 6y ago

>> I think Go is in a honeymoon phase and people will hate it in 10 years; >> Rust on the other hand is optimized for maintaining How come this post isn't flagged? Crazy ... How can someone more aggressively start a language flame war? These kind of posts of an individual are the reason for the bad reputation of the Rust community. Looking at the facts regarding the industrial usage and growth of Go and Rust in the real world one can only conclude that Go's honeymoon hasn't started yet. There are so many reason why Go is much more likely to be maintainable 10 years from now: - easier language - massive standard lib - professional maintainers at google - garbage collector - much, much more devs available - very sensible maintainers to keep Go stable - much more mature despite being not that much older - ...

zibzab 6y ago

> Rust on the other hand is optimized for maintaining I completely DISAGREE with this statement! I have already seen many year-old Rust projects fail to build due to changes to language, compiler and core libraries.

aw1621107 6y ago
Out of curiosity, would you be able to provide concrete examples of those build failures?
- zibzab 6y ago
  Just try random project from github without using nightly, alternatively try a project from 2018 with a current rustc. Specially the debian/Ubuntu Rust packages have hard time compiling many recent projects.
  - steveklabnik 6y ago
    These two issues sound totally different, a 2018 project that doesn’t use nightly should absolutely compile today, unless there was a soundness issue. (And the vast majority of projects don’t use nightly features.) The latter bit is the opposite, that is, old compilers can’t possibly know about new features, and that’s not a compatibility issue. That’s an older tool chain issue, or maybe a “community prefers newer tool chains than distros do” issue.
    - zibzab 6y ago
      But how in gods name can you call a language "maintainable" if just compiling it after certain time requires some detective work to find the right rustc/cargo versions? And that's only the first problem with maintaining old Rust projects. There are so many other issues, specially with projects created in very early Rust days. Tell me, have you ever seen a go project failing due to similar issues? Python had this problem once (2 to 3) and they are still apologising for it. (Not trying to start a language flame war. I like Rust and want it to succeed. But right now things are a bit chaotic)

mohanmcgeek 6y ago

Go was in the honeymoon phase between 2013-2016. Considering how much unnecessary attention Rust gets in this forum despite being a terrible language to learn would suggest that Rust is the language currently in the honeymoon phase. It's Rust that carries Ruby's and Scala's legacy of putting everything into the language. There's no forethought if it's a kitchen sink

pkolaczk 6y ago
I don't know about Ruby, but saying Scala and Rust put everything into the language is just totally incorrect. Both are designed with philosophy of building minimal set of features with very strong expressivity. For example Scala 3 removed a lot from the language and unified many features. As for Rust. Is there inheritance in Rust? No. Overloading? No. Global or static (like Java static) variables? No. GC? No. Exceptions as the main error handling feature? No. N ways of casting to a different type? No. 5 or 6 ways of building dataclasses like in Python? No. 20 ways of packaging / building a project? Again - nope. I think this is already enough to say they didn't put everything into the language, and they are actually very careful not to introduce unnecessary features. Actually I find Rust quite small, compared to e.g. Java or C++, but it has much better expressivity.