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

141–150 of 178 posts

Re: The Bosque Programming Language

#141

Post by zenexer »

klibertp wrote: post #138
zenexer wrote: post #107

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

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

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.

Re: The Bosque Programming Language

#142

Post by littlestymaar »

pron wrote: post #68
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…

> 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 Zig makes no sense either.

Re: The Bosque Programming Language

#143

Post by wizeman »

gliese1337 wrote: post #134
wizeman wrote: post #60

Earlier quoted context omitted.

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

> That is a pretty major difference with wide-ranging effects on program performance right there.

It really isn't. The only difference is that in the second case you have to call mmap() at the beginning of your program to allocate stack space and then change the stack pointer to point to it, the rest of the execution would remain the same.

> That is a pretty major difference with wide-ranging effects on program performance right there.

> And once you do, that memory becomes functionally privileged from the perspective of your allocation strategy.

So you're saying that the transformation you mentioned gives you better error messages at the expense of performance, because now instead of using the stack, you have to keep allocating a stack-like structure on the heap?

If so, that's not entirely true, as you can have the same error messages without doing this transformation (that's why some kernels and runtimes can detect stack overflow and even resize the stack), so the only observable functional difference is that you replace a simple stack-like allocation mechanism with one that is slower without much benefit.

And it would still be a bit disingenuous to say that the transformation would make your program use constant stack space, as if replacing stack space with heap space somehow makes stack usage on a recursive function irrelevant...

Re: The Bosque Programming Language

#144

Post by ngrilly »

mrkmarron wrote: post #127
tomp wrote: post #23

Earlier quoted context omitted.

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

Hi and thanks for the questions: 1. By design the language provides some novel memory invariants including, no cycles in the object graph, no old-to-new pointers, and no pointer updates. Thus, we don't need to worry about cycle collection, can greatly reduce the number of Ref-Count operations, and can (later) employ pool allocation more consistently. 2. Bosque also supports by-value types (including the future abilit…

Great to see this point in the design space explored! Looking forward where it goes.

Re: The Bosque Programming Language

#145

Post by klibertp »

zenexer wrote: post #141
klibertp wrote: post #138

Earlier quoted context omitted.

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

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 mentions here and there which do look interesting, but whatever the "breakthrough" turns out to be - and maybe there really is one - it won't be in programming language design for sure.

Re: The Bosque Programming Language

#146

Post by Barrin92 »

exdsq wrote: post #137
zenexer wrote: post #107

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.

>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 assumptions at compile time are part of a trend of attempting to verify programs formally ahead of time, which is not the only way to produce robust software, but seems to be increasingly treated as such.

Re: The Bosque Programming Language

#147

Post by a1369209993 »

devinj wrote: 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…

Not that you don't have a point in general, but the snark and meanness in this HN thread is totally called for.

> github.com/microsoft/BosqueLanguage

We may not know where the fishhook (or razor blade) is, but after fourty years of experience, we know there is one.

Re: The Bosque Programming Language

#148

Post by arc776 »

littlestymaar wrote: post #140
arc776 wrote: post #112

Earlier quoted context omitted.

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

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 different paradigm succeed.

Nim's paradigm is fairly open (no small thanks to metaprogramming and unified function call syntax), and drops a lot of the baggage from the usual class (ahem) of OOP languages. There's loads of mainstream languages that focus entirely on OOP and I really resonate with wanting to explore different approaches to creating solutions, as I think OOP tends to colour how a language approaches problems.

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

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.

Also:

> Nim doesn't have them and never will

https://github.com/nim-lang/RFCs/issues/172

Re: The Bosque Programming Language

#149

Post by a1369209993 »

scoutt wrote: post #119
austincheney wrote: post #113

Earlier quoted context omitted.

> It’s already suspicious by virtue of having a hand-wavy "Int" type (what size/signedness is that?) That is a common misunderstanding by people who haven’t spent time with high level languages. In any language more precise numeric types allows for faster arithmetic operations if used appropriately. This is the primary reason Java is still a few times faster than JavaScript when comparing application benchmarks focus…

This is correct, and applies (and is helpful) to many cases. But the moment you need to shift an "Int", or do bitwise operations or transmit it in a network packet (think about endianness, etc.), is the moment you may regret that the compiler is doing too much heavy-lifting for you.

If it actually is a unlimited-width integer, bit logic/shifting can work fine, and network packets have to be x&0xFF,x>>8&0xFF,etc anyway. But that's painful for direct translation to machine code (what happens when I try to return 340'282'366'920'938'463'463'374'607'431'768'211'456 from a function?), so either it's secretly a fixed-width integer (and they're being deliberately vague about what width, which is suspicious), or the language defaults to possibly allocating memory (and possibly getting a OOM error) on every single arithmetic operation, which is a catastrophically undesirable property in a systems programming language.

Re: The Bosque Programming Language

#150

Post by junker123 »

a1369209993 wrote: post #147
devinj wrote: 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…

Not that you don't have a point in general, but the snark and meanness in this HN thread is totally called for. > github.com/ microsoft /BosqueLanguage We may not know where the fishhook (or razor blade) is , but after fourty years of experience, we know there is one.

Yeah, the good ol' MIT-license fishhook.
Post reply on HN