8 ms·

Still no generics, nor real type inference.

melling 11y ago
You created a burn account just to complain about this? As you know, generics won't appear before 2.0, if ever. It's fine if that's a nonstarter for you. Perhaps you'll like Rust instead. It needs a big community too.
- chowells 11y ago
  Why Rust? It doesn't really compete with Go anywhere. Haskell is a much stronger player in the space of high-level, garbage-collected languages. The only thing Rust and Haskell really have in common is not willfully ignoring the last 50 years of programming language design research.
  - aplummer 11y ago
    Doesn't it? Why do people seem to compare them all the time...
    - TazeTSchnitzel 11y ago
      Rust is a systems-level programming language. Go isn't: it's garbage-collected.
      - sacado2 11y ago
        Lisp is garbage collected. Yet Lisp machines existed, and they were invented at the same time as UNIX.
        nickpsecurity 11y ago
        And some's details were published for other people to learn from. Anyone wanting to see how they implemented it can google LISP and Scheme machines, hardware, processors, and similar search terms. I recall one implemented cons directly while hiding GC behind memory interface. The programs didn't even know there was collection and it happened in parallel with execution without stopping execution. Great stuff. Many of these give software and hardware implementation details where they could be copied in FPGA's. Closest thing I've seen in a modern product is Azul Systems' Java processors with concurrent GC's. So, at least one company is benefiting from the old wisdom.
      - pjmlp 11y ago
        Besides the sibling post. Xomb, Mesa/Cedar, Oberon, SPIN, Singularity were all written in GC enabled system programming languages.
        steveklabnik 11y ago
        Yeah, but at least with XOmB, we weren't actually _using_ the GC, as you can turn it off in D.
        pjmlp 11y ago
        Thanks for the heads up. Although given my Oberon knowledge, I would say that was more a consequence of D's GC implementation quality than anything else, right? On Oberon and all the derived OS, the Kernel module was the only one where GC wasn't used, as it needed to be implemented somewhere. All the other modules enjoyed access to an OS wide GC.
        steveklabnik 11y ago
        Well, it was really just that we didn't get that far, I guess. Mind you, my friends did much more of the work than I did, but like most student hobby projects, at some point, you just stop working on things.
        nickpsecurity 11y ago
        Good points. People often forget GC languages were often used to write OS's and system software even on constrained devices. A number of languages, such as Modula-2 and Ada, offered the ability to go unsafe in certain modules out of necessity but with safe interfaces. So, where Go or Rust can't cut it, language developers can just use a feature like that (or inline assembler) to solve those problems until the language itself can. Additionally, they can do what PL/S and certain Ada's did where specific modules were transformed by the compiler differently based on their needs. One might have total safety, one no safety, one a GC'd runtime, one a non-GC runtime, and one no runtime at all. Still using the same language and tools for everything, albeit subsets in some modules with extra worries.
    - learc83 11y ago
      Go gets compared to Rust because go was originally labeled a "systems" language. But the designers had a different older view of what "systems" meant than what is commonly used to day. People heard systems and thought they meant low level/operating system/embedded systems. That is not what Go is good for because it's garbage collected. They also planned to attract C++ programmers, but they've basically been attracting dynamic language programmers instead. Why that was a surprise is beyond me--I can't imagine that anyone currently using C++ would be OK switching to a garbage collected language. Rust on the other hand, is shaping up to be a C++ replacement.
      - mcgirr 11y ago
        Yeah, additionally it would be unwise to use Go in embedded systems because it is so reliant on heap memory for dynamic allocation. In certain situations where things could fail if an operation takes too long - rocketry and robots - it would be difficult to tell how long something would take in Go with any degree of certainty because allocating and freeing memory on the heap is highly non-deterministic.
        tracker1 11y ago
        If you can do robots with Node.js, I'm pretty sure Go may well be acceptable here.
        learc83 11y ago
        No one is arguing that you absolutely can't use Go to build a robot, just that it's probably not a good idea. Just because someone uses Node.js to build a hobby robot, doesn't mean that many people are using it for production embedded systems. If your systems has hard real time requirements, which many systems do (even many hobby robots), a stop the world garbage collector is out of the question. Let's say you have a legged robot that depends on interpreting sensor feedback to keep from failing over. What happens to your balance when the garbage collector pauses your code for 10ms?
        pjmlp 11y ago
    - deleted 11y ago
      [deleted]
  - danieldk 11y ago
    Why Rust? It doesn't really compete with Go anywhere. I guess people compare Rust and Go because they were released in similar timeframes and people like to view things in competition. Rust is especially attractive when you can't afford a garbage collector, need deterministic destruction, and full compatibility with C. It's what C++ would be if it could start from scratch. I think your point needs to be re-iterated more often: if garbage collection and ~2-3x the running time of C is not a problem, OCaml, Haskell, Scala, F#, etc. are the competition of Go. They integrate modern (read: mostly 70ies/80ies) language design insights, while providing approximately the same performance as Go.
    - mkpankov 11y ago
      > similar timeframes I hope you understand first stable release of Rust happened less than 2 weeks ago (15 May 2015), vs. Go's Go 1 in March 2012. 3 years is pretty big difference.
      - danieldk 11y ago
        I hope you understand first stable release of Rust happened less Of course, but Rust has been in tech news for a while already. E.g., the Rust 0.1 post garnered 82 comments[1], over 3 years ago. Rust seems to be first mentioned in a submission title 5 years ago. Of course, their inception was not exactly at the same time. But if we look back in 20 years, it's the same timeframe. Just like e.g. Python and Ruby, despite being 4 years apart. Or C and Pascal. [1] https://news.ycombinator.com/item?id=3501980 https://news.ycombinator.com/item?id=3501980
        enneff 11y ago
        I find your perspective a little bizarre. For instance, if we look on a galactic time scale, Lisp and Go were created at pretty much the same instant! It's not fair to Rust to compare it to Go, as if they are at the same stage of their adoption and development. Several years is makes a big difference in the tech world.
        11y ago
  - Dewie3 11y ago
    > Why Rust? Whenever Go is mentioned, Rust has to be mentioned somewhere in that same thread. And vice versa. It's practically law. Perhaps a good indication that the debates tend to be more fashion-driven then about technical points (when the discussion is about new languages itself, that is of course reasonable though).
    - sacado2 11y ago
      Right. I think the closest languages to Go, regarding respective niches or overall philosophies, are Java and Oberon. Yet nobody ever compares them.
  - muraiki 11y ago
    Actually, I read an interview with one of the Rust devs recently where he said that one of the meanings behind the name "Rust" is that they purposely chose not to use any ideas from programming language research within the past 10 years. IIRC it was because they wanted to use only ideas that had had some time to mature and be used in practice. So yes, Rust chose to willfully ignore at least some of the past 50 years of PL design research. :)
  - Nelson69 11y ago
    They both compile to machine code? People get bent around the wheel all the time with the tiny niches but both seem well equipped for writing user land applications and are designed to be safer than C and it's cousins. Both have some legitimate interest in them which is what really differentiates them from like D or Ada. Neither is going to be used for kernels (maybe I should say 'serious kernels') and drivers any time really soon. They have a lot of similarity in those regards. Seems like a golden era to have 2 competing languages that are aiming at C and C++ and have legitimate community interest.

