5 ms·

By "north star" I mean the guiding principle that other aspects are sacrificed for. A heuristic might be: "[Lang] would not be [lang] without [aspect]." I'm su

By "north star" I mean the guiding principle that other aspects are sacrificed for. A heuristic might be: "[Lang] would not be [lang] without [aspect]." I'm sure that the Rust team wants Rust to be a good language for large-scale engineering, but it's not their north star; "fearless concurrency" is probably the closest. For example, Rust is willing to sacrifice simple syntax and fast compile times to achieve more safety; Go is not. I don't know enough about the other languages to speak confidently about them, but if you can point me to any source materials (i.e. articles or talks by the language creators) that discuss large-scale engineering, I'd be interested to read them!

kbenson 5y ago
> it's not their north star; "fearless concurrency" is probably the closest. That's just a more recent slogan to succinctly express what their real north star means. Their real north star is "safety and correctness", and like all languages, they push to make the most important thing to them easy and approachable. Here's the thing, I'm not sure as a project saying your focus is large scale engineering and pushing towards that actually gets you closer to the desired result in the end than pushing for safety and correctness instead. I could fully see a language that pushes for safety and correctness eventually being a much better and easier to use choice when evaluating with respect to large scale engineering, because those are extremely important to large scale engineering.
- nemo1618 5y ago
  Safety and correctness certainly are important -- but they're also orthogonal to maintainability (among other values)! It's good to have most of the core values in common, but a language's guiding principle manifests in many small ways that can be very compelling in aggregate. Go's weird capital-letter namespace visibility rule is a great example of this: it has nothing to do with safety or correctness, but it's enormously helpful for getting your bearings in unfamiliar code, because it localizes an important piece of information, saving you a context-switch. Sure, another language might hit upon this feature incidentally (Rust has conventions around capitalization, and IIRC Haskell enforces it to some degree), but how many languages will chance upon all of the little things that make for a great engineering language?
  - Jtsummers 5y ago
    I keep writing poor tutorials (due to space) of Ada here. Check out https://learn.adacore.com/ https://learn.adacore.com/ for more. Overall I like Go, but for software engineering in the large Ada, in contrast to Go, has: Explicit separation of specification and implementation of packages and types making it easier to shard the work out to numerous individuals and teams. What a package exports is explicit, not the result of case conventions. package Foo is procedure Bar(N : in Integer); -- exported private procedure Baz(N : out Integer); -- unexported end Foo; package body Foo is -- implementations of the above end Foo; Generics from day 1, which enabled a set of collection packages similar to C++'s STL in Ada 2005 among other things. Tasks, similar to Go's goroutines, but have a lot of additional guarantees and behaviors that have to be made explicit in Go. Protected objects and protected types which permit you to write code without explicitly acquiring/releases mutexes and using condition variables. Design-by-contract with SPARK/Ada becoming a proper subset of Ada in Ada 2012.
  - kbenson 5y ago
    > but they're also orthogonal to maintainability Not entirely. Some amount of maintainability is fixing mistakes that result in less correct or safe programs. By reducing occurrences of these classes of problems later, you're reducing the maintainability burden. It's the same thing that makes a language with a type system more maintainable in the long run. Eliminating classes of errors pays dividends later. The decision to make is whether the extra effort at the time of creation is worth that reduction. Depending on the type of software, it's expected lifetime, and how many people are expected to use it, that may differ. For large scale engineering, I imagine the extra effort required up front is almost always worth it.
pjmlp 5y ago
https://www.amazon.com/Eiffel-Language-PRENTICE-HALL-OBJECT-ORIENTED/dp/0132479257 https://www.amazon.com/Eiffel-Language-PRENTICE-HALL-OBJECT-... > Quickly emerging as the language of choice for developers of quality software, this guide explains how the Eiffel language combines rigorous software engineering principles with advanced object-oriented techniques. It reveals the simplicity, consistency, and blend of various powerful mechanisms in Eiffel, including: an object-oriented structure based on classes ; multiple and repeated inheritance information hiding assertions to guarantee, document, and test the correctness of software components; strong typing backed by support for generic classes; dynamic binding a highly dynamic run-time model supporting garbage collection renaming and redefinition facilities . . . disciplined exception handling and support for persistent objects. As both an implementation language and a high-level notation for analysis and design, Eiffel emphasizes the industrial production of reusable software components. Written for software designers, analysts, and programmers. https://www.eiffel.com/ https://www.eiffel.com/

