13 ms·

This a key difference between the Go community and the Rust community. Go is like C 2.0: it tries to be minimal and stable. Go usually ships with no language ch

• dilap 7y ago
  I'm a Go fan and I've used it tons; I'm Rust-curious, but I've only made toy programs w/ it. While there is a germ of truth to this -- C++ and Rust are both complex -- I think it carries w/ it a lot of connotations which are untrue. To wit, C++ is a brutal, terribly designed mess that's absolute torture to work with. Rust is extremely well-designed and a pleasure to work with. Very important difference!
  • inimino 7y ago
    C++ is two and a half decades older than Rust. Come back to this comment in 25 years and see how well the pleasure of Rust's design has held up.
    • thawaway1837 7y ago
      That’s ironic because arguably C++ became a much better language in the last decade or so than what it was before that.
      • rob74 7y ago
        ...and I'm sure the language features which feel like torture now looked like a good idea at the time they were implemented, decades ago.
        • dwaite 7y ago
          However, most of those torturous points were from the onset, to attempt 100% compatibility with C.
        • marcosdumay 7y ago
          Hum... No they didn't. People were creating new languages by that time just to reimplement them correctly.
    • dralley 7y ago
      The "edition" model is a big point in Rust's favor. They can make "backwards incompatible" syntax changes without infringing on the ability to compile older code.
  • aloknnikhil 7y ago
    Pre-C++11 was. Modern C++ not so much. Things have drastically improved and dare I say, it's more appropriate to call C++11 and greater C++ v2. That said the tooling around build/test/dependency management/versioning leave much to be desired for. But a combination of meson (for build), Catch (for test) and CMake for dependency management can go a long way.
    • baby 7y ago
      Do you still need to write makefiles manually?
      • dwaite 7y ago
        If you are using makefiles, you either write them manually or use a generator like Cmake or the autotools. Tools or scripts to automate build are required in all languages once you hit a certain level of heterogeneity/complexity.
      • umanwizard 7y ago
        What does the build system have to do with the language? The current trend of combining the two concerns by having language-specific build systems (like Cargo) was a mistake, IMO.
        • adrianN 7y ago
          It has a lot to do with the language because the ease of adding external libraries has an enormous impact on the design choices made when writing code. Also, the need for header files and disgusting hacks like unity builds just adds unnecessary friction.
          • signa11 7y ago
            > ... language because the ease of adding external libraries has an enormous impact on the design choices... even if you could incorporate external libraries with zero impedance mismatch, you still have to _use_ the said libraries. while there might be _marginal_ element of truth to that statement, however ease of stitching external libraries into your application has no bearing on either the programming language or the act of programming the application itself.
  • adev_ 7y ago
    > To wit, C++ is a brutal, terribly designed mess that's absolute torture to work with That's not arguments. That's at best your personal feelings, or just FUD depending of point of view. And not everybody agree with that. I personally find Golang brain dead and close retarded because it is a shame to see language in 2020 not even supporting Generics and Operator overloading.
    • baby 7y ago
      Every languages must have generics and overloading? Gosh that’s one crazy opinion.
      • adev_ 7y ago
        That's my opinion for system language. And even if purely superficial, it has already more argument that the previous comment. But yes, if your language pretend to be a modern system language, you should yes. Not being able to write generic data structure or linear algebra containers in 2020 is a shame yes.
        • baby 7y ago
          Well. I love the fact that Go code doesn’t have generics. Super clear to read. I must be a goof.
• adamnemecek 7y ago
  No, it's nothing like C++. The only recent big change was async but how many other things have changed?
  • jfkebwjsbx 7y ago
    Almost the entire language since its early days. And there have been 2 major editions in the last 5 years.
    • bschwindHN 7y ago
      I would only count language changes since its 1.0 release, there really haven't been that many.
      • jfkebwjsbx 7y ago
        That's fair, then 1 major edition. There have been a lot of added features, though. I am not sure why people downvoted me.
        • kibwen 7y ago
          In the parlance of the Rust developers, a "feature" is often just the addition of a single function to the standard library. The only remotely paradigm-shifting feature to be added since 1.0 was async/await; the other things mentioned in the blog post are minor QOL nice-to-haves.
    • gamegoblin 7y ago
      I don't think it's really fair to talk about pre-1.0 language changes -- by definition, being pre-1.0 typically implies a lack of stability. One of the major editions you mention is the 1.0 release. So, there has been 1 new edition since 1.0, and, as the parent comment says, the only really groundbreaking change since 1.0 is the stabilization of async support. Other changes, such as the `dyn` keyword and match ergonomics are mostly superficial, and things such as NLL and additional lifetime elisions are just simple quality of life improvements that don't fundamentally change the language.
