Live data from Hacker News

The Bosque Programming Language

github.com

131–140 of 178 posts

Re: The Bosque Programming Language

#131

Earlier quoted context omitted.

> I personally would welcome a new language that gives me full-spectrum dependent types with great tooling and moderate performance. I'd propose to have a look at Swift. It is very similar to Rust in many aspects (particularly the type system), with slower performance (due to some of the abstractions). The tooling on macOS is already really good, on Linux it is getting there, and on Windows the next release will add…

I don't see how Swift is similar to Rust -- it's a garbage collected, OO language, not really appropriate for low level / systems level programming. It's a nice looking language for what it is, with some nicer modern features in its type system etc, but its niche is not the same as Rust.

It is for Apple, where the long term roadmap is for Swift to become the systems programming languages of their platforms.

Re: The Bosque Programming Language

#132

Yeah, but what is it? > The Bosque programming language is a breakthrough research project from Microsoft Research. Tells me nothing useful about it. > Bosque simultaneously supports a high productivity development experience expected by modern cloud developers, coming from say a TypeScript/Node stack, It's a web language then? > while also providing a resource efficient and predictable runtime with a performance pro…

It sounds like MS Rust.

Re: The Bosque Programming Language

#133

Earlier quoted context omitted.

... and Pascal ! Many languages are superior to C/C++ C/C++ just wins from the amount of available libraries and high-quality implementations.

I don't understand what people are trying to categorize when they say C/C++. They're incredibly different languages. It's hard to find similarities between C and modern C++ (C++2x flavor). If we put C and C++ under the same umbrella, why not put Java there too? I just think when you say C/C++ you need to clarify what exactly do you mean by that.

C/C++ => C and C++, simple plain English grammar simplification.

Used all over the place in ISO C++ papers, official documentation from all compiler vendors, long gone famous magazines like 'The C/C++ Users Journal', reference books well respected in the C++ community,....

Yet a couple of people still insist into making a point out of it, but don't start one when Java/C, Java/C++, C#/C++, Python/C,..., gets written somewhere.

Re: The Bosque Programming Language

#134
post #60

Earlier quoted context omitted.

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 gra…

To me it just seems that you're arguing semantics... I mean, what is the difference between "stack memory" and "heap memory allocated to store the stack", other than the fact that the OS preallocates the first one for you by default? To me, "the stack" and "a stack-like data structure stored in the heap that is used as a stack to replace what would otherwise be the stack" is functionally the same thing... You know th…

    To me it just seems that you're arguing semantics...
The most important type of argument to have. If you don't agree on semantics, no other discussion is worth having, as you will never know if the other party actually agrees with you or not.

    I mean, what is the difference between "stack memory" and "heap memory allocated to store the stack", other than the fact that the OS preallocates the first one for you by default?
That is a pretty major difference with wide-ranging effects on program performance right there.

    To me, "the stack" and "a stack-like data structure stored in the heap that is used as a stack to replace what would otherwise be the stack" is functionally the same thing...
System-level error messages and memory managers both disagree.

    You know that (given appropriate conditions) you can just allocate stack frames wherever you want and point your stack pointer to whatever you want, whenever you want, right?
Yes. And once you do, that memory becomes functionally privileged from the perspective of your allocation strategy.

    This is what the Go compiler does to prevent Go programs from running out of the stack space provided by the OS by default. But AFAIK they don't advertise that Go programs use constant stack space and you don't have to worry about out-of-stack issues...
Of course not. Because they actually use that space as stack space, to store function activation records.

Re: The Bosque Programming Language

#135

Earlier quoted context omitted.

The issue here is the link; it doesn't do a great job of explaining _why_ Bosque is breakthrough. A bold claim like that needs evidence. What's special here? From glancing at the code snippets--which is really all we have in the way of evidence on that page--I see an interesting language concept, but it's not entirely here how that relates to the initial claim. There are definitely some interesting elements, though.…