kbenson 5y ago

> it's not their north star; "fearless concurrency" is probably the closest. That's just a more recent slogan to succinctly express what their real north star means. Their real north star is "safety and correctness", and like all languages, they push to make the most important thing to them easy and approachable. Here's the thing, I'm not sure as a project saying your focus is large scale engineering and pushing towards that actually gets you closer to the desired result in the end than pushing for safety and correctness instead. I could fully see a language that pushes for safety and correctness eventually being a much better and easier to use choice when evaluating with respect to large scale engineering, because those are extremely important to large scale engineering.

nemo1618 5y ago
Safety and correctness certainly are important -- but they're also orthogonal to maintainability (among other values)! It's good to have most of the core values in common, but a language's guiding principle manifests in many small ways that can be very compelling in aggregate. Go's weird capital-letter namespace visibility rule is a great example of this: it has nothing to do with safety or correctness, but it's enormously helpful for getting your bearings in unfamiliar code, because it localizes an important piece of information, saving you a context-switch. Sure, another language might hit upon this feature incidentally (Rust has conventions around capitalization, and IIRC Haskell enforces it to some degree), but how many languages will chance upon all of the little things that make for a great engineering language?
- Jtsummers 5y ago
  I keep writing poor tutorials (due to space) of Ada here. Check out https://learn.adacore.com/ https://learn.adacore.com/ for more. Overall I like Go, but for software engineering in the large Ada, in contrast to Go, has: Explicit separation of specification and implementation of packages and types making it easier to shard the work out to numerous individuals and teams. What a package exports is explicit, not the result of case conventions. package Foo is procedure Bar(N : in Integer); -- exported private procedure Baz(N : out Integer); -- unexported end Foo; package body Foo is -- implementations of the above end Foo; Generics from day 1, which enabled a set of collection packages similar to C++'s STL in Ada 2005 among other things. Tasks, similar to Go's goroutines, but have a lot of additional guarantees and behaviors that have to be made explicit in Go. Protected objects and protected types which permit you to write code without explicitly acquiring/releases mutexes and using condition variables. Design-by-contract with SPARK/Ada becoming a proper subset of Ada in Ada 2012.
- kbenson 5y ago
  > but they're also orthogonal to maintainability Not entirely. Some amount of maintainability is fixing mistakes that result in less correct or safe programs. By reducing occurrences of these classes of problems later, you're reducing the maintainability burden. It's the same thing that makes a language with a type system more maintainable in the long run. Eliminating classes of errors pays dividends later. The decision to make is whether the extra effort at the time of creation is worth that reduction. Depending on the type of software, it's expected lifetime, and how many people are expected to use it, that may differ. For large scale engineering, I imagine the extra effort required up front is almost always worth it.

pjmlp 5y ago

https://www.amazon.com/Eiffel-Language-PRENTICE-HALL-OBJECT-ORIENTED/dp/0132479257 https://www.amazon.com/Eiffel-Language-PRENTICE-HALL-OBJECT-... > Quickly emerging as the language of choice for developers of quality software, this guide explains how the Eiffel language combines rigorous software engineering principles with advanced object-oriented techniques. It reveals the simplicity, consistency, and blend of various powerful mechanisms in Eiffel, including: an object-oriented structure based on classes ; multiple and repeated inheritance information hiding assertions to guarantee, document, and test the correctness of software components; strong typing backed by support for generic classes; dynamic binding a highly dynamic run-time model supporting garbage collection renaming and redefinition facilities . . . disciplined exception handling and support for persistent objects. As both an implementation language and a high-level notation for analysis and design, Eiffel emphasizes the industrial production of reusable software components. Written for software designers, analysts, and programmers. https://www.eiffel.com/ https://www.eiffel.com/