101–110 of 559 posts
Earlier quoted context omitted.
It doesn't matter but I fully disagree with this. A transpiler emits code the user is supposed to understand, a compiler does not. At least that's the general way I've seen the term used, and it seems quite consistent.
Yea, not sure i disagree with anything being said here. Though to me, transpiler just typically means it goes from one language i could write, to another i could write. I don't necessarily expect to enjoy reading or perhaps even understanding the JavaScript output from any lang that builds to JS, for example.
What possible compiler target couldn't you write? Compilers are not exactly magic.
This seems to achieve a similar type safety complexity tradeoff as Gleam [1] does. However, Gleam compiles to Erlang or JavaScript, which require a runtime and are not as performant as Go. I wonder if Borgo's compiler messages are as nice as Rust's/Gleam's, though. [1] https://gleam.run/
Ymmv, you might be surprised if you actually bothered to benchmark. Depending on the workload, either JS or erlang can ultimately turn out on top.
They're all optimized to a degree that each has a niche it excells at and leaves the others in the dust.
even with heavily scewed benchmark like techempower fortunes (https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...) you end up with JS getting ahead of Go with raw requests. And not just slightly, but by 1.5 times the throughput.
In other benchmarks, Golang does indeed win out with similar or even bigger advantages... so the only thing you can ultimately say is ... that it depends. Its a different story if you chose other languages though. But JS, Golang and Erlang are all extremely optimized for their ideal usecase.
Is it correct to say Borgo "compiles to Go", or should it say "transpiles to Go" It appears to be a transpiler (consumes a Borgo and does the work to convert and emit a Go program as text): https://github.com/borgo-lang/borgo/blob/main/compiler/src/c...
The word "transpiler" propagates the misunderstanding that there is something special about a compiler that emits machine code, that requires some special "compiler" techniques for special "compiler" purposes that are not necessary for "transpiler" purposes because "transpiling" requires a completely different set of techniques. There aren't any such techniques. If one were to create an academic discipline to study "…
Earlier quoted context omitted.
> 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 a…
1. a given interface is provided via a DI module 2. said modules are included in a binary
With decent codesearch, finding the implementation of a particular injection for a given deployed binary is usually a fairly short search.
I'm sure there is all sorts of extra voodoo you can get up to, but the straightforward DI case is, well, straightforward.
Earlier quoted context omitted.
I love Go's letter casing. It's such a neat way to remove cruft.
It also adds cruft. Public struct members JSON usually needs to be converted to lowercase. Hence the stuct tags.
Structure privacy, OTOH, does. Count me in as someone who really enjoys the case-based approach. It’s not the only one which could work, but it does work.
This and pub/private modifiers for structs instead of letter casing is all I've ever wanted.
I love Go's letter casing. It's such a neat way to remove cruft.
Earlier quoted context omitted.
If Rust was already matured by the time Docker was rewriten from Python, and Kubernetes from Java, I bet that Go wouldn't have been the lucky candidate.
I like rust, I write go. There was a thread here the other day where a rust dev pointed out that "Rust is the language tokio ate"... https://nullderef.com/blog/rust-async-sync/ Rust is a lot of overhead when go is "good enough" for 99% of what needs to get done. That doesn't mean go is good for everything. I would still rather write Rust than C or C++ or bunch of other languages. Look at a project like Pingora, from…
Now thanks to Docker and Kubernetes adoption success, we're stuck with it.
At least now generics are supported, unless one needs gccgo, maybe in 10 years we get Pascal enumerations.
Earlier quoted context omitted.
I love Go's letter casing. It's such a neat way to remove cruft.
I spent quite a few hours tracking down bugs due to miscased struct fields unfortunately. Strongly prefer explicitness over implicitness
Earlier quoted context omitted.
I love Go's letter casing. It's such a neat way to remove cruft.
It also adds cruft. Public struct members JSON usually needs to be converted to lowercase. Hence the stuct tags.
The moment you integrate with a third party your US centre zip_code field is suddenly coming over the wire as postCode. The conversions are going to go on, at least in go I can define all of that conversion with ease in one place.