161–170 of 503 posts
Dear god. Compared to the go code required to do the same thing, this is crazy.
Edit: I removed reference to terraform, seems like there's no infrastructure code here, it's helm + operator.
As a Java developer... If the entire problem domain space is written in a language it's dumb not to follow suit. Libraries that solve problems reduce your work to your own specific issues, rather than 'building an apple pie from scratch'. Java is good right now because most problems have libraries to do what you want. Most formats have APIs. It's not perfect in any area - the start-up time is a bit lame, you have to…
You don't really lose anything (APIs, tools, etc.); but you gain a lot. I still use Spring. But I've now used it longer with Kotlin than with Java.
And the nice thing with Kotlin is that it is gaining momentum as its own ecosystem. I'm increasingly biased to not touching old school Java libraries. Those lock me into the JVM and I like having the option of running things in wasm, in the browser or on mobile. Our frontend is kotlin-js and it runs a lot of the same code we run in our Spring Boot server. Kotlin multi platform is nice. I've published several libraries on Github that compile for platforms that I don't even have access to. Supposedly my kt-search client (for opensearch and elasticsearch) should work on an Apple watch. I've not gotten around to testing that just yet and I don't see why you'd want that. But it definitely builds for it. I had one person some time ago trying it out on IOS; same thing (I'm an Android user).
Ecosystems are important. But it's also important to not get too hung up on them. I say that as somebody that made the bet on Java when there was essentially no such thing as a Java ecosystem. It was all new. Kind of slow and wonky. And there were a lot of things that didn't quite work right. But it had lots of people working on fixing all of those things. And that's why it's so dominant now. People are more important than the status quo.
Sometimes you just have to cut loose from the past and not go with something safe but very boring like Delphi, Visual Basic, Perl, and several other things that were quite popular at the time and didn't quite make it. They're still around and there's a half decent library ecosystem even probably. But let's just say none of those things are obvious things to pick for somebody doing something new that was born this century.
Go as an ecosystem is definitely large enough at this point that I would label it as low risk. Same with Rust. Neither is going anywhere and there are plenty of well motivated people working on keeping all that going. Same with Java. All valid reasons for using any of those. But nothing is set in stone in this industry. A lot of things people were using in the nineties did not age well. And it will be the same in another 30 years. Most of those old people that will never change retire at some point. Java projects are pretty depressing to work on these days for me. Lots of grumpy old people my age. I've had a few of those in the last few years. Not my idea of fun. The language is one thing but the people haven't aged well.
Is it wrong that I judge anyone that calls DI "black magic"? Clearly it's just computers all the way down and even spring DI isn't that hard to follow. It's one thing to call it bloated or annoying or tedious but why are we proud to announce we didn't do the work to figure it out?
Black Magic is doubly negative here, but I guess that it can fueled with the feeling that less automagic in a codebase helps downstream debug and moving to maintenance mode, as it increase the chance to let a quick grep reveals immediately where the associated code is.
Earlier quoted context omitted.
What challenge did you run into with exception handling? I'm curious because I've never felt it being onerous nor felt like there was much friction. Perhaps because I've primarily built web applications and web APIs, it's very common to simply let the exception bubble up to global middleware and handle it at a single point (log, wrap/transform). Then most of the code doesn't really care about exceptions. The only cas…
Exceptions are fine if you never catch them. So is calling abort(). (Which is the Unix way to do what you described.) If you need to handle errors, you quickly get into extremely complicated control flow that you now have to test: // all functions can throw, return nil or not. // All require cleanup. try { a = f(); b = a.g(); } catch(e) { c = h(); } finally { if a cleanup_a() // can throw if b cleanup_b() // null che…
def bracket[A, T](ctor: () -> A, next: (a: A) -> T): T =
val a = ctor();
try { return next(a) } finally { a.dispose() }Earlier quoted context omitted.
Maybe go just isn’t for you? It really doesn’t need every feature of other languages. The error handling is ideal for me, better than any other language. You are always explicit, with every function call, about “what could happen if this fails?” Maybe passing it up the stack is the best way to handle it, but also maybe it’s better to handle it somewhere in the middle. The thing that always happens with exceptions in…
Exceptions are a terrible idea. However, I strongly prefer rust error handling to Go. go: (res, err) := foo() if err != nil return err (res, err) := bar(res) if err != … Equivalent rust: let res = bar(foo)?)?; I think go should add the ? sigil or something equivalently terse. Ignoring all the extra keystrokes, I write “if err == nil” about 1% of the time, and then spend 30 minutes debugging it. That typo is not possi…
In Rust, there are cases where I have seen at least 8 consecutive symbols. Not a fan of that.
Has anybody spotted a similar story of switching from C# to go? As someone who is very fond of C#, I'm definitely curious what I'm missing out on.
> But there are obviously work around solutions in the Go ecosystem. It uses the Context ctx, which we pass around functions in order to juggle data around in the application. Man. This works. The context API allows/enables it. But I’d really recommend against passing data to functions via context. The biggest selling point of Go to me is that I can usually just look at anyone’s code and know what it’s doing, but thi…
> The biggest selling point of Go to me is that I can usually just look at anyone’s code and know what it’s doing This is not possible in Java or C#? Both of those languages are so simple to grasp.
Just on the monitoring part, Go has nothing even close to VisualVM, Flight Recorder, JRebel, VM agents, JMX.
No mention of AOT compilers, JIT caches, and so forth.
Earlier quoted context omitted.
https://github.com/codr7/tyred-java/tree/main/src/codr7/tyre... 24 of those files are under 100 lines - some of them are as small as three lines of code. and that's not a personal preference - that's mandated by Java that each type needs to be in its own file, ridiculous.
I don't see that as a problem at all, just like I don't see header files in C++ as a major problem, there are benefits as well and Java has the best IDEs of any language I've worked in except maybe SmallTalk.