[HN Gopher] Borgo Programming Language
___________________________________________________________________
Borgo Programming Language
Author : MrBuddyCasino
Score : 270 points
Date : 2024-11-26 11:33 UTC (3 days ago)
(HTM) web link (borgo-lang.github.io)
(TXT) w3m dump (borgo-lang.github.io)
| brudgers wrote:
| The original ShowHN https://news.ycombinator.com/item?id=36847594
| Philpax wrote:
| See also https://news.ycombinator.com/item?id=40211891, which
| has the bulk of HN discussion about Borgo
| dang wrote:
| Thanks! Macroexpanded:
|
| _Borgo is a statically typed language that compiles to Go_ -
| https://news.ycombinator.com/item?id=40211891 - April 2024
| (545 comments)
|
| _Show HN: Borgo - a Rusty language that compiles to Go_ -
| https://news.ycombinator.com/item?id=36847594 - July 2023 (8
| comments)
| blixt wrote:
| This is quite beautiful. It hides several ugly warts of Go
| without necessarily adding more complexity. Result<T> instead of
| (T, error) and ? for propagation is just so nice. Structured
| enums is something I find myself needing all the time (and
| writing less self-explanatory code due to the lack of it).
| Option<T> instead of nil and zero values (which builds upon
| structured enum support) is what got me to say "yes please!"
|
| Honestly, some of the things they changed are maybe unnecessary
| (like the additional impl syntax, the Zig influenced
| dereferencing, return values from statements, several other
| Rustisms, etc). One part of me wish Go would get all of this. But
| another part of me knows it would never happen because this is
| not a superset (Python 2 -> Python 3 anyone?)
|
| I also wonder if this could even be compared to JavaScript /
| TypeScript for the same reason, not being a superset means you
| have to actively make a change to even start to migrate, and the
| revert path is not as trivial.
| howenterprisey wrote:
| I think it would be cool if we had something like this except
| as a superset.
| miohtama wrote:
| Is this TypeScript of Go?
| nine_k wrote:
| What prevents this from being a superset?
|
| C++ is a superset of C; did it do much good?
|
| Zig is not a superset of C, and Rust is not a superset of C++;
| does this hinder their adoption a lot
|
| Also, the pain of Python 2 -> 3 migration was that you can't
| mix py2 and py3 code in one project. This is not the case with
| Borgo apparently: you can mix it with Go, much like you can mix
| C++ / Zig / Rust with C, or TS with JS, or even Kotlin with
| Java.
|
| By having excellent interoperability, Borgo may have a good
| chance of wider adoption. If I were its maintainer, I'd
| prioritize interoperability with plain Go and its stdlib
| highly.
| Thorrez wrote:
| >What prevents this from being a superset?
|
| There are various syntax changes, such as let. Of course, if
| Borgo could be modified to not have let, but that would be a
| backward incompatible change.
| Y_Y wrote:
| The graph showing complexity against type safety is nice. I'd
| love to see it as a scatter plot with C and Haskell and MUMPS for
| example. Nevermind how to quantify those things of course.
| anthomtb wrote:
| I've no idea how to quantify such things.
|
| I do know that adding C to that graph would require changing
| the Y axis to a logarithmic scale.
| taosx wrote:
| That's very close to what I want, I wonder if we'd ever have
| customization for programming languages on the client side but
| when pushing to git it would get transpiled to the most common
| subset. A small change I would have loved at first glance would
| be the double colons (::) for namespace path along with explicit
| extraction and pub for public types.
| Someone wrote:
| > when pushing to git it would get transpiled to the most
| common subset.
|
| That would mean pulling from git would get you code that's
| harder to read than what you pushed (if that's not the case,
| you wouldn't have used that transpiler)
|
| There also isn't agreement on the common subset.
|
| For example, scala has lazy sequences, Rust wants programmers
| to have control over memory deallocation, go (sort-of) requires
| threads to have small stacks, Swift has copy-on-write
| collections, python's numbers automatically become bignums,
| many languages really need efficient boxing to have efficient
| implementations, etc.
|
| Strip all that, and you end up with WASM (or, possibly, even
| something even smaller), and various language ecosystems would
| build libraries on top of that that are incompatible with each
| other (possibly sometimes in non-obvious ways, leading to hard
| to detect bugs)
| nulld3v wrote:
| I have this same dream wayyy too often (uunfortunately).
|
| - A language that transpiles down to human readable, idiomatic
| Go.
|
| - Automatic folding of normal Go code into more
| concise/functional-style syntax.
|
| - Proper preservation of where every folded token came from for
| byte-perfect reconstruction of the original code. (Probably
| involving something like a lockfile).
|
| - On-demand transpilation during VCS checkout, or transpilation
| can happen directly in your IDE during file load/save.
|
| I think as long as some tricks are done, the in-IDE
| transpilation could even let you reuse all the existing Go
| syntax highlighting and autocompletion IDE infra.
|
| I started working on an IDE plugin to prototype transpilation
| "Go -> new lang". The plugin would replace Go code using IDE
| "code-folds" so it effectively didn't exist and wouldn't impact
| autocomplete/highlighting. And then you could use IDE snippets
| that expand to Go code to "pretend" you were writing in the new
| language.
|
| But unfortunately, I have too many other wild dreams in my head
| so it never went anywhere.
| mst wrote:
| > Proper preservation of where every folded token came from
| for byte-perfect reconstruction of the original code.
|
| I wonder if you could cheat by insisting the original code
| must have been run through an opinionated formatter so
| there's a One True Represenation of the source and you can
| restrict the problem to byte-perfect reconstruction of
| -that-?
|
| (I have the same dream too sometimes and keep wondering if
| that would, at least, be a more tractable goal for a version
| 0.1 if I ever get a round tuit)
| BlindEyeHalo wrote:
| > but when pushing to git it would get transpiled to the most
| common subset.
|
| What about the other direction? I don't think it will be very
| useful to not be able to read the exact code you wrote after
| the fact. Feels like writing a book but every sentence you
| enter is instantly rephrased by ChatGPT to sound more
| convoluted.
| taosx wrote:
| I was assuming that each contributor would have their custom
| rules on what the code looks in their editors. I agree that
| we should have a different solution so everyone reads the
| exact code they wrote in the style and format they wrote
| it...; Scratch all that, the more I think about it that
| sounds like a very bad idea, what about pair programming,
| collaboration, being able to talk about some parts of the
| code or it's design? Back to Go and Rust for me :)
| kjksf wrote:
| I love it.
|
| This is a language that everyone here says they want but no one
| will use, even though it's stable and mature (I assume because it
| compiles to stable and mature Go and can use every existing Go
| library).
|
| It hits all the "ok, Go is popular but made by morons for morons
| and if only it had this X advanced feature, it would be totally
| great".
|
| It has immutability. It has advanced enums. It has algebraic
| types. It has pattern matching. It has Result<> instead of
| returning an error. It gets rid of if err != nil. It gets read of
| of nil pointers.
|
| On paper it's a perfect language. It literally addresses every
| major complaint people have with Go.
|
| And I'll be here not using it and watching everyone else not use
| it.
|
| Because the harsh truth is that none of those things are actually
| big issues that would justify learning slightly different syntax.
|
| But maybe I'm wrong. Time will tell.
| Philpax wrote:
| I don't think the impediment to adoption is the syntax - that's
| straightforward enough - it's the ecosystem / tooling / network
| effects.
|
| I love this, even though I don't interact with Go on a regular
| basis, but I recognise that I'd be locking myself out of a lot
| of the standard Go tooling if I adopted this wholesale. For
| better or for worse, there's a high ecosystem barrier that most
| languages must overcome to be adopted, and the vast majority of
| efforts never get to that.
| nine_k wrote:
| What standard tooling would fail, given that the translation
| goes via a a generated Go source?
|
| I suppose there must be some borgofmt that handles the
| particular syntax. Certainly debuggers would have to be
| updated to show the corresponding Borgo code line at least.
|
| What else?
| autarch wrote:
| > What else?
|
| Any and all linters for Go, to start. In theory, you could
| run them on the transpiled source, but the results would be
| very hard to apply to the original Borgo code. And they'd
| probably produce lots of false positives for things that
| the Borgo compile ensures are safe, even if they're not
| linting-correct.
|
| And syntax highlighting, refactoring tools, an LSP server.
| I'm sure there are more things along these lines I'm
| failing to think of.
| throwup238 wrote:
| I think it'd do a lot better with Rust fans than Go fans, to be
| honest. It may not he as safe or whatever but Rust build times
| are brutal for larger projects and their ecosystems are mature
| enough to be comparable.
|
| It'd be even more useful with a Rust/Borgo interop layer but I
| bet that'd be really complicated.
| tucnak wrote:
| > made by morons for morons
|
| The creators of Go have also built the foundation of everything
| you take for granted. The real "harsh truth" here, of course,
| is that the Go team exhibits engineering genius, taste, and
| particularity that is rare to find in our industry, such that
| the likes of Rust "death by committee" people may only dream
| of. The long-lasting obsession that Rust people have with Go
| and the Go team has become a meme.
|
| Borgo is the recognition of that: a handout to Rust people that
| they will never appreciate.
| desumeku wrote:
| People seriously act like Rob Pike's quote was about
| appealing to the lowest common denominator of programmers
| possible without realizing that the functional programming
| concepts they hold so dearly have been lacking for 50 years
| in the world of C/C++ where it's creators came from. They are
| so quick to frustration over the fact that the some languages
| don't act like they think it should and don't require the
| extraneous baggage of higher-order programming in order to
| quickly be productive in, while at the same time the entire
| operating system their computer runs on contains not a single
| line of map(), reduce() or filter().
| tucnak wrote:
| For a community supposedly "committed to providing a
| friendly, safe and welcoming environment for all,
| regardless of level of experience"[1] Rust activists
| perhaps unsurprisingly lack in tolerance, empathy, and
| awareness. The community has changed, too. I liked them
| more circa ~2015 from before the corpos caught on to "the
| most loved" language, and have since blown evangelists'
| expectations for future adoption way out of proportion. As
| long as the drawn-out vendetta lead by Rust activists
| contra Go is concerned, old proverb comes to mind: "Hating
| popular things does not make you interesting."
|
| [1]: https://www.rust-lang.org/policies/code-of-conduct
| skinkestek wrote:
| > They are so quick to frustration over the fact that the
| some languages don't act like they think it should and
| don't require the extraneous baggage of higher-order
| programming in order to quickly be productive in
|
| Higher order functions often seems to be a way to
| complicate otherwise easy to read code. Kotlin manages to
| do it reasonably well, in Javascript I has beem behind some
| of my absolutely worst debugging experiences.
|
| The problem with Go, as far as I have seen is not about
| functional programming, but rather about things like making
| a point out of not supporting generics for years.
|
| For anyone who has experienced the Java 1.4 to Java 5
| transition, and all the cruft it removed I cannot see how
| any of them can willingly accept a language that made a
| point out of being clumsy so one had to do it the old
| clumsy way agaim.
|
| Or how a language that us supposedly a good fit for web
| backends had (don't know if it have now, I've given up) no
| simple way in the standard library or any popular
| templating solution to say in a template that it should be
| included in a bigger template, thereby forcing the code to
| know about things that belong in the design world.
|
| I.e. to have
|
| - a common header with dynamic title
|
| - a dynamic part between
|
| - and common footer
|
| the correct way last I checked seemed to be to string them
| together like a php script from the late nineties.
| cwalv wrote:
| > The creators of Go have also built the foundation of
| everything you take for granted
|
| Is it the foundation because it was built a long time ago,
| and is "good enough" .. or because it's just really good?
| "Worse is better" comes to mind.
|
| There was another post on hn today about "pipelines getting
| stuck" that was really just about poor interaction between
| pipelines and programs changing their buffering behavior
| based on `istty()`. bash has been around a long time, and
| will stay around for a long time still, but that doesn't mean
| its design leaves nothing to be desired. It just means the
| benefits of changing it haven't crossed the 10x threshold of
| the costs (partially because it's foundational).
| erik_seaberg wrote:
| Fitting a C compiler on a PDP-11 was an impressive
| achievement, but as a language it was a poor foundation to
| build anything reliable, and we still live with the
| consequences.
| oersted wrote:
| I do agree with you to a degree, but let's not forget the
| monumental successes that are TypeScript and Kotlin.
|
| There have been lots of such languages that transpiled to
| JavaScript or worked on the JVM, adding nicer syntax and
| features. Many of them went nowhere, but quite a few of them
| did get widely adopted. Off the top of my head, CoffeeScript
| was also relatively popular for a while, and Clojure builds on
| top of both ecosystems, Scala comes to mind too.
|
| Go might be in a similar situation right now, where it has
| become entrenched in certain domains (like DevOps), and lots of
| people are not entirely satisfied with it but they can't to
| switch to something else. Is Go getting a similarly bad
| reputation as JavaScript or Java to push this through? Is the
| lock-in as strong as in browsers or Android? No, I wouldn't say
| it's there yet, but still, it is worth a shot to try to build
| such an alternative language.
|
| I do agree that Borgo will probably not be adopted widely, the
| pains it addresses are not strong enough and the language does
| not seem to be properly maintained and supported. But history
| shows it is not as unlikely as you suggest.
| alexvitkov wrote:
| > Because the harsh truth is that none of those things are
| actually big issues that would justify learning slightly
| different syntax.
|
| The syntax has nothing to do with it, you already know the
| syntax. I'm fairly confident most people reading this comment
| can program in this language right now, without opening the
| docs.
|
| The reasons I won't be using it are:
|
| 1. It's a source to source transpiler - even when done nearly
| perfectly, these always introduce problems. Debugging TS is
| never 100% seamless. Debugging minified JS is annoying, even
| with a sourcemap.
|
| 2. Go code tends to be very simple and "un-abstract", so the
| problems with the language's syntax and typesystem aren't bad
| enough to justify a wrapper.
|
| 3. I don't want to be an early adopter of programming
| languages. This may be harsh, but I won't consider a language
| until it reaches at least #50 in popularity someone is paid to
| work on the tooling full time. Hobbyists enjoy solving
| interesting problems like language design, but don't
| particularly enjoy the "gruntwork" some of which is critical -
| a comprehensive test suite, a fuzzer for the compiler, an
| LSP/IDE/editor plugins, a good standard library...
|
| There have been a lot of promising one-man projects such as
| this one, that get abandoned when the lead developer moves on.
| You don't want to be stuck holding the bag with a large
| codebase in a zero user language.
| foooorsyth wrote:
| Top 50 is incredibly generous. I wouldn't use anything
| outside of the top ~20 for anything I'd be getting paid to
| produce.
|
| https://survey.stackoverflow.co/2024/technology#most-
| popular...
|
| The most important factor for a language is Big Tech backing.
| Little squabbles on syntax or language features or
| philosophies are entirely secondary.
| nine_k wrote:
| How does Zig look from where you sit?
| graemep wrote:
| > This is a language that everyone here says they want but no
| one will use, even though it's stable and mature (I assume
| because it compiles to stable and mature Go and can use every
| existing Go library).
|
| Note the thread here about the lack of a license. You cannot
| legally use it.
|
| Even if you risk using it, people are also wary of using a
| language that has a single developer behind it, and would be
| even if it were open source.
| weinzierl wrote:
| _" It literally addresses every major complaint people have
| with Go."_
|
| It addresses complaints 1 to n but does nothing about complaint
| 0: Having a garbage collector with all its associated
| downsides.
| polyaniline wrote:
| If it skipped the GC wouldn't it just be Rust?
| weinzierl wrote:
| Valid question, but no. Borgo takes inspiration from Rust
| but is still a vastly different language. Even though it
| has algebraic data types its type system is not Rust's.
| Another big difference is that it sticks with Go's
| interfaces instead of traits.
|
| I think Borgo sits at an interesting place in the design
| space. I just believe there are vast plains of unsettled
| land in the strongly typed GC-less direction and a language
| that really addressed _all_ complaints about Go would have
| live there.
| darthrupert wrote:
| Rust with GC is actually what many people want.
|
| And by that I don't mean using Rc<> everywhere nor do I even
| mean making a GC library and then using GC<> everywhere. I
| mean having the runtime handle all memory things with you
| having to think about it only when some extremely rare corner
| case breaks.
| arethuza wrote:
| That sounds like C#?
|
| https://learn.microsoft.com/en-us/dotnet/standard/memory-
| and...
| restlake wrote:
| You are correct, C# straddles that line better than any
| other language right now imo thanks to the APIs you
| linked. There was a good write up about this Rust vs C#
| Span comparison on HN a few weeks ago but the link
| escapes me
| ComputerGuru wrote:
| I have been a huge (but lonely) proponent of C# and rust
| being the best two-language combo. But once (someday!
| Soon they say!) first-class discriminated union support
| lands, it'll be the ideal recommendation for anyone that
| wants to get away from manually taking care of lifetimes.
| cwalv wrote:
| C# was derided as "Microsoft's Java" from the beginning,
| even though it pulled ahead very early on with generics
| and never looked back. Microsoft was loathed by many for
| a long time. Go is popular because Google is (was?)
| loved/admired.
| neonsunset wrote:
| I'm finding F# to be even closer because it has HM type
| inference, discriminated unions (note they are not as
| layout-efficient as Rust's, it is better in F# 9 though),
| is fully expression oriented and overall a quite terse
| language (Rust isn't really terse but can be made so in
| some cases).
|
| It's worse at dealing with ref structs so C# is better
| for some low-level tasks. But it has other niceties like
| IL-level function and lambda inlining.
| timeon wrote:
| When companies move from Go it is usually because of GC.
|
| Tho point of Rust is to be safe language without GC. Even
| if not perfect, best thing about Rust is borrow checker and
| border between safe/unsafe. You can use several other
| languages, like Ocaml, if you want Rust with GC.
| etse wrote:
| I'm curious which are the well known projects or products
| that have ported or converted away from Go. Anyone have a
| shortlist?
| PittleyDunkin wrote:
| Rust with GC wouldn't look much like rust anymore.
| thomasmg wrote:
| I think people want is Rust, but simpler. At least by
| default.
|
| I could imagine people want a programming language that
| is: memory safe, without GC pauses. A bit slower by
| default than C / Rust, but with the _option_ to make it
| as fast. Then easier to learn, less vendor lock-in than
| Swift, and a modern syntax (no null pointers etc).
|
| I don't think such a language exists currently.
| dicytea wrote:
| It'll probably not get as much traction as Go, but for a
| simpler reason that may not be as ideologically satisfying for
| you. It's just really hard for a new language to get real
| traction, no matter how good it is. And it's even harder for
| transpiled languages, because they almost always gets
| overshadowed by the language they're transpiling to.
| mst wrote:
| What I find truly fascinating is that given the complexity of
| most build systems (especially ones that use babel) basically
| every node project I encounter is in fact effectively
| transpiled, it's just it's "javascript compiled to
| javascript" rather than having a different source syntax.
|
| I don't even mind[0], I think it's actually kind of amazing.
|
| [0] I have all the usual complaints about build systems and
| about the node ecosystem in general, but I don't think the
| fact that it's javascript compiled to javascript in and of
| itself is a problem, only, well, almost everything about how
| that's usually implemented/achieved :D
| nine_k wrote:
| But it's the minimal translation to allow newer language
| features and APIs to be still used in older browsers.
|
| OTOH I haven't seen a pure _JavaScript_ project for a
| number of years. It 's all Typescript now, maybe with some
| vestiges of legacy JS slated for eventual migration to TS.
| DecoySalamander wrote:
| There are people who insist on writing JS (with types in
| JSDoc), but Svelte is the only such project I can name
| off the top of my head.
| lexicality wrote:
| Is it mature? The project is a bit more than a year old and
| describes itself as "new"
| ctvo wrote:
| > Because the harsh truth is that none of those things are
| actually big issues that would justify learning slightly
| different syntax.
|
| That's partially the cost, but the other cost is building this
| into existing tool chains and deployment mechanisms. Getting
| buyin from teams, ensuring _everyone_ learns the syntax.
|
| And the unstated fear: The code it generates, is it actually
| good? Am I going to have silly issues down the road that are
| hard to debug and require diving into generated code to see
| some concurrency issue?
| pjmlp wrote:
| The problem is that it is useless to try to fix Go, because
| that isn't what the community appreciates.
|
| One is better off wasting brain cycles contributing to C#,
| Java, Kotlin, Swift, Scala, D,.... where a language being
| feature rich is appreciated by the community.
| throwaway127482 wrote:
| It's not trying to fix Go, it's trying to be a new
| programming language. It just happens to compile to Go, and
| allows Go interop.
| pjmlp wrote:
| Which is a way to use Go, while not using Go.
|
| Hence better invest into ecosytems that value language
| design PhDs....
| nine_k wrote:
| No, it's a way of writing a better language while using
| Go libraries extensively. The same way Kotlin is a way of
| writing a better language while using Java libraries
| extensively.
| pjmlp wrote:
| The difference is that JVM community welcomes languages
| PhD folks.
|
| There is even the JVM Languages Summit.
|
| Unthinkable in Go ecosystem.
| nine_k wrote:
| Maybe because Go is not a VM?
| pjmlp wrote:
| Java compiles to native code for two decades now, it has
| always been a matter of how much one was willing to pay
| for a commercial JDK.
|
| "The key point here is our programmers are Googlers,
| they're not researchers. They're typically, fairly young,
| fresh out of school, probably learned Java, maybe learned
| C or C++, probably learned Python. They're not capable of
| understanding a brilliant language but we want to use
| them to build good software. So, the language that we
| give them has to be easy for them to understand and easy
| to adopt."
|
| -- Rob Pike
| nine_k wrote:
| > _our programmers are Googlers ... They're not capable
| of understanding a brilliant language_
|
| Sounds pretty damning, I'd say. This of course
| illustrates why Go is called "systems PHP".
|
| > _how much one was willing to pay for a commercial JDK._
|
| I strongly prefer open-source tools at the base of my
| stack. Not as much because of the money but more because
| of the level of trust. Things should be inspectable.
| neonsunset wrote:
| That's what .NET is for (both C# and F#) - it has no
| private implementations (Unity does not count :P). Much
| more competent compiler too and smaller native binaries.
| Something you could confidently use in production.
| skinkestek wrote:
| Then you have to deal with:
|
| - .Net devs (they are almost as annoying as us
| Java/Kotlin devs)
|
| - a language and ecosystem that consistently sacrifice
| backwards compatibility (contrary to us who have features
| sacrificed for backwards compatibility at every single
| step)
|
| - you have to live without the JVM ecosystem (on this I
| have no self deprecating comment, C# is a better
| language, but the ecosystem, from libraries to build
| system to IDEs is something I always miss when I work in
| .Net.)
| neonsunset wrote:
| "Contrary to us"? I can't agree with this attitude.
|
| .NET maintains excellent backwards compatibility, C# and
| F# even more so. The changes either affect frameworks and
| libraries, which you can often update independently or
| are easily addressed. Most projects since .NET 5 only
| ever had to bump the target version and rebuild to move
| forward (notable exception: in .NET 6 ASP.NET Core
| introduced simplified API for application setup which
| required changes).
|
| Neither JVM nor Go have the degree of low-level
| capabilities .NET provides first-class support for. And
| F# integrates in an easier way into existing C# solutions
| than Kotlin does into Java ones.
|
| It _is_ the GC-based Rust alternative many are looking
| for but are overlooking due to bias from the past.
| skinkestek wrote:
| Yes, I'm talking about the platform, not the syntax.
|
| It is my feeling that .Net developers with some years of
| experience get wide eyed when I tell them how I can use
| any old library that I need together with the newest JVM
| and my platform upgrades have mostly consisted of bumping
| numbers.
| neonsunset wrote:
| I don't know which developers you talked to. It's nothing
| surprising in .NET land. If you target netstadnard2.0 the
| library will work on _any_ version from .NET Framework
| 4.6.1 and upwards. All newer targets are forward
| compatible by default too. Wherever the notion of
| otherwise comes from it is likely a misunderstanding.
| desumeku wrote:
| "We hire working-class college graduates from the normal
| population, and not ivy league graduates who have the
| time to waste on unproductive academic research languages
| that see no industrial use."
|
| Is this what is so damning about Go? The constant
| reposting of this quote as some sort of attack on Go's
| validity and reputation reeks of nothing but classism.
| renox wrote:
| You're right nobody will use it: it's a one man language are
| you going to bet your codebase on it? It probably doesn't have
| any tooling, debugggers.. Are the error messages from the
| compiler good?
| nine_k wrote:
| Elm is also a one-man language, but it enjoyed some
| popularity. Zig has been a one-man language for some time,
| but it's got traction, following, and more contributors.
|
| Syntax squiggles are not very important, but other language
| features, like a good design and removing whole classes of
| bugs, are.
| samatman wrote:
| Zig is a BDFL language, but it's far from a one-man
| language. There's a Zig Foundation with several full-time
| paid contributors, with a larger design team who
| collaborate on the big picture.
|
| If Andrew Kelly were kidnapped by aliens tomorrow, Zig
| would continue. I think that's the dividing point, when the
| bus factor is no longer one.
| skinkestek wrote:
| I've had to deal with Elm alone (the original devs had
| left, leaving next to no docs, because who needs docs with
| such a beautiful language I guess).
|
| Thankfully I've been able to scramble some syntax
| highlighting support and reverse engineer how to start and
| run it, and after a while it actually kind of makes sense.
|
| But I am an engineer, not an artist, and elm code will not
| survive me in the code base if I can avoid it (unless there
| are teams of Elm programmers at a place).
|
| Elm might remove classes of bugs, but when there is not a
| single developer except me who manages to wrestle with it,
| though luck. TypeScript also removes entire classes of
| bugs, and it does so while being well documented and easy
| to understand for devs from other mainstream languages so
| the other devs won't come running my way everytime they
| have to fix something written in it.
| keybored wrote:
| Who are you talking to?
|
| Some people don't like Go but have no reason (or something
| compelling them) to use it. So they use other languages. They
| don't need a new source-to-source compiler. Your point is moot
| for this group.
|
| But some people might have to use it. So this language is at
| least relevant to them. If indeed it addresses all of the
| complaints. But that might be hard for a language which only
| compiles to that other language to do.
| Aldipower wrote:
| JavaScript had Netscape behind it, TypeScript has Microsoft
| behind it, Rust had Mozilla behind it, Go has Google behind it,
| Java had Sun behind it, C++ had AT&T behind it, and so on..
|
| Borgo?
|
| Cannot think about much languages that haven't any bigger
| company behind it. PHP maybe? To an extend Python? But today
| Python good pushed by the big companies of the AI hype.
| scythe wrote:
| Python was obscure and developed in silence for 15 years
| before it caught on. The team behind it just never gave up.
| Most people who develop independent languages give up after a
| year or five. Lua is similar, though it and PHP both caught
| on faster because they both put embedding upfront, which
| allowed them to be built into game engines and websites built
| with C.
| cwalv wrote:
| Python also fits its design space amazingly well (that's
| what's meant by "Guido's time machine"). It's a glue
| language, with a REPL, but it's not a shell (i.e. it's not
| meant to glue programs primarily through stdin/stdout/argv,
| but instead libraries through their APIs). It was a very
| useful (Greenspun's tenth rule) and somewhat underserved
| niche (perl, scheme and tcl come to mind).
| cwalv wrote:
| In my mind the fact that Go has Google behind it is the main
| reason it caught on (and quickly). It would have been
| completely ignored otherwise.
| anamexis wrote:
| I think that's the point.
| diggan wrote:
| That + the individuals involved. Without the company
| backing + different (not already-"famous" [programmer
| famous]) people involved, it would have been completely
| ignored.
| cmrdporcupine wrote:
| The issues with language adoption come down to tooling,
| libraries, and community.
|
| Just because it's compatible with Go doesn't mean that 3rd
| party Go dependencies will be a natural fit for it.
|
| Existing IDEs and other tooling won't work.
|
| Community is unlikely to grow.
|
| etc
| IshKebab wrote:
| I don't think that's why nobody will use it. The real reasons
| are:
|
| 1. People who want Rust will just use Rust. You can keep your
| Rust code simple if you want, most of the time. I think most
| people that object to Go's issues have moved on from Go by now.
| Kind of like how safe C++ has no chance because most of the
| people that get it have left C++ already.
|
| 2. It's clearly _not_ mature. Not many people jump on one man
| languages. If this was backed by a large company I suspect the
| story would be different.
|
| Still, it seems to be tastefully designed. Might have a chance
| I guess.
| cies wrote:
| Gleam compiles to Erlang. Kotlin compiles to JVM bytecode and has
| great interop with Java. Rust and Zig easily call C. Elm compiles
| to JS and has a clear means to calling JS.
| TypeScript/ReScript/ReasonML all do something similar.
|
| All these languages add type-safety and/or sum types and/or
| immutability-by-default and/or explicit-nullability.
|
| I wish Borgo the best in doing the same for the Golang ecosystem.
| It's sorely needed.
| mrhonza wrote:
| Note that the compiler is not open source.
|
| https://github.com/borgo-lang/borgo/issues/11
| graemep wrote:
| Even worse than that, it has no license at all. It cannot
| legally be used.
| diggan wrote:
| > It cannot legally be used.
|
| Not true at all.
|
| If you create and/or upload a repository to GitHub, you're
| giving others the permission to see and fork it. From the
| "Licensing a repository":
|
| > If you publish your source code in a public repository on
| GitHub, according to the [Terms of
| Service](https://docs.github.com/en/site-policy/github-
| terms/github-t...), other users of GitHub.com have the right
| to view and fork your repository.
|
| https://docs.github.com/en/repositories/managing-your-
| reposi...
| Someone wrote:
| Corrections welcome, but I don't think the right to view
| and fork code gives you the right to run it.
|
| Also, GitHub's terms say:
|
| _"If you set your pages and repositories to be viewed
| publicly, you grant each User of GitHub a nonexclusive,
| worldwide license to use, display, and perform Your Content
| through the GitHub Service and to reproduce Your Content
| solely on GitHub as permitted through GitHub 's
| functionality (for example, through forking). You may grant
| further rights if you adopt a license."_
|
| Part of that reads as if you are only allowed to fork it
| into other GitHub repos.
|
| Whether copying to your local machine or running are
| allowed will depend on what "use through the GitHub
| Service" and "perform through the GitHub Service" mean.
| diggan wrote:
| Yeah, true, thanks for expanding the context.
|
| Would also depend on how exactly GitHub (or a court)
| would interpret "forking", as an argument could be made
| that a GitHub fork is just a "GitHub Create" + "Git
| Clone" operation, and having permission to do a "GitHub
| Fork" means you're also allowed to do a "Git Clone".
|
| I guess we'll never know, as a case like this would never
| reach court so it's guesses all around.
| aleksi wrote:
| Yeah, but "view and fork" does not imply "compile and run",
| unfortunately.
| captaincrowbar wrote:
| That doesn't make it open source, just "source available".
| laurentlb wrote:
| There are some interesting design ideas, but I'm not sure where
| the project is going. Based on the commit history, it was created
| by one person and there has been almost no activity in the last
| 12 months.
|
| The current status is unclear (is anyone willing to use it in
| production) and the lack of license is of course a concern.
| jjallen wrote:
| There's no license which makes a copyrighted work. This is just
| a performance without a license that permits usage of the
| language.
| bmacho wrote:
| Looks similar to Haxe (and to the language that
| C++/Java/Python/TypeScript/etc are converging).
|
| Now give it to google, release it as .go2, and make it
| frictionless to use Go and Go2 in a codebase.
| diggan wrote:
| > Now give it to google, release it as .go2, and make it
| frictionless to use Go and Go2 in a codebase.
|
| Has Google ever "taken" an already created project under their
| wing and ran with it? AFAIK, Google only does the opposite and
| releases projects from their grips, but never the opposite.
| "Everything Google does, Google must invent" is how it looks
| like from the outside at least.
| mkl wrote:
| Webkit.
| joatmon-snoo wrote:
| If Google adopts an existing OSS technology, it usually takes
| the form of Google contributors joining a core team for the
| OSS in question. The OSS community generally isn't a fan of
| single companies taking _over_ a project and generally
| prefers ownership changes in the other direction (e.g.
| Kubernetes getting transferred to the CNCF).
|
| That being said, the most noticeable example here that I can
| think of is Google migrating its internal C++ toolchain from
| using gcc/g++ to clang.
| rererereferred wrote:
| They've bought and kept running many projects. YouTube,
| Writely (now google docs), Android to name a few.
| mst wrote:
| I can't immediately find it but somebody once said something
| like "on a long enough timeline, all languages become
| CommonLispScript with different syntax" and there's definitely
| some truth to that.
| darkest_ruby wrote:
| this is basically what Go should have been!
| sixthDot wrote:
| The first thing I do when I hear of a new PL is to look at its
| bug tracker.
| jjallen wrote:
| This is interesting except for the fact that there is no license.
| This makes this "language" technically only usable by the
| creator?
|
| This is what GH says about no license being included. I almost
| think they should make including a license obligatory.
|
| > You're under no obligation to choose a license. However,
| without a license, the default copyright laws apply, meaning that
| you retain all rights to your source code and no one may
| reproduce, distribute, or create derivative works from your work.
| If you're creating an open source project, we strongly encourage
| you to include an open source license. The Open Source Guide
| provides additional guidance on choosing the correct license for
| your project.
|
| Note
|
| If you publish your source code in a public repository on GitHub,
| according to the Terms of Service, other users of GitHub.com have
| the right to view and fork your repository. If you have already
| created a repository and no longer want users to have access to
| the repository, you can make the repository private. When you
| change the visibility of a repository to private, existing forks
| or local copies created by other users will still exist. For more
| information, see "Setting repository visibility."
|
| Also if it compiled to Rust instead of Go (it is written in Rust
| which made me think it compiled to Rust for a minute) we could do
| something about that darn GC.
| arvidj wrote:
| How does it compare to OCaml?
| darthrupert wrote:
| This is freaking awesome. Golang is an amazing language and
| runtime for application development. But the language does show
| its heritage insofar that it lacks many niceties that languages
| like Rust have.
|
| I will certainly try this out in my next personal project.
| vfclists wrote:
| How come on HN the comments which are tangential to the main
| topic always get voted to the top?
| kbd wrote:
| Go deserves to get TypeScripted. Another effort in this vein is
| Go+
|
| https://github.com/goplus/gop
| onionisafruit wrote:
| How do you figure this. Javascript got TypeScripted because it
| was forced on us by browsers.
|
| Is there an equivalent api that forces the use of Go? None that
| I know of. Maybe there are some domains where you need access
| to specialized Go packages that would be hard to recreate in
| another language. I see that sometimes with C and C++, but I
| haven't seen it with Go.
|
| As a happy Gopher, I'm aware I probably have blind spots about
| this.
| renox wrote:
| While it looks interesting but what is the story for debugging?
| Insanity wrote:
| This is cool! I won't be using it in production but this will
| definitely be (one of) my advent of code languages for 2024 :)
| 3a2d29 wrote:
| Might I suggest a purple logo, since its half Go (blue) and half
| rust (reddish). Lol
|
| This fills a pretty good niche. There are several backend APIs
| that I want to use rust for, but ends up adding so much upkeep
| and complexity to deal with, but Go leaves errors uncaught.
| dvdkon wrote:
| This looks neat, but I think requiring declaration files makes
| interop with Go code tedious enough that nobody will bother
| (along with all the usual maturity arguments). I'd prefer it if
| this was using the Go compiler as a library to get all necessary
| information automatically, or if it was a straight up fork of Go.
| nmilo wrote:
| Almost the perfect language. I don't get why it's they didn't
| make it compatible with normal Go. It should have been like
| Typescript where you can compile plain Go, it just adds features
| on top it. The "let" and struct changes are totally unnecessary.
| Then you can interop with existing libraries and convert large Go
| projects to this incrementally.
| atombender wrote:
| Interop would force the language to keep certain core features,
| like nil pointers and zero values, that in Borgo are presumably
| considered anti-features.
|
| You end up with the worst features as the common denominator
| and something you can never get rid of; the moment you call a
| Go library that can return nils, for example, you have to deal
| with those as nils (and run the risk of nil bugs) rather than
| the safer option type.
|
| We've been there before. C++ chose to be largely compatible
| with C as it existed at the time, and that legacy casts a long
| shadow, even if it's no longer a strict superset. C++ still has
| C-style arrays, null-terminated strings, unsafe pointer
| arithmetic, implicit conversions, etc.
|
| You could also argue that TypeScript's backwards compatibility
| with JS also adds a similar burden. It's had to provide a lot
| of mechanisms to allow untyped values to share the same
| universe as typed values.
|
| Maybe the solution is to provide a kind of "unsafe" kind of
| block where you can interact safely with Go code but you're
| forced to deal with the discrepancies. For example, you can
| call a Go function that returns nil, but to pass the value out
| of the unsafe block, you have to convert it to an optional.
| skybrian wrote:
| I'm wondering how idiomatic the generated Go code is. Would it be
| useful for generating code in a Go library?
| fsndz wrote:
| I wonder if there will ever be another programming language on
| top of the most high level languages we currently have (like to
| python what python was for C)
| written-beyond wrote:
| Did someone finally fix/complete go?
| waveywaves wrote:
| Feels like this is something I could learn before moving trying
| Rust properly for the second time. What do Rust developers here
| think about that ?
___________________________________________________________________
(page generated 2024-11-29 23:00 UTC)