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

81–90 of 178 posts

Re: The Bosque Programming Language

#81

Post by exdsq »

h-cobordism wrote: post #71
hhas01 wrote: post #67

Earlier quoted context omitted.

Swift is just C++ with rubberized corners. Distinctly “meh” as a language in its own right, embarrassingly knotty around its ObjC bridging (there’s a basic impedance mismatch between those two worlds), and certainly doesn’t have anything as powerful as dependent types.

> embarrassingly knotty around its ObjC bridging (there’s a basic impedance mismatch between those two worlds) I think they've done an incredible job with their ObjC interop, given said mismatch. But you're right — the person above who said that > The world has enough cookie cutter procedural and OOP languages. definitely isn't looking for Swift.

But it doesn’t have dependent types does it?

Re: The Bosque Programming Language

#82

Post by kd0amg »

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…

>> This compiles recursive functions into a CPS form that uses constant stack space, eliminating any possible Out-of-Stack issues

> So recursion cannot depend on input from the outside world?

Why would CPS prevent recursive code from doing I/O or using its results?

Re: The Bosque Programming Language

#83

Post by b3kart »

norswap wrote: post #57
throwaway_pdp09 wrote: post #24

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…

Does a language really have to aim for a specific use case?

Of course. A language isn't just syntax, it prescribes how and at what level you're solving problems. System programing languages typically expose a lot of the underlying memory management, so you can optimize it. Scripting languages provide high-level primities, specifically so you don't have to think about memory management.

Re: The Bosque Programming Language

#84

Post by hhas01 »

h-cobordism wrote: post #71
hhas01 wrote: post #67

Earlier quoted context omitted.

Swift is just C++ with rubberized corners. Distinctly “meh” as a language in its own right, embarrassingly knotty around its ObjC bridging (there’s a basic impedance mismatch between those two worlds), and certainly doesn’t have anything as powerful as dependent types.

> embarrassingly knotty around its ObjC bridging (there’s a basic impedance mismatch between those two worlds) I think they've done an incredible job with their ObjC interop, given said mismatch. But you're right — the person above who said that > The world has enough cookie cutter procedural and OOP languages. definitely isn't looking for Swift.

“I think they've done an incredible job with their ObjC interop, given said mismatch.”

Which is to say, the Swift devs have done an incredible job of solving the wrong problem.

Apple needed a modern language for faster, easier Cocoa development. What they got was one that actually devalues Apple’s 30-year Cocoa investment by treating it as a second-class citizen. Gobsmacking hubris!

Swift was a pet project of Lattner’s while he was working on LLVM that got picked up by Apple management and repurposed to do a job it wasn’t designed for.

Swift should’ve stayed as Lattner’s pet project, and the team directed to build an “Objective-C 3.0”, with the total freedom to break traditional C compatibility in favor of compile-time safety, type inference, decent error handling, and eliminating C’s various baked-in syntactic and semantic mistakes. Leave C compatibility entirely to ObjC 2.0, and half the usability problems Swift has immediately go away. The result—a modern dynamic language that feels like a scripting language while running like a compiled one, which treats Cocoa as a first-class citizen, not as a strap-on.

(Bonus if it also acts as an easy upgrade path for existing C code. “Safe-C” has been tried before with the likes of Cyclone and Fortress, but Apple might’ve actually made it work.)

Tony Hoare called NULL a billion-dollar mistake. Swift is easily a 10-million-man-hour mistake and counting. For a company that once prided itself for its perfectly-polished cutting-edge products, #SwiftLang is so very staid and awkward-fitting.

Re: The Bosque Programming Language

#85

Post by LudwigNagasena »

norswap wrote: post #57
throwaway_pdp09 wrote: post #24

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…

Does a language really have to aim for a specific use case?

It has to have at leasat one use case, otherwise it is litearlly useless. At least a use case like "Python but with static types" or "Swift but for Windows".

Re: The Bosque Programming Language

#86

Post by TomMarius »

thrower123 wrote: post #62
norswap wrote: post #57

Earlier quoted context omitted.

Does a language really have to aim for a specific use case?

It would be good for its own sake to provide some motivation for why you'd bother using it over the dozen established alternatives with mature ecosystems and tooling.

It's a language research project.

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

Re: The Bosque Programming Language

#87

Post by cmrdporcupine »

terhechte wrote: post #50
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.…

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

Re: The Bosque Programming Language

#88

Post by throwaway894345 »

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?)

This is a silly criticism. The language is brand new; they haven't gotten around to ironing out low-risk minutia like naming numeric types. Anyway, "Int" can still be well-specified even if the name doesn't indicate size (the signedness is just as clear as with Rust and C++).

> it appears to be object-oriented (so we have to rely on compiler optimisations to remove dynamic dispatch)

Not a fan of OOP or C++, but implicit dynamic dispatch isn't a property of OOP as C++ demonstrates. And to that end, Bosque seems to copy C++ in this regard, or at least the code snippets show methods annotated with "virtual".

Re: The Bosque Programming Language

#89

Post by wwright »

mhh__ wrote: post #43
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).

Even a cascading deallocation is still deterministic. It’s true that it doesn’t have hard latency guarantees, though (and true GC with hard latency guarantees is arguably more useful in many cases).

Re: The Bosque Programming Language

#90

Post by wwright »

occamrazor wrote: post #34
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.

Have you used Rust? It doesn’t have backwards compatibility with C++, but the semantic model really is very similar to modern C++, just without hundreds of the footguns.
Post reply on HN