4 ms·

I feel like I'm beating a dead horse, but I really can not grasp what the catalysts are for creating Rust or Go or Julia or other new languages that want to be

I feel like I'm beating a dead horse, but I really can not grasp what the catalysts are for creating Rust or Go or Julia or other new languages that want to be safe, reliable, readable, etc.. 30 years ago these problems were solved in a language Ada. Its exact requirements include all of those and more. See for yourselves: http://www.adahome.com/History/Steelman/steelman.htm http://www.adahome.com/History/Steelman/steelman.htm Later revisions have well-though-out rationales that show off all the changes: Ada 95: http://www.adaic.org/resources/add_content/standards/95rat/rat95html/rat95-contents.html http://www.adaic.org/resources/add_content/standards/95rat/r... Ada 2005: http://www.adaic.org/ada-resources/standards/ada05/ http://www.adaic.org/ada-resources/standards/ada05/ Ada 2012(!!): http://www2.adacore.com/wp-content/uploads/2006/03/Ada2012_Rational_Introducion.pdf http://www2.adacore.com/wp-content/uploads/2006/03/Ada2012_R... The steelman was the end revision of requirements for the original language. There is a comparison of C/C++/Java/Ada wrt the steelman available as well. Ada has become so much more since this document and it's original version one really must see it to be believe it. :o) As a community we have a tendency to embark on projects on a whim, but the effort, time and money required to bring a language to maturity is enormous. Even then any deficiency a preexisting language may have surely is not so insurmountable as to make it viable to develop a new language in house. Can we please have some sanity? Can we please look for mature solutions? Edit: Ada has an amazing GCC frontend developed largely by a successful opensource company (with just massive customers across the globe) and is available across all of its targets: the bsd's, solaris, linux, mac, haiku, android and more. It's a great solution that is hard to ignore.