• yahyaheee 7y ago
  Yea I think this concept just doesn’t resonate deeply with the rust community for some reason
  • dodobirdlord 7y ago
    > When a new version of Rust is released, the core Rust devs write a blog post gleefully explaining all the new "features" the current version has. What these devs perhaps fail to appreciate is that not having new features can itself be a feature. Rust is trying to solve a set of problems, some combination of which exist in pretty much every programming language that exists today (including Rust). "Have you considered giving up?" is obviously not a very interesting question and not one that's going to get much traction.
    • ddevault 7y ago
      The question is not "have you considered giving up?", but rather "have you considered when this will be finished?"
      • ironmagma 7y ago
        From using Rust, it’s clear there is still a lot of work to be done. Someday Rust will be stable and mature, but it isn’t now, and it doesn’t look like it will be a year from now either. The plasticity of the language honestly is what allows it to continue to innovate where others do not. Let’s let Rust find its niche and then lock it down, and not rush it or we’ll be regretting it in a few years.
      • DeathArrow 7y ago
        Try Cobol, it's pretty much finished.
        • moogly 7y ago
          The latest version was released in 2014
      • 7y ago
• Skunkleton 7y ago
  IMO Go is more like C people took a stab at making a Java. I really like go, and it’s ethos, even if I haven’t used it much in production. Go is not however a replacement for C in the way C++ and Rust can be. Of course Rust and C++ aren't a replacement for C in some key ways, so maybe I don't have a point here?
  • tmh88j 7y ago
    >IMO Go is more like C people took a stab at making a Java. I haven't used Go beyond tutorials and some very basic programs, but I am pretty comfortable with Java. What about Go makes you feel it's relatable to Java? From what I've read the lack of generics is a hot topic in the Go community, but they're pretty crucial to most programs written in Java. Is this still true?
    • 7thaccount 7y ago
      Garbage Collector?
      • EdwardDiego 7y ago
        Go's GC is quite different to Java's though - deliberately not as many knobs to twiddle.
    • doliveira 7y ago
      Java didn't have generics before version 5, I think. It was a hell of casting back and forth Object, much like Go and interface{} today.
    • correct_horse 7y ago
      As a side note, Java also didn't ship with generics. Java was released in the mid 90s and didn't have generics until about 10 years later with version 5. This timing should feel familiar - Go first appeared ~10 years ago in 2009. You may remember that in Java 1.4, `get`ting from collections (e.g. ArrayList) always returned Object, which you were expected to cast to their runtime type (or a class that their runtime type inherits from). I was young at the time, correct me if I'm wrong. Contrast this with Go's solution, which seems to be user-inaccessible compiler magic. I much prefer Go's solution to Java's, but I also like generics.
• phkahler 7y ago
  Stability is THE most important feature. Rust needs to mature a little more and then mostly just stop. I seriously hope that it doesnt follow the C++ path.
  • steveklabnik 7y ago
    Rust has made very strong stability guarantees. Just today someone posted in /r/rust about how they took a two year old project, compiled it with the latest compiler, no issues. Other than it magically took less time to compile and the end result ran faster.
    • Fordec 7y ago
      Two years is nothing, absolutely nothing, in the grand scheme of "long term".
      • steveklabnik 7y ago
        That's correct. Rust is still a pretty young language; it's only been stable for five years. This doesn't mean that two years is meaningful in a broader sense, that is, this is one random anecdote. I know of a crate that still maintains Rust 1.13 compatibility, and that's about three and a half years. Still not actual evidence, of course. Code that doesn't rely on soundness bugs written in 1.0 should generally compile on the latest stable release without issue. The vast majority Rust users in our annual survey report that their code never breaks, and of those that have, the majority have said that it is trivial or easy to fix. We put a tremendous amount of work (and spend a lot of money!) into ensuring this. If upgrading your Rust compiler is a significant issue for you our anyone else, please report these things to us.
        • Fordec 7y ago
          It is indeed a young language. Upgrading my compiler isn't an issue. I haven't opted to transitioning to Rust at all in the first place until things calm down. I've yet to feel that my career has once ever been impacted by not learning it. I'm in hardware land, not JavaScript frontends. Innovation there is more about the product features, sensor capabilities, power consumption. Generally solving customer issues. Selling adoption of a new language to the superiors or new job interviewers to use in production isn't an issue about compiler upgrades or the merits of using cargo fix. They are more concerned about how many people are available to be hired that has extensive expertise in the language, making hiring hard, and support is still in flux. And that is what I'm reporting, tooling is more than about the compiler, the world around it and human issues, particularly non-technical humans are also at hand. And until there is stability and a language people don't feel is a moving target to learn, that will remain the chicken and egg scenario.
