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

41–50 of 178 posts

Re: The Bosque Programming Language

#41

Post by curryhoward »

jleahy wrote: post #37
curryhoward wrote: post #32

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

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

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

Not sure I understand what you're suggesting. I was asking for a language with dependent types (or anything that isn't just another procedural/OOP language). Such a language could use any runtime, whether it be the JVM or anything else.

Re: The Bosque Programming Language

#42

Post by rossng »

The language doesn't seem like the interesting part here. Bosque appears mainly to be a vehicle for exploring a different way of thinking about compiler IR. From the MSR site[1]:

> In the Bosque project we ask the question of what happens if the IR is designed explicitly to support the rich needs of automated code reasoning, IDE tooling, etc. With this novel IR first perspective we are exploring a new way to think about and build a language intermediate representation and tools that utilize it. Our initial experiments show that this empowers a range of next-generation experiences including symbolic-testing, enhanced fuzzing, soft-realtime compilation with stable GC support, API auto-marshaling, and more!

[1] https://www.microsoft.com/en-us/research/project/bosque-prog...

Re: The Bosque Programming Language

#43

Post by mhh__ »

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…

Arguably garbage collection is a huge boon to productivity though. I agree about the first two, but I think the whole memory allocation debate is too contextual to be an issue in the general case. Big projects tend to have customized memory allocators which make most benchmarks usefulness dubious - that and reference counting can be nondeterministic too (you deallocate an object triggering a huge chain of frees).

Re: The Bosque Programming Language

#44

Post by stared »

> is a breakthrough research project

[citation needed]

In all seriousness, each time when I see a project self-describing itself as a breakthrough, it is a red flag. No matter if it is programming, mathematics, arts, or anything. (Of course, unless used ironically.)

Either, it is a huge ego and a total lack of self-skepticism (vide Stephen Wolfram's recent Theory of Everything) or fiddling of the marketing department.

Re: The Bosque Programming Language

#46

Post by HelloNurse »

still_grokking wrote: post #25

Looks like Stainless Scala, mixed with Rust, and given a C++ syntax. This mix looks interesting as such. But of course Wadler's law applies: Why THIS syntax? Looks like a blast-from-the-past, bloatty and complex. Modern languages go mostly for some more lightweight look-and-feel. Usually more "pythonic". This would be imo also here the better idea.

A lot of punctuation, most of it painful:

  * arrow and double arrow
  * arrow and double colon
  * apparently random semicolons
Not all syntax choices are bad (for example, consistently declaring types after things with a colon as a separator), but certainly not coherent and elegant enough to compete with Python, C/C++/Java, Lisp, etc.

Re: The Bosque Programming Language

#49

Post by m0llusk »

mpoteat wrote: post #2

This is pretty cool. This project has a long way to go before it's mature, but as someone who uses Typescript every day professionally, the promise of the ease and safety of Typescript coupled with the speed of C++ is really compelling.

The core ideas are kind of interesting, but in my experience where cool new language ideas come apart at the seams is when they are built out to completeness with libraries, packaging, configuration management and the rest.

> ... The current focus of the Bosque project is core language design. As a result there is no support for packaging, deployment, lifecycle management, etc. ...

So there is nothing solid there yet and thus significant risk that like many other languages this offering will suffer metastasis, bloat, and conflicts as it grows to be useful for solving real problems.

Re: The Bosque Programming Language

#50

Post by terhechte »

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

> 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 official support.

Post reply on HN