You created a burn account just to complain about this? As you know, generics won't appear before 2.0, if ever. It's fine if that's a nonstarter for you. Perhaps you'll like Rust instead. It needs a big community too.

chowells 11y ago
Why Rust? It doesn't really compete with Go anywhere. Haskell is a much stronger player in the space of high-level, garbage-collected languages. The only thing Rust and Haskell really have in common is not willfully ignoring the last 50 years of programming language design research.
- aplummer 11y ago
  Doesn't it? Why do people seem to compare them all the time...
  - TazeTSchnitzel 11y ago
    Rust is a systems-level programming language. Go isn't: it's garbage-collected.
    - sacado2 11y ago
      Lisp is garbage collected. Yet Lisp machines existed, and they were invented at the same time as UNIX.
      - nickpsecurity 11y ago
        And some's details were published for other people to learn from. Anyone wanting to see how they implemented it can google LISP and Scheme machines, hardware, processors, and similar search terms. I recall one implemented cons directly while hiding GC behind memory interface. The programs didn't even know there was collection and it happened in parallel with execution without stopping execution. Great stuff. Many of these give software and hardware implementation details where they could be copied in FPGA's. Closest thing I've seen in a modern product is Azul Systems' Java processors with concurrent GC's. So, at least one company is benefiting from the old wisdom.
    - pjmlp 11y ago
      Besides the sibling post. Xomb, Mesa/Cedar, Oberon, SPIN, Singularity were all written in GC enabled system programming languages.
      - steveklabnik 11y ago
        Yeah, but at least with XOmB, we weren't actually _using_ the GC, as you can turn it off in D.
        pjmlp 11y ago
        Thanks for the heads up. Although given my Oberon knowledge, I would say that was more a consequence of D's GC implementation quality than anything else, right? On Oberon and all the derived OS, the Kernel module was the only one where GC wasn't used, as it needed to be implemented somewhere. All the other modules enjoyed access to an OS wide GC.
        steveklabnik 11y ago
        Well, it was really just that we didn't get that far, I guess. Mind you, my friends did much more of the work than I did, but like most student hobby projects, at some point, you just stop working on things.
      - nickpsecurity 11y ago
        Good points. People often forget GC languages were often used to write OS's and system software even on constrained devices. A number of languages, such as Modula-2 and Ada, offered the ability to go unsafe in certain modules out of necessity but with safe interfaces. So, where Go or Rust can't cut it, language developers can just use a feature like that (or inline assembler) to solve those problems until the language itself can. Additionally, they can do what PL/S and certain Ada's did where specific modules were transformed by the compiler differently based on their needs. One might have total safety, one no safety, one a GC'd runtime, one a non-GC runtime, and one no runtime at all. Still using the same language and tools for everything, albeit subsets in some modules with extra worries.
  - learc83 11y ago
    Go gets compared to Rust because go was originally labeled a "systems" language. But the designers had a different older view of what "systems" meant than what is commonly used to day. People heard systems and thought they meant low level/operating system/embedded systems. That is not what Go is good for because it's garbage collected. They also planned to attract C++ programmers, but they've basically been attracting dynamic language programmers instead. Why that was a surprise is beyond me--I can't imagine that anyone currently using C++ would be OK switching to a garbage collected language. Rust on the other hand, is shaping up to be a C++ replacement.
    - mcgirr 11y ago
      Yeah, additionally it would be unwise to use Go in embedded systems because it is so reliant on heap memory for dynamic allocation. In certain situations where things could fail if an operation takes too long - rocketry and robots - it would be difficult to tell how long something would take in Go with any degree of certainty because allocating and freeing memory on the heap is highly non-deterministic.
      - tracker1 11y ago
        If you can do robots with Node.js, I'm pretty sure Go may well be acceptable here.
        learc83 11y ago
        No one is arguing that you absolutely can't use Go to build a robot, just that it's probably not a good idea. Just because someone uses Node.js to build a hobby robot, doesn't mean that many people are using it for production embedded systems. If your systems has hard real time requirements, which many systems do (even many hobby robots), a stop the world garbage collector is out of the question. Let's say you have a legged robot that depends on interpreting sensor feedback to keep from failing over. What happens to your balance when the garbage collector pauses your code for 10ms?
      - pjmlp 11y ago
  - deleted 11y ago
    [deleted]