tedunangst 15y ago
I've used Ada. It was a super major pain in the butt. Go is like an easier to use C, where Ada is like a harder to use C. The solution to "people screw up dynamic allocations" is not "make dynamic allocations brutally difficult".
- jmilkbal 15y ago
  Ada wants to catch as much as it can before runtime. To that end, it is one strict beast when you're used to all the willy nilly (and unsafe) constructs that we can beat C into doing. Ada absolutely is harder; it's built for hard problems. I don't intend to turn away from the topic of TFA, but Ada is on quite a different plane than C for a number of reasons--reasons that I think are compelling. C is wonderful for creating a foundation for low-level software as it has demonstrated for what seems like an eternity, but beyond that--and I think the crazy things we've done over time to make it a little easier to use reflect this--something with more high-level, safe, readable, yada, yada, yada is desirable if not absolutely needed. Dynamic allocations in Ada are a cinch by the way. We use the "new" reserved word. subtype Hacker_News_Article_ID is Natural; -- Numbers 0 .. Integer'Last; type Article_Handle is access all Hacker_News_Article_ID; -- "all" reserved word used allows access to variables on the stack. Favorite_Article : aliased Hacker_New_Article_ID := 3793716; -- "aliased" so we can point to this stack variable. Article_Pointer : Article_Handle := Favorite_Article'Access; -- A sensible default perhaps. later on... Article_Pointer := new Hacker_News_Article_ID (Whatever); Good luck!
  - tedunangst 15y ago
    What I meant by dynamic allocation was allocating an array of the necessary size. Last I checked, the Ada solution was to always allocate the largest possible array you would ever need every time. Correct me if I'm wrong, but in Ada if two arrays are different sizes, they are completely different types. In practice, this means your Ada written image viewer can show you 1000 thumbnails, but no more. Or 10000, or some other hard limit. And you can only view images smaller than 2MP. Unless the author made the fixed sizes really large, but now you're burning 10MB of memory per image even if they're all tiny gifs.
    - xlq 15y ago
      This is untrue. This is an Ada declaration for a fixed-size array of Foo with indices 1 to 10 (inclusive): type Foo_Array is array (Integer range 1..10) of Foo; This is an array indexed by an enumeration: type Foo_Array is array (Some_Enum) of Foo; But dynamically sized arrays can also be declared: type Foo_Array is array (Integer range <>) of Foo; Note that such an array has a dynamic lower bound and a dynamic upper bound. If I create an instance of such an array and pass it to a procedure: declare My_Array: Foo_Array (3..10) begin Do_Something (My_Array); end; then the procedure Do_Something receives both bounds of the array, 3 and 10, which it can read with the 'First and 'Last attributes. A declaration like the one above is typically done on the stack (although it doesn't have to be). An array can be allocated on the heap with "new", with, IIRC, the following syntax: new Foo_Array (3..10)
      - tedunangst 15y ago
        Thanks for the clarification. Can you create an array with variable size though? new Foo_Array(x..y) That's what I couldn't figure out how to do last I tried.
        xlq 15y ago
        Yes. What you've written is exactly how to allocate an array of dynamic size on the heap. You can also do: declare My_Array: Foo_Array(X..Y); begin ... end;
- gchpaco 15y ago
  Ada 95 is a very different language from Ada 83, cleaning up a bunch of rough edges in the latter. That said I still don't really like it, for aesthetic reasons more than anything else.
whateverer 15y ago
You are right with respect ot maturity, and Ada does have some high level concurrency constructs, though I'm not well versed enough to compare them with other language's. I think a main selling point for Rust is its type system: it's more up to date from the state of the art of... the mid seventies, having Algebraic Data Types and type inference. Though it does seem to lack some of Ada's features, such as its limited support for dependent types in the form of its ranged numeric types and fixed-length array, so it may balance out. Edit: oh, and Rust has no null. I guess people still dislike verbose syntax, and you still see people making macho arguments about how they like to throw type-safety over the window for 'power', but Ada without doubt is a seriously underrated language.
- jmilkbal 15y ago
  Ada's verbosity is one of it's best qualities making it perfectly suited for our large, geographically distant team. There are far less questions about the purpose and meaning of code when its in Ada. Seriously! And to boot the documentation writers have fewer problems determine this either since it's all spelled out in plain language. Of course this applies some to Pascal, Oberon and Modula for example, but they are missing other things that make Ada a great choice.
kibwen 15y ago
I don't have any experience with Ada, and I don't intend to refute your points. Nor do I have oodles of experience with either Rust or Go. However, as I see it, the problem with our current language ecosystem isn't "we lack a safe, fast, low-level language in which to implement things"; as you've pointed out, we've long had Ada. Instead, the problem is "people are using C++ to laboriously construct applications that, while not safety-critical, still require a high degree of reliability". This is a social problem rather than a technical one, and it probably has more to do with path dependence and resistance to unfamiliarity than with the technical merits of the modern iterations of either language. In a perfect world, perhaps we'd be using Ada for all tasks that currently require C++. However, the fact that we're still using C++ over Ada suggests to me that there is still room for new languages in this area. I agree that it's sad to see so much redundancy and duplication of effort. But if the end result of all of this is that future applications are written in a more reliable language, isn't that still a net win for society, regardless of what that language is?
jk4930 15y ago
I get the feeling that Ada could receive some hacker love, see the discussion in this thread (4 days ago): http://news.ycombinator.com/item?id=3774156 http://news.ycombinator.com/item?id=3774156

tedunangst 15y ago

I've used Ada. It was a super major pain in the butt. Go is like an easier to use C, where Ada is like a harder to use C. The solution to "people screw up dynamic allocations" is not "make dynamic allocations brutally difficult".

jmilkbal 15y ago
Ada wants to catch as much as it can before runtime. To that end, it is one strict beast when you're used to all the willy nilly (and unsafe) constructs that we can beat C into doing. Ada absolutely is harder; it's built for hard problems. I don't intend to turn away from the topic of TFA, but Ada is on quite a different plane than C for a number of reasons--reasons that I think are compelling. C is wonderful for creating a foundation for low-level software as it has demonstrated for what seems like an eternity, but beyond that--and I think the crazy things we've done over time to make it a little easier to use reflect this--something with more high-level, safe, readable, yada, yada, yada is desirable if not absolutely needed. Dynamic allocations in Ada are a cinch by the way. We use the "new" reserved word. subtype Hacker_News_Article_ID is Natural; -- Numbers 0 .. Integer'Last; type Article_Handle is access all Hacker_News_Article_ID; -- "all" reserved word used allows access to variables on the stack. Favorite_Article : aliased Hacker_New_Article_ID := 3793716; -- "aliased" so we can point to this stack variable. Article_Pointer : Article_Handle := Favorite_Article'Access; -- A sensible default perhaps. later on... Article_Pointer := new Hacker_News_Article_ID (Whatever); Good luck!
- tedunangst 15y ago
  What I meant by dynamic allocation was allocating an array of the necessary size. Last I checked, the Ada solution was to always allocate the largest possible array you would ever need every time. Correct me if I'm wrong, but in Ada if two arrays are different sizes, they are completely different types. In practice, this means your Ada written image viewer can show you 1000 thumbnails, but no more. Or 10000, or some other hard limit. And you can only view images smaller than 2MP. Unless the author made the fixed sizes really large, but now you're burning 10MB of memory per image even if they're all tiny gifs.
  - xlq 15y ago
    This is untrue. This is an Ada declaration for a fixed-size array of Foo with indices 1 to 10 (inclusive): type Foo_Array is array (Integer range 1..10) of Foo; This is an array indexed by an enumeration: type Foo_Array is array (Some_Enum) of Foo; But dynamically sized arrays can also be declared: type Foo_Array is array (Integer range <>) of Foo; Note that such an array has a dynamic lower bound and a dynamic upper bound. If I create an instance of such an array and pass it to a procedure: declare My_Array: Foo_Array (3..10) begin Do_Something (My_Array); end; then the procedure Do_Something receives both bounds of the array, 3 and 10, which it can read with the 'First and 'Last attributes. A declaration like the one above is typically done on the stack (although it doesn't have to be). An array can be allocated on the heap with "new", with, IIRC, the following syntax: new Foo_Array (3..10)
    - tedunangst 15y ago
      Thanks for the clarification. Can you create an array with variable size though? new Foo_Array(x..y) That's what I couldn't figure out how to do last I tried.
      - xlq 15y ago
        Yes. What you've written is exactly how to allocate an array of dynamic size on the heap. You can also do: declare My_Array: Foo_Array(X..Y); begin ... end;
gchpaco 15y ago
Ada 95 is a very different language from Ada 83, cleaning up a bunch of rough edges in the latter. That said I still don't really like it, for aesthetic reasons more than anything else.

whateverer 15y ago

You are right with respect ot maturity, and Ada does have some high level concurrency constructs, though I'm not well versed enough to compare them with other language's. I think a main selling point for Rust is its type system: it's more up to date from the state of the art of... the mid seventies, having Algebraic Data Types and type inference. Though it does seem to lack some of Ada's features, such as its limited support for dependent types in the form of its ranged numeric types and fixed-length array, so it may balance out. Edit: oh, and Rust has no null. I guess people still dislike verbose syntax, and you still see people making macho arguments about how they like to throw type-safety over the window for 'power', but Ada without doubt is a seriously underrated language.

jmilkbal 15y ago
Ada's verbosity is one of it's best qualities making it perfectly suited for our large, geographically distant team. There are far less questions about the purpose and meaning of code when its in Ada. Seriously! And to boot the documentation writers have fewer problems determine this either since it's all spelled out in plain language. Of course this applies some to Pascal, Oberon and Modula for example, but they are missing other things that make Ada a great choice.

kibwen 15y ago

I don't have any experience with Ada, and I don't intend to refute your points. Nor do I have oodles of experience with either Rust or Go. However, as I see it, the problem with our current language ecosystem isn't "we lack a safe, fast, low-level language in which to implement things"; as you've pointed out, we've long had Ada. Instead, the problem is "people are using C++ to laboriously construct applications that, while not safety-critical, still require a high degree of reliability". This is a social problem rather than a technical one, and it probably has more to do with path dependence and resistance to unfamiliarity than with the technical merits of the modern iterations of either language. In a perfect world, perhaps we'd be using Ada for all tasks that currently require C++. However, the fact that we're still using C++ over Ada suggests to me that there is still room for new languages in this area. I agree that it's sad to see so much redundancy and duplication of effort. But if the end result of all of this is that future applications are written in a more reliable language, isn't that still a net win for society, regardless of what that language is?

jk4930 15y ago

I get the feeling that Ada could receive some hacker love, see the discussion in this thread (4 days ago): http://news.ycombinator.com/item?id=3774156 http://news.ycombinator.com/item?id=3774156