News for hackers. Stuff that matters.
Re:Ada: a C Developer's Perspective by JohnStrange on Thursday April 27, 2017 @04:10AM (#14209973)
Ada is so stable and backwards compatible that old libraries will work just fine, unless they have external dependencies or depend on things that change fast in the outside world.

For me personally Rust is not a good Ada replacement, because 1) it has the usual obscure syntax - maybe to attract C++ programmers, who seem to like obscurity -, 2.) many semantic tricks and borrower idiosyncrasies that makes it harder to write, read and maintain than idiomatic Ada, and 3) it's fast changing. The good thing about Ada is that it is self-documenting, it's almost impossible to intentionally or unintentionally obfuscate it, and once you've written a program it will continue to work 10-20 years later.

Re:Ada: a C Developer's Perspective by cormacrelf on Thursday April 27, 2017 @05:22AM (#14210214)
I think a lot of people would disagree with #1. There was a discussion on /r/technology yesterday where people were discussing how it was exactly the other way round – Ada has weird syntax (so many English words!) which slows adoption, and Rust is C-like enough that the target market of C/C++ users can pick it up, syntactically at least. I'm saying this having done a distributed systems course in Ada. It felt like writing a novel, about some very awkward people announcing every action as they did it. Rust, on the other hand, feels like pair programming with a wizard (the compiler) who knows how to write really great C++ and has many tips to share.

Rust's syntax is, like many new languages as they are invented, essentially a pick of the crop of the best syntax ideas from other languages. 'Best' is probably debatable but familiarity is certainly not. Type annotations are basically Scala syntax. Class::method(), ditching `return` in favour of last-line expressions and the || {} closure syntax are all pretty close to Ruby. Structs/enums are also basically Scala. `instance.method()`, and pretty much the rest of the language, is universal.

It's true, Scala syntax for types is the weirdest part, but once you know what it means it's not hard to decipher. Much easier than trying to figure out function pointers in C, if you ask me.

#2 is probably true, but that's the cost of staying close to the metal. Rust makes all your memory access very explicit, rather than bundling it up in the standard/GC or leaving it to you. But it's a model you can get used to, and it has value as a mental model aside from its application in Rust.

#3 – well. Ada was young once. Rust is incredibly stable for a project designed by a distributed community of Mozilla and a ton of volunteers.

Re:Ada: a C Developer's Perspective by johncolanduoni on Thursday April 27, 2017 @06:27AM (#14210454)
> Structs/enums are also basically Scala.

How so? Scala class bodies are a mix of ordered constructor statements and unordered declarations/method definitions, while Rust structs can only declare fields (without any sort of initial value). Scala enumerations (both scala.Enumeration and the more common sealed class versions) look nothing like a Rust enum; if anything Rust enums look like ML/Haskell algebraic type definitions.

> It's true, Scala syntax for types is the weirdest part, but once you know what it means it's not hard to decipher.

The part of the type syntax that is like Scala (i.e. the colons and arrows) has its origins in the ML family IIRC. Rust's bootstrapping compiler was written in OCaml, so I suspect that was in fact the inspiration.

Re:Ada: a C Developer's Perspective by cormacrelf on Thursday April 27, 2017 @06:42AM (#14210504)
Ah, I see it's been a while since I've used Scala. I think I should have referred to case classes. Weak point nonetheless.

I did fail to mention the other very Scala thing: match expressions. Most complicated Rust match expressions could almost compile without errors in Scala.

Re:Ada: a C Developer's Perspective by adrianN on Thursday April 27, 2017 @05:11AM (#14210180)
If you start a project today that depends on a library that was last updated in 2002, then may God help you.
Re:Ada: a C Developer's Perspective by JohnStrange on Thursday April 27, 2017 @06:10AM (#14210390)
Why? Ada libraries from 2002 without outside dependencies work perfectly fine. I'm using that old libraries all the time. Ada has been designed specifically for that, it's been used in the aviation industry that runs the same code for 20+ years minimum.

That you think otherwise only shows that you've never seriously used Ada in a larger project.

Re:Ada: a C Developer's Perspective by maxxxxx on Thursday April 27, 2017 @10:34AM (#14211739)
The keyword is "without outside dependencies " . Most of us have to integrate many systems and there outdated libraries are a big problem.
Re:Ada: a C Developer's Perspective by adrianN on Thursday April 27, 2017 @08:11AM (#14210847)
The last version of DOS also works really well for the things it was designed for. You still wouldn't start new projects targeting DOS if you could help it, even if it would satisfy your current requirements.
Re:Ada: a C Developer's Perspective by nickpsecurity on Thursday April 27, 2017 @09:40AM (#14211360)
Well, we're talking a safe language. So, if want an archaic red herring, you'd be better bringing up Burroughs written in an Ada predecessor that was immune to most forms of code injection or crashes in 1961. If you want small and Ada, then Martes RTOS is one written in Ada that's still around. For small and secure, the Muen separation kernel can handle it.
Re:Ada: a C Developer's Perspective by mondoshawan on Thursday April 27, 2017 @10:07PM (#14216402)
Actually, I would, if my needs were simple enough. Rarely is it necessary to have much more in embedded fields. Have a look at MDOS, a modern reimplementation of DOS used in many modern embedded cases.

Edit: which is apparently now called adelian.

Re:Ada: a C Developer's Perspective by andrepd on Thursday April 27, 2017 @06:28AM (#14210459)
Well, why? Why would a library be bad just because it hasn't been updated in 15 years? Does it spoil? Maybe it doesn't need to be updated.
Re:Ada: a C Developer's Perspective by dagw on Thursday April 27, 2017 @09:43AM (#14211378)
The current RFC for the base LDAP protocol is from 2006, so that is at least 4 years of potential updates/changes that are missing from the library.
Re:Ada: a C Developer's Perspective by dorfsmay on Thursday April 27, 2017 @07:04AM (#14210591)
Environment rot, yes (protocol changes, bug that weren't found yet by the time that library come out, etc...).
Re:Ada: a C Developer's Perspective by user5994461 on Thursday April 27, 2017 @09:12AM (#14211178)
There are environment and protocols that don't change much. Typically the places where Ada is used.
Re:Ada: a C Developer's Perspective by maxxxxx on Thursday April 27, 2017 @10:33AM (#14211718)
Libraries that interface with other systems like LDAP go bad over time. Either you are missing bug fixes or new features.
Re:Ada: a C Developer's Perspective by btrask on Thursday April 27, 2017 @05:26AM (#14210228)
Same goes for a library that was last updated 5 minutes ago though.
Re:Ada: a C Developer's Perspective by throwaway7645 on Thursday April 27, 2017 @05:37AM (#14210276)
Good point. I'd rather pick the one that hasn't needed an update in 20 years unless they're assuming it is bitrotten.
Re:Ada: a C Developer's Perspective by adrianN on Thursday April 27, 2017 @01:01PM (#14213027)
How do you distinguish between "hasn't needed an update" and "was abandonded by the developer"?
Re:Ada: a C Developer's Perspective by throwaway7645 on Thursday April 27, 2017 @09:40PM (#14216302)
Probably isn't always easy.
Re:Ada: a C Developer's Perspective by bsder on Thursday April 27, 2017 @08:56PM (#14216126)
Welcome to VB6.