- danieldk 11y ago
  Why Rust? It doesn't really compete with Go anywhere. I guess people compare Rust and Go because they were released in similar timeframes and people like to view things in competition. Rust is especially attractive when you can't afford a garbage collector, need deterministic destruction, and full compatibility with C. It's what C++ would be if it could start from scratch. I think your point needs to be re-iterated more often: if garbage collection and ~2-3x the running time of C is not a problem, OCaml, Haskell, Scala, F#, etc. are the competition of Go. They integrate modern (read: mostly 70ies/80ies) language design insights, while providing approximately the same performance as Go.
  - mkpankov 11y ago
    > similar timeframes I hope you understand first stable release of Rust happened less than 2 weeks ago (15 May 2015), vs. Go's Go 1 in March 2012. 3 years is pretty big difference.
    - danieldk 11y ago
      I hope you understand first stable release of Rust happened less Of course, but Rust has been in tech news for a while already. E.g., the Rust 0.1 post garnered 82 comments[1], over 3 years ago. Rust seems to be first mentioned in a submission title 5 years ago. Of course, their inception was not exactly at the same time. But if we look back in 20 years, it's the same timeframe. Just like e.g. Python and Ruby, despite being 4 years apart. Or C and Pascal. [1] https://news.ycombinator.com/item?id=3501980 https://news.ycombinator.com/item?id=3501980
      - enneff 11y ago
        I find your perspective a little bizarre. For instance, if we look on a galactic time scale, Lisp and Go were created at pretty much the same instant! It's not fair to Rust to compare it to Go, as if they are at the same stage of their adoption and development. Several years is makes a big difference in the tech world.
        11y ago
- Dewie3 11y ago
  > Why Rust? Whenever Go is mentioned, Rust has to be mentioned somewhere in that same thread. And vice versa. It's practically law. Perhaps a good indication that the debates tend to be more fashion-driven then about technical points (when the discussion is about new languages itself, that is of course reasonable though).
  - sacado2 11y ago
    Right. I think the closest languages to Go, regarding respective niches or overall philosophies, are Java and Oberon. Yet nobody ever compares them.
- muraiki 11y ago
  Actually, I read an interview with one of the Rust devs recently where he said that one of the meanings behind the name "Rust" is that they purposely chose not to use any ideas from programming language research within the past 10 years. IIRC it was because they wanted to use only ideas that had had some time to mature and be used in practice. So yes, Rust chose to willfully ignore at least some of the past 50 years of PL design research. :)
- Nelson69 11y ago
  They both compile to machine code? People get bent around the wheel all the time with the tiny niches but both seem well equipped for writing user land applications and are designed to be safer than C and it's cousins. Both have some legitimate interest in them which is what really differentiates them from like D or Ada. Neither is going to be used for kernels (maybe I should say 'serious kernels') and drivers any time really soon. They have a lot of similarity in those regards. Seems like a golden era to have 2 competing languages that are aiming at C and C++ and have legitimate community interest.