Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Bosque Programming Language

github.com

Post reply on HN
Print view View original

31–40 of 178 posts

Re: The Bosque Programming Language

#31

Post by dkersten »

xixixao wrote: post #3

I gotta say you lost me at args->allof It’s 2020, if you’re really serious about building a new language, shouldn’t you at least pick a reasonable naming case convention? (allOf, AllOf, all_of, all-of would all work) (Not talking about the fact that allOf doesn’t seem very consistent with other languages...)

My question is why -> instead of . for method/field access. I see almost all of the examples using -> but a few use . but unless there’s a difference (like how in C++ -> is a pointer dereference access), I think -> just adds noise to the syntax needlessly .

The documentation doesn’t appear to explain when to use one over the other, or perhaps . is a typo.

Re: The Bosque Programming Language

#32

Post by curryhoward »

nonsince wrote: post #27

At this point any new systems language aiming at productivity has to prove itself not just superior to C++, but superior to Rust, without being significantly worse in any aspect. It’s already suspicious by virtue of having a hand-wavy "Int" type (what size/signedness is that?) and it appears to be object-oriented (so we have to rely on compiler optimisations to remove dynamic dispatch) and garbage-collected (so by de…

> It’s already suspicious by virtue of having a hand-wavy "Int" type (what size/signedness is that?) and it appears to be object-oriented (so we have to rely on compiler optimisations to remove dynamic dispatch) and garbage-collected (so by default any non-trivial type is heap-allocated). These are just ways in which it is worse than Rust as far as performance goes, since "ergonomics"/"productivity" is so subjective.

While I agree that this language doesn't seem to be differentiated enough to compete, I disagree with your apparent premise that new languages need to be as fast as Rust. I personally would welcome a new language that gives me full-spectrum dependent types with great tooling and moderate performance. There are many aspects to programming languages beyond raw speed.

The world has enough cookie cutter procedural and OOP languages. I'd love to see a new language from a different paradigm succeed.

Re: The Bosque Programming Language

#33

Post by pjmlp »

tomp wrote: post #23
mrkmarron wrote: post #14

Hi, project owner here, great to see this on HN and always happy to hear from folks here and on the GitHub repo. We also have a webinar with Q&A scheduled for Thursday morning ( https://note.microsoft.com/MSR-Webinar-Programming-Languages... ) which may be of interest as well.

Can you explain some further things about this languages? 1. How does the GC work? It says "novel reference counting" does that mean it leaks cycles or handles them (either by also tracing or preventing them statically)? 2. Is that the only thing it does to provide a C++-like "resource efficient and predictable runtime"? After all, that's basically Swift (or Python+static types). I think the main improvement that C++…

Actually that was already a thing in Mesa/Cedar, Modula-3, Oberon language family and Eiffel.

Sadly Java has not taken this into account, nor AOT support out of the box, and now it is catching up with it.

Re: The Bosque Programming Language

#34

Post by occamrazor »

nonsince wrote: post #27

At this point any new systems language aiming at productivity has to prove itself not just superior to C++, but superior to Rust, without being significantly worse in any aspect. It’s already suspicious by virtue of having a hand-wavy "Int" type (what size/signedness is that?) and it appears to be object-oriented (so we have to rely on compiler optimisations to remove dynamic dispatch) and garbage-collected (so by de…

A better C++ could be an attractive proposition. There are precedents of succession languages which improve on existing ones, like eg. Coffeescript, Kotlin (at least at the beginning), Reason.

Re: The Bosque Programming Language

#35

Post by timon999 »

wizeman wrote: post #20

> As a result of these design choices there is always a single unique and canonical result for any Bosque program. This means that developers will never see intermittent production failures or flaky unit-tests! So Bosque programs are not allowed to receive input from the outside world? > When an error occurs in deployed mode the runtime simply aborts, resets, and re-runs the execution in debug mode to compute the pre…

The Bosque paper says the following:

> JavaScript took an interesting step by decoupling the core compute language in the JS specification from the IO and event loop which are provided by the host [...]. We take the same approach of decoupling the core compute language, BOSQUE, from the host runtime which is responsible for managing environmental interaction.

So it seems that Bosque doesn't do IO directly, but instead specifies how a given input is mapped to some output.

Re: The Bosque Programming Language

#36

Post by wizeman »

dkersten wrote: post #28
wizeman wrote: post #20

> As a result of these design choices there is always a single unique and canonical result for any Bosque program. This means that developers will never see intermittent production failures or flaky unit-tests! So Bosque programs are not allowed to receive input from the outside world? > When an error occurs in deployed mode the runtime simply aborts, resets, and re-runs the execution in debug mode to compute the pre…

> Again, no interaction with the outside world? Or are all inputs recorded during the entire execution? Inputs would need to be cached (eek, if there’s a lot of state loaded from external services or databases, or if that state is sensitive and you want to control where it may get persisted), but more importantly, output needs to be not output on the rerun (eg database writes and api calls). > So recursion cannot dep…

Sure, but they are not simply saying that they do not allow unbounded loops, that is what some languages do already, like Coq.

They are saying that the compiled program "uses constant stack space, eliminating any possible out-of-stack issues".

This seems impossible unless recursion cannot depend in any way on inputs from the outside world.

Mind you, even if you have constant stack space that does not mean that you won't run into an out-of-stack issue.

You can still run out of stack space if it is constant, because it might not fit in memory. It would probably be trivial to construct such a program.

Furthermore, a program with constant stack space may even run out of stack space during execution (due to the kernel overcommitting memory, for example).

Re: The Bosque Programming Language

#37

Post by jleahy »

curryhoward wrote: post #32
nonsince wrote: post #27

At this point any new systems language aiming at productivity has to prove itself not just superior to C++, but superior to Rust, without being significantly worse in any aspect. It’s already suspicious by virtue of having a hand-wavy "Int" type (what size/signedness is that?) and it appears to be object-oriented (so we have to rely on compiler optimisations to remove dynamic dispatch) and garbage-collected (so by de…

> It’s already suspicious by virtue of having a hand-wavy "Int" type (what size/signedness is that?) and it appears to be object-oriented (so we have to rely on compiler optimisations to remove dynamic dispatch) and garbage-collected (so by default any non-trivial type is heap-allocated). These are just ways in which it is worse than Rust as far as performance goes, since "ergonomics"/"productivity" is so subjective.…

For ‘moderate performance’ surely JVM based languages are what you’re looking for? There’s great tooling and a very low barrier to creating new languages.

Creating a new systems programming language like C++, Rust or Zig is by contrast a lot more effort and means having significantly worse support for debugging and IDEs unless you put a lot of effort in (generating good DWARF debug data for a new language is hugely complex).

Re: The Bosque Programming Language

#38

Post by wizeman »

timon999 wrote: post #35
wizeman wrote: post #20

> As a result of these design choices there is always a single unique and canonical result for any Bosque program. This means that developers will never see intermittent production failures or flaky unit-tests! So Bosque programs are not allowed to receive input from the outside world? > When an error occurs in deployed mode the runtime simply aborts, resets, and re-runs the execution in debug mode to compute the pre…

The Bosque paper says the following: > JavaScript took an interesting step by decoupling the core compute language in the JS specification from the IO and event loop which are provided by the host [...]. We take the same approach of decoupling the core compute language, BOSQUE, from the host runtime which is responsible for managing environmental interaction. So it seems that Bosque doesn't do IO directly, but instea…

From what you're quoting and from what you're saying, it seems that Bosque (the core compute language) can indeed receive input from the outside world, even though it comes from the runtime (which Bosque considers the outside world).

Which means that some of the claims I quoted don't seem entirely accurate, and the other one only seems possible if the input (and possibly some state) is recorded...

Re: The Bosque Programming Language

#39

Post by the_duke »

mrkmarron wrote: post #14

Hi, project owner here, great to see this on HN and always happy to hear from folks here and on the GitHub repo. We also have a webinar with Q&A scheduled for Thursday morning ( https://note.microsoft.com/MSR-Webinar-Programming-Languages... ) which may be of interest as well.

The README is full of buzz words, and yet does not explain at all how these supposedly amazing "breakthroughs" have been achieved.

The code samples look a lot like Swift, with some C++/Rust/Scala/general ML sprinkled in, so I can't see anything special here directly.

Especially relating to the promise of being as easy as Typescript but as efficient as C++/Rust/etc.

If there are great ideas in here, I'm happy to hear about them, but they should be at least be mentioned and referenced clearly.

Re: The Bosque Programming Language

#40

Post by gliese1337 »

wizeman wrote: post #36
dkersten wrote: post #28

Earlier quoted context omitted.

> Again, no interaction with the outside world? Or are all inputs recorded during the entire execution? Inputs would need to be cached (eek, if there’s a lot of state loaded from external services or databases, or if that state is sensitive and you want to control where it may get persisted), but more importantly, output needs to be not output on the rerun (eg database writes and api calls). > So recursion cannot dep…

Sure, but they are not simply saying that they do not allow unbounded loops, that is what some languages do already, like Coq. They are saying that the compiled program "uses constant stack space, eliminating any possible out-of-stack issues". This seems impossible unless recursion cannot depend in any way on inputs from the outside world. Mind you, even if you have constant stack space that does not mean that you wo…

There is a difference between "running out of stack memory" and "running out of memory used to store stack-structured data".

Any recursive algorithm can be mechanically transformed into an equivalent iterative algorithm that uses only a single activation record on the system call stack. If you perform that transformation on an entire program, then the total depth of the call stack is a static property of the call graph in the source code, and it does not depend in any way on run-time inputs from the outside world. The only way to run out of stack space then would be to write a program whose static, constant stack space requirements are indeed too large for the machine it is run on.

Transformed algorithms may, of course, require "manually" tracking data in a stack structure, and use of such a data structure may indeed result of running out of memory depending on what inputs are provided, but that's just "running out of memory, which we happened to be using to hold a stack-like data structure", not "running out of stack".

Post reply on HN