This is a much better link. Bold vague buzzwords on the GitHub page ("a breakthrough research project", "a high productivity development experience", "an unprecedented tooling ecosystem") inflict antagonistic mood towards the whole project.

Gets me pretty excited though. MS has a track record of productive dev experience and great tooling ecosystems. I’m actually looking forward playing with this!

Re: The Bosque Programming Language

#136
post #132

Yeah, but what is it? > The Bosque programming language is a breakthrough research project from Microsoft Research. Tells me nothing useful about it. > Bosque simultaneously supports a high productivity development experience expected by modern cloud developers, coming from say a TypeScript/Node stack, It's a web language then? > while also providing a resource efficient and predictable runtime with a performance pro…

It sounds like MS Rust.

Microsoft Research is also working on Verona, which seems closer to Rust than this language, to me anyway.

Re: The Bosque Programming Language

#137
post #101

The snark and meanness in this HN thread is totally uncalled for and why people don't publish code. I can't believe this thread is on the front page together with https://news.ycombinator.com/item?id=23157783 . Go read that, especially the ending comments on open source. > I made this thing that I thought was cool and I gave it away, and what I got back were occasionally friendly people who nicely requested things fr…

The issue here is the link; it doesn't do a great job of explaining _why_ Bosque is breakthrough. A bold claim like that needs evidence. What's special here? From glancing at the code snippets--which is really all we have in the way of evidence on that page--I see an interesting language concept, but it's not entirely here how that relates to the initial claim. There are definitely some interesting elements, though.…

Stronger assumptions at compile time allows for higher quality code, invariants are amazing.

Re: The Bosque Programming Language

#138
post #101

The snark and meanness in this HN thread is totally uncalled for and why people don't publish code. I can't believe this thread is on the front page together with https://news.ycombinator.com/item?id=23157783 . Go read that, especially the ending comments on open source. > I made this thing that I thought was cool and I gave it away, and what I got back were occasionally friendly people who nicely requested things fr…

The issue here is the link; it doesn't do a great job of explaining _why_ Bosque is breakthrough. A bold claim like that needs evidence. What's special here? From glancing at the code snippets--which is really all we have in the way of evidence on that page--I see an interesting language concept, but it's not entirely here how that relates to the initial claim. There are definitely some interesting elements, though.…

> see an interesting language concept, but it's not entirely here how that relates to the initial claim.

I didn't see any concept which wouldn't be practiced in PL design for decades. Yeah, they may not be widely known, but suggesting that "structural, nominal, and union" types are anywhere near any kind of "breakthrough" is just too much. If anything, the language seems conservative in its design rather than novel.

EDIT: actually, this looks like a much better link, in that there's at least some meat to chew on: https://github.com/microsoft/BosqueLanguage/blob/master/docs...

Re: The Bosque Programming Language

#139
post #137

Earlier quoted context omitted.

The issue here is the link; it doesn't do a great job of explaining _why_ Bosque is breakthrough. A bold claim like that needs evidence. What's special here? From glancing at the code snippets--which is really all we have in the way of evidence on that page--I see an interesting language concept, but it's not entirely here how that relates to the initial claim. There are definitely some interesting elements, though.…

Stronger assumptions at compile time allows for higher quality code, invariants are amazing.

> invariants are amazing

They are, as are pre- and post-conditions; they're not, however, a breakthrough in language design by any means.

https://en.wikipedia.org/wiki/Eiffel_(programming_language)

Re: The Bosque Programming Language

#140
post #112

Earlier quoted context omitted.

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

Have a look at Nim: https://nim-lang.org/ It's a system language that's focused on readability and performance. It has OOP but isn't focused on it, and has some of the best AST metaprogamming out there built in as a core principle, so it's easy to extend the language. Strong static typing with type inferrence, specific type for garbage collecting (ref type) - everything else is on the stack by default, or you can man…

The GP asked for a single key features: dependent type. Nim doesn't have them and never will, why bring it in the discussion ?

Sadly, “Look at Nim” seems to be the new “rewrite it in Rust”…

Post reply on HN