Some would say it's the most important badge of all maybe only second to wiping the database without a recent snapshot/backup 😌

"Just a note, Kotlin doesn't necessarily assume it's running on the JVM, there are Native, JS, and WASM targets." - 🤓

@@igoralmeida9136 kick this bot outta here...

Isn't it compiling to Java? And Java to bytecode? Or am I missing the latest developments in both languages?

True, however they are using Kotlin + Spring, so it's almost guaranteed to be on the JVM. And even with Kotlin + Ktor I've only seen it run on the JVM. Do you know of anyone using for example Kotlin Native for microservices?

@@VojtasIIktor can compile to any of those services, you need to use a different engine instead of Netty iirc

All the best bud

How did you find your first gig

F# too has the option type and is a very good language. It seems that having roots in the ML family language is a very good thing!

Hm, what's there to do if there's no other handling?

​@@kreuner11 Run-of-the-mill error checks and fallbacks. You can also get try-catch functionality with really simple, very popular libraries. Rolling your own try-catch is like 10 lines of code

​@@JanJozefoGolang error handling isn't great.

@@deistormmods I feel like you just ignored the second half of my comment, which was about getting try-catches going in Go, which is ALWAYS an option even if not optimal. Regardless, Go's error handling is very robust even if we personally don't like it. It's just compiler-enforced guard clauses.

@@JanJozefo I think the "Go error handling bad" meme is more to do with the fact that functions return a result tuple that contains an error + a set of values. Allows weird edge cases where the function returns both an error and a value ... and you can ignore the error. People that are used to error unions that must be one of the other, find this a bit annoying and open to abuse. At least Go errors contain payload context, which is nice The whole "if err != nil" thing though, I don't see that as an issue at all. It might look OTT verbose sometimes, but at least it's explicit. There is nothing worse that inmplicit magic when you are trying to understand someone else's code. That's very hard to write Go code that is hard for someone else to understand.

Also, on Java, quality tools like to bitch if you state that a method is going to receive an Optional as a param. They don't want you to do that for some reason. You have to receive the var and envelop it in an optional inside the method, and have to do that in every method. Quite silly if you ask me.

​@@Titere05I think it is like that because you can pass null instead of Optional as an argument

null is just incredibly useful thats why we love it so much

not "liking null" is a memory management skill issue, that should go away the moment you hear the words "pointer", "stack", or "heap" a pointer on the Stack is the size of int, and the thing you are pointing to could be Far, Far larger then L3, or even RAM could hold, like what is the Size of a given Map(T): "(number of elements + a magic amount of elements) * structure size" so even the option wrapper might not be able to hold the entire Map. and testing if(MyDataType) or the more explicit if(MyDataType != Null/nil/nullptr) is just sanity. the other problem with java and Null is the wrangling it can do for the sake of "truthiness", has "null reference exception 0x0000" or "out of bounds exception" destroyed far to many programmers, that doesn't mean null is bad, it means "and next time we're going to check for null right?" (nods head while looking at ground)

@@gardian06_85 pointers are almost always 8 bytes idk what u mean is the size of int

> maybe

Maybe they just wanna to have some fun, what's the fun part if you can't wipe your prod db easily and lose a ton of money?

@@lauraprates8764 that money was asking for it.

I also feel the "we where down for an hour and lost $xxxk in revenue!" Claims forget that if something's broken people will comeback and try later. Outages happen and most clients will understand having an occasional hour long outage

@@Patmorgan235Us valid, unless it's for some sort of live event

oh nice. i assume you are brewing it manually as well. do you make it with french press or do you have fancy brewing equipment? i never really timed it but i think my similar routine takes around 7-8 minutes total, 4 min brewing time for filter coffee. seeing anyone using a hand cranked grinder makes me really happy.

@@ardnys35 no I gave up on all that and just use drip, lol. The biggest difference is using a burr grinder, I think. I even had an espresso machine at one point, but it wasn't worth it. At some point my french press broke, so I broke out my old Mr. Coffee. Hotter water would be better, but the drip method is almost as good. I'll pick up a new french press someday, if I see one on sale. I got the hand cranked grinder because the good electric burr grinders were $$$, and I didn't want to buy one only to decide I liked a different one better. Plus, when I'm making coffee, I'm trying to wake up anyway, so adding a little elbow grease into the ritual is pointing me in the right direction.

Yep, can't catch errors if you don't throw

@@jimhrelb2135but you can uncatch errors…

Go doubled down on the C nil train. You have to be more explicit in rust when you write something like an unwrap instead of more careful handling, but using unwrap is roughly the equivalent of not checking nil in go.

It can be simulated with generics for your own library uses, but in order for it to become an option in stdlib and generally pushed as a standard, we'd need a breaking version change, and that's something the Go team isn't really into until there's enough reason to do it. Backwards compatibility is a huge selling point and Go isn't likely to break that anytime soon

I've come across this before with different terminology. Whenever we've had two similar systems where we want to transition from System A to System B, we'd do it in a couple of steps. Step 1 would be what we called ghosting, where System A is live and System B is run in the background while its output is tested. Then System B is live while System A is kept running to roll back to in case System B fails. Then System A is taken offline. Key takeaway is that we called it 'ghosting' not shadow testing. But I think the idea is the same.

