511–520 of 614 posts
Earlier quoted context omitted.
Well that's a hard pass from me. I always knew go was quick to compile, I didn't know the lengths they were willing to go to achieve that! Case in point: it's not TB, as you stated, but rather PB.
There's both, TestBase and ParallelBenchmark.
Fortunately the rest of Go uses sensible names so I think it would be silly to avoid Go just because of that.
Earlier quoted context omitted.
For open source projects, it’s very popular in the “big data” world. Kafka, as you mentioned, but also Spark, Flink, Summingbird, Scalding, etc. And yeah, it’s a pretty popular backend language at some large companies. Twitter, LinkedIn, Netflix, the Guardian, Starbucks, AirBnB, Coursera, AT&T, etc. all make significant use of Scala. Go is certainly bigger, but Scala has plenty of adoption too.
Kafka is currently undergoing a rewrite into java.
Earlier quoted context omitted.
None with the same performance characteristics, ease of use, and ecosystem size. I'm reasonably competent with Rust, but sometimes I don't want to bash my head against the borrow checker or litter my code with copy/clone. Go hits a nice sweet spot, my main quibbles are that there's no native iterators/comprehensions or sum types with compiler checked exhaustive matching. With generics we can get libraries that allow…
Ocaml. Insanely fast compiler. Great type system. Functional programming at its best but still relatively pragmatic and easy to mix in some imperative code if need be. It is a bit more complicated than Go and the ecosystem is maybe a bit more patchy but other than you will have a good time.
Well that makes all the difference, if one is writing programs in professional capacity.
Earlier quoted context omitted.
I don’t see Go ever making headway in data science. For one, it’s not fast enough to implement algorithms directly but lacks a decent FFI; it would be burdensome to create the metric ton of new libraries that would have to be put into place. And there are Python libraries for basically everything already, from numeric computing to Bayesian time series to Spark to Torch and TensorFlow. Plus Go’s kind of weird, relativ…
Go is definitely fast enough to do data science.
Earlier quoted context omitted.
Because not all statements apply to all situations.
This is really vague and unhelpful. I’m going to interpret this to mean you’re not interested in actually explaining the problem, sorry if I’m mistaken.
I'm not even sure why I'm having to explain this. It's is a pretty obvious thing.
Earlier quoted context omitted.
> What, exactly, was gained here to justify the productivity lost while waiting? The goal isn't to wait long enough to come up with something novel. That's what research projects are for, and Go is on the exact opposite of the spectrum. If after deliberation, it turns out that a mostly similar solution is the way to go, then that's doing it "right". Also, the lost productivity that keeps getting mentioned is overblow…
Right, the design goals are it is a language for people not clever enough to deal with programming languages. "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.…
> people not clever enough to deal with programming languages.
Add older folks to this cohort. They've lost steam, are lazier and less patient with obstacles and less fortunate with time.
Earlier quoted context omitted.
IMO using Optional type means the inner value must be not null. And if it's Some(null), it should mean exactly same as None.
(Assuming we are discussing the Option type from rust) Some(null) is not a valid result. The whole point of the Option type is to let you know: a) we got a result: Some(value) b) there is no result: None
struct Foo;
fn main() {
let option_with_null: Option = Some(std::ptr::null());
dbg!(option_with_null);
dbg!(option_with_null.is_none());
}
[src/main.rs:6] option_with_null = Some(
0x0000000000000000,
)
[src/main.rs:7] option_with_null.is_none() = false
Earlier quoted context omitted.
Go could have provided message queues with priorities Erlang style or something closer native solutions in Linux/Max/Windows that are known to work. They are safe, allows to avoid deadlocks just as channels and much more flexible. And with mutex one can build those as necessary, even if interaction with channels is ugly.
Erlang doesn't have priorities natively, does it? As far as I am aware, there is a standard pattern to do it, like this: receive {high_p, Message} -> process_high(Message) after 0 -> receive {high_p, Message} -> process_high(Message); {low_p, Message} -> process_low(Message) end end The Go equivalent can be done with different channels for priorities and similarly nested selects, as I am sure you are aware.
With this code:
receive
{high_p, Message} ->
process_high(Message);
{low_p, Message} ->
process_low(Message)
end
Now Go has everything I need in a programming language!
Not for me. There is no ?: ternary operator. Having to write 6 additional lines of code for each tiny conditional sucks. It's not frequent, I think I've only had a single case in a few years where I had difficulty working around, but when it happens - it's not fun. err := h(cond(x) ? f(x) : g(x)) vs var temp T if cond(x) { temp = f(x) } else { temp = g(x) } err := h(temp) Hopefully, this can be improved with generics…
err := h(map[bool]func(T){true: f, false: g}[cond(x)](x))
Earlier quoted context omitted.
Policies don't work. It's why we lean on process in fields where correctness matters, e.g. aviation.
Policies do work if you have a process to enforce those policies. Without policy how do you define the process? "Good intentions never work, you need good mechanisms to make anything happen." http://nickfoy.com/blog/2018/4/7/good-intentions-dont-work