41–50 of 75 posts
[dead]
> Performance is good enough, it's not the intellectual masturbation of Scala or Rust. As we know, any technology that would require experienced programmers to learn something is a crime against engineering.
Earlier quoted context omitted.
I know C, python, Go and Rust reasonably well and Go is usually my default choice for a new projects. Well unless it's just a quick script, in which case Python will do just fine. Tried Scala while learning Chisel and hate it from the bottom of my heart. It's like Kotlin on bad drugs. My point is, people are different.
> Well unless it's just a quick script, in which case Python will do just fine. Weirdly Go has made me enjoy Python even less and compilation is so fast it's turned into my go-to for quick "scripts."
Lack of support for operator overloading is a bit sad. As a result, Go can't get used in numerical applications, unless you like writing `matrix_plus(A, B)` instead of `A + B`. Is there a programming language that has a "simple" design like Go but which supports some operator overloading?
Earlier quoted context omitted.
I'm really not a fan of small qol features like this. I think it really hurts readability for the general audience. The function itself is minimal overhead and is clearer to the reader.
That's true, we should get rid of operators for primitives too.
That said, Go sticks to the most basic operator implementation (strings, numbers etc...). Go doesn't support `+` on slices for instance.
Earlier quoted context omitted.
> Performance is good enough, it's not the intellectual masturbation of Scala or Rust. As we know, any technology that would require experienced programmers to learn something is a crime against engineering.
It’s also really gross how we want ultra prescriptive tools that force you to write things certain ways because we can’t trust our own coworkers to write decent code. Or learn things for that matter. I guess people don’t do code review at all? This was tried before and it was called Java. But there’s always an eager generation of naive programmers willing to believe the lie that this time is different.
You have to learn many restrictions, a number of which feel arbitrary/highly subjective, and follow that. Of course, the style guide evolves over time so it's not like legacy code is consistent with new code.
The end result is that I much prefer the Go way of having fewer options in the language, instead of having those options in the language but restricting them via policy.
Earlier quoted context omitted.
Your last sentence seems fishy to me. Are you suggesting that support for C++ like operator overloading is a necessary condition for, say, autodiff? I thought Go is a Turing complete language.
Operator overloading is about syntax and type safety. Brainfuck is Turing complete.
Earlier quoted context omitted.
I was with you until you slagged on the other options. Rust and Scala are designed for other use cases than yours. That doesn’t trivialize their worth.
> Rust and Scala are designed for other use cases than yours This has become a sort-of gotcha for any discussions that involve comparing programming languages, but I think it has been over-extended beyond what is reasonable. It is true that some languages are much better at certain use cases than others, and especially if you consider their ecosystems when making this determination. For example, I don't feel Go makes…
[dead]
> Performance is good enough, it's not the intellectual masturbation of Scala or Rust. As we know, any technology that would require experienced programmers to learn something is a crime against engineering.
Earlier quoted context omitted.
Adding matrices with A+B looks nice. But then you'll soon want to do A*B+C, and you'll find that fused multiply/add is a much faster operation than doing a multiplication and then addition, and soon you'll either be writing mul_add(A, B, C) anyway, or you'll overengineer a complex solution to make A*B return some kind of object that can recognize the subsequent + operation etc. Update: corrected * representation
You can have your cake and eat it. E.g. C++ expression templates allow you to fuse application of multiple operators.
So yes, you can have efficient nice abstractions, but only at the cost of an extraordinarily complex base language.