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

161–170 of 178 posts

Re: The Bosque Programming Language

#161

Post by goto11 »

dunk010 wrote: post #151
rossng wrote: post #42

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

I know that Microsoft are all about grabbing as much developer mindshare as possible these days, but does nobody remember Steve Yegge and is Grok system at Google? It's basically this, just ten years ago. Having the IR not throw away anything so that the tooling can have a richer interaction. I guess the best way to be successful is to bury your sources.

The Roslyn C# compiler also doesn't throw anything away - you can recreate the source from the AST, completely with white-space and comments. This is necessary to support safe refactorings, so I don't think this is a novel idea. IntelliJ must have supported something like this for ages.

Bosque sounds like something beyond Roslyn, but it is not clear to me what.

Re: The Bosque Programming Language

#162

Post by exdsq »

Barrin92 wrote: post #146
exdsq wrote: post #137

Earlier quoted context omitted.

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

>Stronger assumptions at compile time allows for higher quality code this depends very heavily on your definition of higher quality code. I really hate this new trend in language discussions of declaring subjective benefits to be objective. Stronger compile-time assumptions, by definition, reduce the scope of runtime dynamism, which, for many people is an important feature of say dynamic languages. Stronger assumptio…

What can you do with runtime dynamism that I can’t do with a language using a strong type system with dependant types? You need to know _something_ about the dynamic data else you can’t do anything with it and that starts to suggest there’s a structure you can declare, right?

And what methods do you think are as capable as formal verification? What I mean by that includes formal specification, property based testing, theorem provers etc.

Edit: This reads argumentative but that’s not what I wanted, I’m genuinely interested.

Re: The Bosque Programming Language

#163

Post by pron »

littlestymaar wrote: post #142
pron wrote: post #68

Earlier quoted context omitted.

> has to prove itself not just superior to C++, but superior to Rust ... and Zig and Nim and D, I guess? None of them are seeing enough usage to even score them meaningfully against C++. The incumbents are C/C++, and there's no one else within two orders of magnitude. Just experiments at various stages; some are still in the lab, others have started some field trials, but that's about it.

You can't really compare Rust to Zig & Nim anymore. 2016 is over, Rust is deployed in the wild on millions of computers (Dropbox, VSCode, and obviously Firefox), there are dozens of Rust packages in Debian apt repositories and it's being used by many companies (Microsoft, Amazon, Facebook, Google, etc. even Nike!). Of course it's incomparable to C and C++, and it will never replace them, but comparing it to Nim and Z…

The difference between 0.000001% and 0.001% is much less important than between 0.001% and 20%. Rust has less penetration than Haskell and Erlang, and regardless of what you think of their merits, influential as they may be, none of them are factors in the software ecosystem. Languages with 10x more use and 10x more exposure than Rust disappeared with little impact over a very short period of time. Of course, Rust could become a serious force one day, as could Zig or Nim.

Re: The Bosque Programming Language

#164

Post by throwaway_pdp09 »

TomMarius wrote: post #160
throwaway_pdp09 wrote: post #128

Earlier quoted context omitted.

And I quoted exactly that line. In my first post.

Why are you asking unrelated questions then? The goal is not to motivate you to use it, especially not you who seem to be uninterested in both the goals and the ways the team has proposed. On the other hand I like the direction - but I am not going to use it on a daily basis either, maybe in a few years.

The base question was, what is it for? That is the ultimate purpose of this language. That's not an 'unrelated' question.

> The goal is not to motivate you to use it, especially not you who seem to be uninterested in both the goals and the ways the team has proposed

I knew neither the goals or nor the ways of this team. Tell me and as a guy interested in languages, I will be interested.

> I like the direction

So what is the direction?

All I'm asking for is information on this project, clearly given and not wrapped up in idiot marketing drivel ("stable GC support" FFS)

Re: The Bosque Programming Language

#166

Post by littlestymaar »

pron wrote: post #163
littlestymaar wrote: post #142

Earlier quoted context omitted.

You can't really compare Rust to Zig & Nim anymore. 2016 is over, Rust is deployed in the wild on millions of computers (Dropbox, VSCode, and obviously Firefox), there are dozens of Rust packages in Debian apt repositories and it's being used by many companies (Microsoft, Amazon, Facebook, Google, etc. even Nike!). Of course it's incomparable to C and C++, and it will never replace them, but comparing it to Nim and Z…

The difference between 0.000001% and 0.001% is much less important than between 0.001% and 20%. Rust has less penetration than Haskell and Erlang, and regardless of what you think of their merits, influential as they may be, none of them are factors in the software ecosystem. Languages with 10x more use and 10x more exposure than Rust disappeared with little impact over a very short period of time. Of course, Rust co…

> The difference between 0.000001% and 0.001% is much less important than between 0.001% and 20%.

Even if your math is pretty much arbitrary, there is the big difference between having libraries and not having them, and having jobs or not having them.

> none of them are factors in the software ecosystem

It will probably disappoint you, but C and C++ aren't really “relevant factors in the software ecosystem” anymore, and they haven't been for the past two decades. It's been PHP, Java, JavaScript, and some C#, all over for the past 20 years. And Rust won't change anything in that hierarchy even in the best case scenario, neither will Zig or Nim. And that's completely fine.