We always called it mirrored traffic. Same thing. It's a great approach. Once you build your tools it's possible you can use the collected traffic to simulate testing during development and testing.

To be fair one defer recover inside goroutine would also keep the service alive

Exactly maybe for production revenue generating apps, just keep using the stack the team is expert in unless the current tech stack is giving some issues. As they say " if it works don't touch it". Ofcourse using some other language would make sense for say some experimental project.

he be speaking the language of god

is this in cases where UTF8 strings might include multi byte characters?

here is the JDA lord. thanks for your work haha

​@@y00t00b3rI assume a string represents an array of chars in an encoding and indexing takes care of it? Not sure

@y00t00b3r yes, if you take a slice of a multi byte character not on a char boundary, there will be a run time panic. Note that directly indexing into a string is not allowed, only slices can be taken. Taking a slice of string is not recommended. You can get around this by using .get and handling the case when it’s not on a char boundary, or more preferably being explicit with what you want with .chars to get an iterative of chars or .bytes to get an iterative of bytes, neither of which can fail during runtime

@@muddycalendar3292 unexpectedly good reply!

​@@nisonatic well, no lsp warnings aside it's a pretty loud stacktrace :D

Same. I don't know how to code in any language yet. Having ChatGPT open and pausing to ask it to define terms I'm not familiar with helps

There is ifPresentOrElse which allow me to handle the error on point and there are functions to assign a default value if the optional is empty. There are nice functions for a lot of use cases and I have been getting a lot less NullPointerExceptions. but these are a bit weird when you just see them in these languages. i learned it first with Rust and then transferred the ideas to java. i tried to explain Options and how nice they are to many people but they don't really get it

@@nisonatic If you use Optional.ofNullable(value) the optional itself cannot be null

Go has _a_ type system, but not a sophisticated one. the lack of null-safety probably stems directly from this trade-off (sac ADTs to gain simplicity). other languages also make simplicity a core value but make different trade-offs in doing so... everyone's favorite newboi Gleam seems to be one of these, and i'd bet that one can learn a lot from contrasting the two

@@radfordmcawesome7947 Go has static duck-typing, basically. I'd say it's sophisticated, even though it's not complex. OTOH, basic null tracking is quite straightforward. You just paint stuff nullable or non-nullable, that's it. What am I missing?

@@McFrax I would consider Algebraic Data Types to be "sophisticated" as it lets you compose types ad infinitum. The language would also have to treat the types as first-class citizens to qualify in my book. I wasn't referring to null-handling specifically. I have to admit that I haven't looked deeply at Go since before it had generics, so I may be misinformed. The most Go I do these days is mess around with other people's k8s controllers when something goes down at work.

One thing I dislike about std::optional is the implicit padding from that lone bool. I want an optional that can be grouped in memory as bool[8] followed by the payload for those 8 variables.

@@JuusoAlasuutari That's fair. There is definitely a cost to using std::optional or std::expected. For my frequently called functions, I still choose another strategy.

@@ISKLEMMI it wouldn't be exceedingly hard to write an "optional_set" or similar actually, if anyone feels like implementing it ;)

​@@JuusoAlasuutari Seems like something that would require polymorphism, which would break if you returned optional_set by value. Not certain how you would achieve that without some additional flag byte. ¯\_(ツ)_/¯

yeah, that was an interesting thread in the issue tracker... :/

loop variable fix was a good and awaited change Iterators would make the language more complex and Go strives to be a simple language (I do fear that at some point someone will still add them just like they did with generics though) Not everything needs to be a kitchen sink like C++ or Rust I really love how stable and backward-compatible Go is

@@bionic_batman Other languages, like JS (w/ var) or Python, have the same behavior w/ for, so almost none care about it. And, there some dudes suggested just adding new syntax construction, like 'foreach', to cover this fix and backward compatibility. It was just neglected. The Go way... Golang possibly would be a simple language. But it is just pretending to be, instead, it is rather "ad-hoc" language. Almost any piece of language is built in a non-obvious way, different from almost any existing language. And worst of all, new fixes just add new ad-hocs, and devs instead of having some solid instruments, that should be learned once and can rely on in any conditions - like generics or iteration protocol - have to learn all nuances of those ad-hocs and their combinations. The main focus of language developers is clearly in the wrong place. The sum-type (enum)? No. Some Option type? No. Better syntax for handling errors? No. Support custom collections in loops? No. The MIN and MAX built-ins! YES! You lack it! You need them so badly!!! ))))

@@AlexanderBorshak Sometimes less is more. Just accept that Go has different philosophy which really shines when you have a large team of devs working on the same codebase. If you prefer languages with kitchen sink mentality that have all sorts of bells and whistles which iterators and sum-types are then use Rust, nobody forces you to use Go But making all languages into the same strange monstrosities that have tons of different paradigms mashed together is a really bad idea. Some people just value backward compatibility, simplicity and stability over some badly over-engineered syntactic sugar mess

