Go is less complex than rust? Really? I thought that was disputed.
Borgo is a statically typed language that compiles to Go
71–80 of 559 posts
Re: Borgo is a statically typed language that compiles to Go
#72Earlier quoted context omitted.
> A transpiler emits code the user is supposed to understand, a compiler does not. No, a transpiler emits code that another system is meant to understand (often another compiler or interpreter). Whether a human can understand it or not is immaterial to the objective of transpiling.
But then compilation is the same thing as transpilation as noted.
Yes.
Re: Borgo is a statically typed language that compiles to Go
#73Rust is not as complicated as the opening graphic indicates. I usually see this meme from less experienced people but I'm frankly surprised to see it from somebody that's capable of writing a compiler in rust .
Compared to GCed languages like Go and Borgo? Ownership is non-trivial...
Re: Borgo is a statically typed language that compiles to Go
#74Earlier quoted context omitted.
I don’t think any of that is contradicted by what this seems to be trying to do. In fact, Go doesn’t make you deal with your errors (you’re free to ignore the returns) whereas this would (via exhaustive pattern match).
> In fact, Go doesn’t make you deal with your errors Your right, it does not. I will _ =: an error in a throw away script all the time. I see that in a code review, in production code... Big red flag. This is a departure from an exception, that might be thrown in one place and handled far far away from the code you're looking at.
I'm not an expert in Go, and my experience is somewhat limited, however, a few years back I fixed a really subtle bug in a project that was related to the fact that errors _weren't_ being handled correctly. As a relative newbie to Go, the code in the diff[0] didn't appear to be doing anything wrong, until I added some print statements and realized that the numbers were not adding up correctly. IMO, if the returned value had been more like a Rust optional or result type, I think this issue would have either not been a bug in the first place, or it would have been easier to spot the bug.
[0]: https://github.com/semilin/genkey/commit/fafed6744555c5a81fd...
EDIT: The fact that this was a bug at all makes me fear for the rest of the code base. If this one slipped through the cracks, how can I know that the rest of the code base is correct?
Re: Borgo is a statically typed language that compiles to Go
#75Earlier quoted context omitted.
GO: Easy to learn: you can be productive in go in a day or two. Strong standard library. Complies to binary. (you dont need to drag a run time around) And this is fast! Easy dependency management. Linting is built in. (No arguing over tabs vs spaces) First class testing. (and its fast) "good enough" coding is very fast. You can mostly ignore performance and pick it up when and where you need it. ---------------------…
> As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. I actually see this as a negative and we've been looking at Uber/Fx for more support. DI frameworks don't do anything you can't do without it, but it takes significantly more experience and technological/organizational maturity that I find the avera…
DI in something like Spring, for example, can make it extremely hard to track where a given dependency is coming from. With the use of annotations and defaults and properties on annotations for selecting a dependency, to sometimes autogenerated classes for which there is no source code.
I would much rather have a few lines of straight forward code that set up dependencies explicitly, than deal with opaque semantics and mysterious incantations.
Re: Borgo is a statically typed language that compiles to Go
#76Great! Something I've always wanted. I'd love to be able to use a bit more type-y Go such as Borgo, and have a Pythonesque dynamic scripting language that latches onto it effortlessly. Dynamic typing is great for exploratory work, whether that's ML research or developing new features for a web app. But it would be great to be able to morph it over time into a more specified strongly typed language without having to r…
Sounds like JavaScript and typescript would be a good fit for you. Highly expressive, dynamic and strongly typed, and highly performant both on server side and within the browser.
Re: Borgo is a statically typed language that compiles to Go
#77Great! Something I've always wanted. I'd love to be able to use a bit more type-y Go such as Borgo, and have a Pythonesque dynamic scripting language that latches onto it effortlessly. Dynamic typing is great for exploratory work, whether that's ML research or developing new features for a web app. But it would be great to be able to morph it over time into a more specified strongly typed language without having to r…
> Like building out of clay and firing the parts you are happy with.
> Could even have a three step - Python-esque -> Go/Java-esque -> Rust/C++esque.
We do exactly that with Common Lisp. It compiles to different languages/frameworks depending on what we require (usually sbcl is more than enough, but for instance for embedded or ML we need another step. All dev (with smaller data etc) is in sbcl so with all the advantages.
Re: Borgo is a statically typed language that compiles to Go
#78Great! Something I've always wanted. I'd love to be able to use a bit more type-y Go such as Borgo, and have a Pythonesque dynamic scripting language that latches onto it effortlessly. Dynamic typing is great for exploratory work, whether that's ML research or developing new features for a web app. But it would be great to be able to morph it over time into a more specified strongly typed language without having to r…
I like the idea but in all honesty I have difficulty imagining it working in practice. Once your python code is stable (i.e. You've worked out 99% of the bugs you might have caught earlier with strict type checking) would there be any incentive to go back and make the types more rigid or rigorous? Would there be a non-negligible chance of introducing bugs in that process?
Re: Borgo is a statically typed language that compiles to Go
#79Go is less complex than rust? Really? I thought that was disputed.
Go is less complex than Rust, imo. As someone who has used Go and Rust for about the same time (5-6 years), it's not as less complex than it seems, though. Namely i found a odd type of complexity emerge in Go where by every individual unit was simple, but the whole was so spread out and poorly abstracted that it it spread out the complexity. So if you squinted, everything was simple. If you zoomed out, it felt convoluted.
Rust on the other hand drastically simplifies a lot of the complexity i dealt with in Go. However depending on the type of work, it's of course got plenty of complexity to dig into should you need it.
The challenge with Rust imo is to know where to use that complexity. Lots of rope to hang yourself with. On average i find myself with code that to me is simpler in Rust, because it's easier to reason about larger blocks of logic. However i still wouldn't ignore the extra rope of the whole language and call it "simpler" than Go.
Re: Borgo is a statically typed language that compiles to Go
#80Earlier quoted context omitted.
GO: Easy to learn: you can be productive in go in a day or two. Strong standard library. Complies to binary. (you dont need to drag a run time around) And this is fast! Easy dependency management. Linting is built in. (No arguing over tabs vs spaces) First class testing. (and its fast) "good enough" coding is very fast. You can mostly ignore performance and pick it up when and where you need it. ---------------------…
> As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. I actually see this as a negative and we've been looking at Uber/Fx for more support. DI frameworks don't do anything you can't do without it, but it takes significantly more experience and technological/organizational maturity that I find the avera…
Wow, that's a pretty good take.
There is a line here though. I think a lot of people have seen what happens when you set a bunch of JR devs loose in a node/ruby code base with all that tooling. It goes about as well as giving a lead footed suburbanite an F1 car.
If you work in an agency (new every week) or in a place where you have a high number of jr devs then a framework makes a fair bit of sense. But at that point are your experienced devs being productive or being babysitters?
I think I would rather babysit a bunch of jr devs working in Go where correcting their issues is educational, rather than dealing with babysitting JR devs and high speed stupidity in something like rails...