Well guys, looks like Microsoft has dropped their latest research language, called Bosque. https://www.microsoft.com/en-us/research/project/bosque-programming-language/#!publications

Only have a moment for a scan. The paper starts off promising in section 2. Section 3 presents what just looks like a modern, typed language. Section 4 suggests that Bosque has somewhat non-strict execution semantics. That's something. Am I missing something else interesting?

"..the initial goal for Bosque is to build automated zero-effort code validation, automated SemVer checking, and compilation to use SIMD hardware, such as AVX or SSE." -- https://www.theregister.co.uk/2019/04/18/microsoft_bosque_programming_language

Here’s my summary. The language in the paper is grandiose, which I found off-putting. If you wade through that, here’s what you find Bosque contains, in some rough order of goodness/novelty (most to least): 1. Primitives for collection operations (

map

,

filter

,

fold

etc)—no looping constructs. (Recursion is allowed but discouraged—you have to mark callsites to recursive functions with

rec

.) 2. Those collection primitives are packaged with pre- and post- conditions to ease verification. (The verification story is a bit hand-wavy though.) 3. Execution produces deterministic results, but there’s no guarantees on intermediate execution order. If a piece of code throws errors in parallel, which error is thrown may be non-deterministic, but that some error is thrown is deterministic. 4. Function arguments are (apparently) matched by name and by type first, and then by position. This is an idea I’ve wanted to explore because it’s superficially more ergonomic but there may be some tricky downsides (e.g. with complicated arg matching rules, how do you determine if an API change breaks existing code?). 5. There’s special syntax for denoting optional values that can be

none

, and syntax for allowing method calls on

none

to return

none

instead of crashing. The following ideas are extolled in the paper but I don’t think they are quite so novel or worthy: 1. Local multiple assignments to the same variable are not actually mutations of the same memory location. I’ve thought about this before: the naive version doesn’t work work all the time because where you want multiple assignment is in folds and the above semantics doesn’t work there. 2. All objects support record update syntax and record merge syntax. What’s novel here is applying this to a more traditional OO model; but its core is just plain old functional record update syntax. There’s also a field projection syntax, which is handy. 3. Well defined interface to the outside world. It’s a good idea to have an API to the OS, but the writeup makes it sound like this solves all the messy IO system call stuff when really it just pushes that mess out of scope of the language. You’ll still have to deal with it sometime. Ideas perhaps worth discarding: 1. No referential equality (that’s fine) but to support custom equality measures you simply define a field named

key

on your objects/records. You only get one of these: now you’re toast if you want a different equality metric or your equality metric wasn’t precise enough. 2. No logging. (Stated justification: when your language is deterministic you don’t need logging.)

I just read the readme on GitHub, as that's what Slashdot linked to when it announced Bosque ... it was full of TODOs. I got a bit suspicious by how Bosque proudly solves so many problems by making all heap objects read-only - okay, you reinvented Haskell in C-style syntax, but don't imagine you're the first one to do it. To me, mutability is pretty useful, so the real challenge is to figure out how to make a language that somehow retains... analyzability/comprehensibility despite the presence of mutability. I mean, without mutability you can use "hash trees" instead of hashtables, but it's not free, there's a performance hit. And then I wondered how it scales, because I didn't see monads in there...