Its not a typo but describes a product difference. ELT is a common term for a new type of data eng workflow that isn't mapped to ETL. In most ELT products the raw data is loaded into and then transformed by the data warehouse tool. As opposed to the ETL pipelines many of us are used to where the data gets transformed in a separate process before being dropped into the DW.
Similar story but newer hardware. I was given a machine built with left over parts from the IT company my did did sales for. Booted right to the CLI. I was given a giant red hat manual and told to have fun. It was awesome.
I don't mean to disparage the wonderful work of the lo developers but, this is in many ways what I feared generics would bring. If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language.
I am probably an old man yelling at clouds and I hope those who like this style get tons of value from it. I just don't see the benefit of trying to retrofit some of the behavior of other perfectly useful languages into Go. JS/Java/C#/Python/Ruby is a fine language. Let each of them have their strengths. I feel like trying to bolt things together this way only serves to take away what is special and valuable in Go.
I should probably shut up and just be happy lots of other people are using a language I enjoy :)
> I don't mean to disparage the wonderful work of the lo developers but,
> this is in many ways what I feared generics would bring.
What is, anything in particular about that "lo" library? Just the way it uses generics, or moreso that it's yet another library to learn to be effective? Can't argue with the latter, but as far as the former goes, I think that looks quite reasonable. It's very explicit, there's no magic going on. I think there's definitely a bar for "so much abstraction that it is discouraging to developers not into that sort of thing", and IMHO that doesn't cross it. Monads, sure, that's a tall order for many folks. But this is pretty tame.
But I am a fan of abstraction so I'm not the best judge.
Efficient map/filter/reduce chaining basically requires JIT to fuse the operations and/or a GC prepared to deal with huge amounts garbage. In Go, filter(h, map(g, filter(f, a))) will be immensely slower than the equivalent for loop.
Great point. Although, that sounds like a typical example of "let's write it the ergonomic but less performant way first, then profile and refactor as needed". That seems very tractable for that sort of refactor, especially with type safety.
Also I would not be surprised to see JIT-like behavior from go tooling, first party or otherwise, if that sort of approach takes off.
And now we introduced 2 new problems:
1. We have 2 ways of doing stuff (boring loop vs map)
2. We have a new hidden way to introduce performance degradation by importing a library that uses map
You might argue that you should know what you're importing, but in practice, it can hurt the overall ecosystem. I'm still supporting the introduction of generics, but the tradeoff should be clear to everyone.
> If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language.
Generics were widely asked for by the community for many reasons, one of the main things being reducing boilerplate and having basic polymorphic functionality that other languages provide.
I'm not trying to disparage you but: You don't know who I am, or my capabilities. Please don't be condescending to me and assume I just "don't get it" or that I am too lazy to learn the "go" way of doing things.
I am seeing that a lot in this comment section. You are judging others and coming to conclusions because we like something you do not like. I can totally understand your perspective, because I also see the danger of introducing more "power" into a language that was elegant and simple.
I respect your disagreement with introducing generics to Golang. However, please extend us the courtesy of assuming we are at least remotely competent.
Man, I totally missed the mark if this is how you interpretted my comment. I never meant to imply any competence level. Certainly didn't meant to direct any judgment at you. Simply trying express the issue I had with the lo package.
I'm really happy we have gotten generics. I think some of our lower level tooling will be much easier to build. I know lots of the community will likely be happy to have non reflect based ORMs come out of that work. I have a coworker who has expressed interest in building a new json:api parsing library with generics. Happy we have it.
The map/reduce/filter and some of the other _ style helper functions from lo was what I was trying to speak to. Those idioms just don't seem to fit well in the language. The clarity of the single way to do something in Go has been immensely refreshing. I appreciate that so often Go code looks like Go code. I also don't find myself pondering which iterator to use or chain together to accomplish something. I just quickly go to a for loop and move on. In Ruby/Java/JS/Python I often find myself deciding which chainable to use instead of just solving the problem and moving on. The language is certainly not without its warts or shortcomings. To me it feels like if those kinds of options are things you really enjoy using in a language, it would feel more natural to use a different tool. Sacrificing that clarity seems to remove some of the biggest reasons to use the language as opposed to something with fewer limitations.
Sorry if I came across as condescending. Not a stereotype of the community I intended on perpetuating.
It's worth remembering that Java and C# didn't have generics initially. And when they did get them, there was a lot of pushback along the same lines; sometimes almost word-to-word about lost simplicity etc.
18 years later, the C# and Java developers are doing fine.
It's worth remembering that C# did have them pre-release, Microsoft decided to release .NET 1.0 without them to avoid postponing the release date until they were fully done.
This is clearly described in the HOPL papers regarding generics in .NET.
I understand the gamer tag fear. To my knowledge, discord now allows for different display names on servers from your single account. I've used this for different servers where I want to use First L. naming or a character name from an mmo.
You can, but the setting is a bit hidden and when you're dealing with GenPop you have to assume they won't read anything, and find anything beyond basic features too complex. I mainly use the setting for sharing my timezone. The nice thing about discord is the server admin can precisely say what a server should look like, so people don't need to find and join channels. It's just there.
I use either karabiner on my laptop or map it in my keyboard firmware (mostly drive QMK boards for the last few years) to swap caps lock to escape on tap and control on hold. Makes vim life great. Also means that using ctrl+a as a tmux leader is comfortable to type.
I think the region has been attracting talent in the remote shift. Columbus has tens of thousands of software developers. Certainly not on the same scale as the bay but we are here. Lots of insurance and finance. VC influx from former coast vcs at Drive Capital and the folks at Rev1 have been pumping cash and resources into the local startup scene. CoverMyMeds/Root/Olive were the recent unicorns.
It might not be the well known bay/NYC/Austin but it has a vibrant scene for the population.
Looks like their faq under pricing says you can do this now! I wonder if it would work for interviews that have more than one interviewer? I might check this out for some of our needs too.