• Ar-Curunir 7y ago
  Rust has only become more uniform and contains less special cases than just a couple of years ago. The rate of adding features is quite slow, as demonstrated elsewhere in this thread. Important features spend a long time baking, and a long time in testing before they are piecewise stabilized. > When a new version of Rust is released, the core Rust devs write a blog post gleefully explaining all the new "features" the current version has. Of course when someone talks about a CHANGELOG, they'll talk (rather happily) about the things that have changed/improved.
  • lmm 7y ago
    > Rust has only become more uniform and contains less special cases than just a couple of years ago. How so? Aren't await and ? both new special cases?
    • kibwen 7y ago
      What the GP means there is that when the list of new "features" comes out with each Rust release, if we discard the features that are just new stdlib APIs (~75% of the total count for an average release), most of the remaining "features" are just tweaks to existing language features that remove edge cases, e.g. non-lexical lifetimes. As for your second question, async/await is absolutely the biggest thing added since 1.0 (and is an outlier in new features in that regard); the ? operator is just an improved version of the try! macro that shipped with 1.0.
      • lmm 7y ago
        The way I see it NLL added a huge number of edge cases. Pre-NLL it was clear what kind of lifetimes were possible; now I have no clue what the different lifetimes are and every keyword interacts with lifetimes in a different way.
        • mrpf1ster 7y ago
          Pre-NLL made the language incredibly clunky to use, with a lot of code acrobatics required to do something you know should work logically according to ownership but the scope lifetime rules wouldn't allow.
• banachtarski 7y ago
  How is Go anything like a C 2.0. It's more of a server-side scripting language if anything
  • pjmlp 7y ago
    When companies like F-Secure use it to write bare metal security firmware, CoreBoot uses it for UEFI firmware, or Google creates an hypervisor, TCP/IP stack and GPGPU debugger with it.
• littlestymaar 7y ago
  We hear this narrative really often even though it's not accurate: Go has its share of outrage about one change (in error handling too amusingly) last year and the proposal (the try keyword) even had to be repealed because it was considered too revolutionary. Go modules are a huge change in how Go dependency management works and it's comparable, or even bigger in scope, to the Rust changes in 2018 edition regarding modules. And in a near future, Go's generics (contracts) are going to be a dramatic change, in a scale Rust arguably hasn't faced yet since 1.0, even though there is some similarities with the impl Trait features. In fact, Go and Rust are both evolving fast compared to C (and maybe even to C++) and interestingly enough, most of the time the evolution comes in similar domains (error handling, modules, generics). The big difference is the release schedule: Rust release small changes often while Go release big changes rarely. The 6-weeks schedule has advantages (each version is quite small so it's easier to test and bugs are found earlier) but it adds a feeling of churn which can be harmful.
  • ldng 7y ago
    The point is that Rust is changing too fast. Not that Go does not change ever.
    • littlestymaar 7y ago
      My point is that Rust doesn't really change more than Go does. Rust used to change a lot after 1.0, but for the past 3 years it hasn't been the case if you compare it to how much Go changed.
    • ChrisSD 7y ago
      "Too fast" is relative but the Rust language has had few changes since the 2018 edition (and even that can work alongside the 2015 edition). The pace of change has slowed significantly in recent years. The standard library has had more additions (but Go has had changes there too). The blog post we're all commenting on started because someone took umbrage to an idea someone else expressed in another blog post. Not because of any actual language changes, not even a formally proposed change, just an idea in a blog post. All the actual changes mentioned ("try!() -> ?, the addition of impl trait, and the dyn keyword") happened years ago. And not all at once. It took years from adding `?` to adding `dyn`.
• throw_m239339 7y ago
  Go is more like static Python rather than C 2.0. I wish Go was C 2.0, but it isn't with its crazy reflection where one can do basically whatever they want, and garbage collector. Rust is … just Rust.
  • graynk 7y ago
    Static Python is Nim. Go is way more C-like with its structs and pointers
  • umanwizard 7y ago
    Rust is OCaml disguised as c++ :)
• umanwizard 7y ago
  C++ only changes every 3 years. It’s hardly comparable to Rust’s every-six-weeks churn.