@@bionic_batman The irony is, that even with 'for' despite just one syntax construction there are many semantics - one for regular loop (C-style), one for while (for w/ condition), one for 'foreach' (w/ range), and one for infinite loop (w/o conditions). So it's just trying to pretend simple, while you still have to remember all nuances of each semantic, so having different syntax possibly even would be better since the mental load would be lower. But OK, I accept "different philosophy which really shines". Let it shine!

It doesn't work in all situations. You can clone the DB so the shadow gets its own data store, if your calling out to other external services that have side effects it's probably not a good fit for shadow traffic.

Exactly. You need to have really thought through your "is shadowing" env flags or whatever is best to mock up or turn off or otherwise handle all of those things the best way you can engineer. The more complex the system, lots of microservices lots of third party apis, bockchains, emails, sms, S3, kafka, nats, stream processing, billing and payments, lord knows what, your shadowing can really get you into trouble if you have not engineered your shadowing for all of that ( looks like our shadow double billed everyone and deployed 50k redundant smart contracts ). Crud app that cruds to a DB? Shadowing is a simple and great choice.

seems not that much experienced right right? lol its literally the first fuk up someone do in go

Prime never shows up here. Prove me wrong.

@@y00t00b3r it's an open question to anyone not prime only (although his suggestion means lot to me). and I didn't know that.

Programing sub reddits might be a better place to ask this question. There are a bunch of great books that cover these topics from O'Reilly and Manning.

@@H-Root Honestly, just lurking in Prime's chat on Twitch might get you a long way.

While this is a fair point, it's also pertinent to point out that the source of that null value is a Java library: null-checks on platform types (e.g. values coming from Java code) are relaxed so that you aren't forced to elvis every single value you get from Java. The unexpected NullPointerException is a consequence of the limitations of the Java type system and the convenience that Kotlin provides for interacting with it. You'll be hard-pressed to get a null from pure Kotlin code without shenanigans. There is unfortunately no way to make the compiler enforce this, but you could in principle follow a convention of always assigning platform-typed values to variables of nullable type. IIRC at one point the Kotlin compiler forced you to !! every platform-typed value, but this turned out to be impractical so it was dropped.

Yes. That’s what he’s talking about. So like Optional etc

why are builtin maps not safe for concurrent reading? does reading modify internal state?

@@teodormaxim5033 I believe it's due to how it does the key lookup internally. It doesn't like multiple happening on the map at once. I've seen maps end up in a state where multiple keys end up having the same value in memory, the original values lost to the wind after only reads/lookups, not great for a thumbnail cache let's say (last time I saw it was a map of string to []byte for thumbnails a front-end was requesting like 20 at a time for a webpage when it loaded). It's a shame that Go only has one builtin map type and it's very not thread-safe. It is very efficient though as a tradeoff afaik. The tldr, which the docs do mention but I don't think quite stress hard enough is always access a map via a mutex for concurrent access, regardless of what you're doing with it. Once you've got the value out of the map (even if it's a map of pointers / slices etc) you can unlock it and do whatever you want with the value without having a lock and be thread-safe, the issue seems to be the mapping of the keys to the values rather than the values themselves moving around or changing underneath you.

There's also an issue with slices I think and how some web frameworks work (thinking Fiber), so pulling a slice out of a map and throwing it straight into a response without cloning I think can end badly due to some pointer cascading. There's quite a few annoying caveats with slices now and then depending on how they were made but if in doubt, clone.

C# had nullable value types from the start, that is a different thing. Nullability analysis for reference types came only in 2019

It's better since you handle real world payloads instead of the happy and known error paths. Production traffic can suprise you

@@EdubSi that makes sense

Yes shadow traffic is a kind of testing. It's the closest you can get to putting your code in production without actually serving real clients. Writing a bunch of unit test is not the same thing though.

No, Option is the same as Kotlin's explicit nullability. Therefore, "Option" is Kotlin's "String?".

That's why Rust is infinitely times supperior to golang. If it compiles, it's most probably ok. If it does not compile, then there is a skill issue.

​@@svetlinzarev3453Well, rust is safer but that doesnt equal superior. You know, choosing the right tool for the right job. While I dont like go's nil pointers (altough there is tooling to catch these errors in the ide) this story has so many red flags that we cannot blame the whole thing on the language. Ps: I love both rust and go

@@svetlinzarev3453 I can make Rust code that has expects everywhere, it will compile just fine but will crash in production No amount of safeguards will prevent you from shooting yourself in the foot if you are persistent enough

Option(mentioned)

So, obviously, they are NOT the same thing, since with Option you MUST check if a value exists before using it, i.e. Option gives you strict guarantees; while null shifts all responsibility onto you. It's opposite things, not the same.

@@AlexanderBorshakI think he’s referring to null in null-safe languages like Kotlin, where null is truly just syntax sugar for Option. Kotlin’s “!!” operator is exactly the same as “.unwrap()”, “?:” == “.unwrap_or”, and “?.” lets you call a method (or read a property) if and only if the value is not null. By default, you can’t do anything else with a value of type “T?”