Yet, Rust has reached a significant existence, which means you can build stuff without having to build all the necessary libs by yourself, you can hire people knowing it, or even people who don't know it yet but will become proficient reasonably quickly because there are tons of learning material. You can find a job at some company already using it or use it for an internal project at your current company because you can show your manager that this isn't too much of a risk. All that even if you don't live in the bay area but in Europe. None of it was possible in 2016 for Rust, and none of it is in 2020 for Nim (and Zig isn't even stable, so it's more comparable to what Rust was in 2013 or something). If everything goes well for them, it could become the case by 2025, but not today. (First, they really need to bring more core contributors to the language, as they are still mainly developed by a single lead: at this point Andrew Kelley still has authored 50% o fall Zig commits, while Andreas Rumpf is responsible for one third of Nim's. The bus/burnout factor of both languages are still pretty much 1).

Re: The Bosque Programming Language

#167

Post by littlestymaar »

arc776 wrote: post #148
littlestymaar wrote: post #140

Earlier quoted context omitted.

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

You're right no dependent types, though to be fair that wasn't the only thing mentioned, and none of the other replies have yet suggested a language with dependent types either. I was responding to: > ...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 differe…

> In terms of languages with existing dependent type implementations, it looks like the main options would be ATS, Agda, F, or Idris. Some of these are pretty far away from the OOP paradigm too.

This* is an OK response to the original question.

> Seems a bit sudden to jump from my posting a reply to this as the same vein as "rewrite it in Rust".

The thing is: 90% of comments talking about Nim comes from people like you, whose entire comment history is over 90% about Nim, and most of the time, it comes in context where it's borderline irrelevant to the subject.

Aggressive proselytism like this has hurt Rust a lot, and it's definitely going to hurt Nim as well if you aren't careful.

Re: The Bosque Programming Language

#168

Post by nwienert »

klibertp wrote: post #145
zenexer wrote: post #141

Earlier quoted context omitted.

Right, I don't see the justification for "breakthrough" on that particular page. It's interesting in that it's attempting to bring more performance to the JS world using old tricks, but from that page alone, I wouldn't call it breakthrough. I'd need to see more concrete justification for that term. It's possible that the compiler itself is truly groundbreaking, but that isn't really addressed in the readme.

I actually went through the language doc, which describes the language in more detail (there are still some WIPs and TODOs). I was able to name at least one language which would be considered "prior art" for every one of the features detailed there. A good deal of languages also come close to supporting all of them in one package, and languages that offer most of the features are a dime a dozen. There are a few menti…

This can almost be said for many languages, even the popular ones like Rust which didn’t event most of the things it does.

Who cares? It’s all about how they put it all together. Plus some of the IR stuff is interesting.

Basque strikes me as a better attempt at a new Typescript than Reason. I really like that they are adding things like check, assert, validate into the language itself. I mean it just looks far better than TS in every way, especially once it starts to optimize all the language information it has. And it’s totally fine it’s not new. What matters more is that it puts them all together in the right way, moves at a good pace, gains traction.

I’m curious the interop story. Performance stats. DX. Look at TS vs Flow. I tried both numerous times and it was just so obvious TS was leagues ahead - far easier to set up, work with existing code, nicer errors (early on), and they just relentlessly improved it while Flow was crickets.

I don’t care so much about it being a breakthrough (though I can see how it’s basically as big a breakthrough as Rust, if it’s done right), but that it becomes viable. Sure, Reason or any of the other hundred I’ve seen come and go over the last few years would be cool too, but for whatever reason they aren’t “catching” fully. Reasons interop is finicky, the language is very verbose, and it’s just been way too quiet (where are the big releases?), but they got most of the rest right. This seems to get as much if not more right, so we’ll see if MS pushes it like they do TS, I hope so!

Re: The Bosque Programming Language

#169

Post by pron »

littlestymaar wrote: post #166
pron wrote: post #163

Earlier quoted context omitted.

The difference between 0.000001% and 0.001% is much less important than between 0.001% and 20%. Rust has less penetration than Haskell and Erlang, and regardless of what you think of their merits, influential as they may be, none of them are factors in the software ecosystem. Languages with 10x more use and 10x more exposure than Rust disappeared with little impact over a very short period of time. Of course, Rust co…

> The difference between 0.000001% and 0.001% is much less important than between 0.001% and 20%. Even if your math is pretty much arbitrary, there is the big difference between having libraries and not having them, and having jobs or not having them. > none of them are factors in the software ecosystem It will probably disappoint you, but C and C++ aren't really “relevant factors in the software ecosystem” anymore,…

Rust has a real existence that's somewhere in the vicinity of that of Elixir, Haskell, Ada, and Delphi. It's definitely alive, but it's not "the one to beat" or a major factor, even in the systems programming space, which is what I was responding to.

Re: The Bosque Programming Language

#170

Post by littlestymaar »

pron wrote: post #169
littlestymaar wrote: post #166

Earlier quoted context omitted.

> The difference between 0.000001% and 0.001% is much less important than between 0.001% and 20%. Even if your math is pretty much arbitrary, there is the big difference between having libraries and not having them, and having jobs or not having them. > none of them are factors in the software ecosystem It will probably disappoint you, but C and C++ aren't really “relevant factors in the software ecosystem” anymore,…

Rust has a real existence that's somewhere in the vicinity of that of Elixir, Haskell, Ada, and Delphi. It's definitely alive, but it's not "the one to beat" or a major factor, even in the systems programming space, which is what I was responding to.

Then you misunderstood the comment you were responding, because it claimed Rust was the one to beat in terms of design, never in terms of market share.

I someone wanted to release a new functional programming language, it would be totally legitimate to ask how it compare with Haskell, and complain that it's a poor reinvention of standard ML, even if Haskell only has a tiny market share.

Post reply on HN