Comment by jmilkbal | Hacker News Reader

Comment by jmilkbal | Hacker News Reader

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 Later revisions have well-though-out rationales that show off all the changes: Ada 95: http://www.adaic.org/resources/add_content/standards/95rat/r... Ada 2005: http://www.adaic.org/ada-resources/standards/ada05/ Ada 2012(!!): 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.

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?

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

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!

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.

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)

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.

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;

Hmm, I remember it being very hard, but it seems I've lost the specifics. My bad. In any case, Ada is not a language I'm excited to work with, but Go could be one.

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.

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.

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.

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

Reply on news.ycombinator.com