|
eschaton posted:that’s a fine way to do things in Smalltalk, it’s clear there that everything is a message-send including iteration for all of ruby's manifold flaws, literally everything is message-sending. that is how the language worked from day one. this was, indeed, shaped by perl. all OO operations in perl are message-sending, influenced by smalltalk. ruby took the basic design of perl and extended it "backwards" to the language primitives. since ruby 1.0 had no perl 4.x to with which to remain backwards-compatible, it's turtles all the way down. there is little or no non-OO baggage hanging around that doesn't respond to the same message passing as user objects.
|
![]() |
|
![]()
|
# ? Jun 18, 2024 04:52 |
|
Notorious b.s.d. posted:this is entirely true, but it's equally true of virtualenv and python. deffo true honestly I kinda think this is why go took off so hard for tooling the whole gopath thing is the stupidest loving thing I've ever heard, and dependency management is braindead just like every other scripting language, but only one person actually needs to make the build work. if all you need is to run it, you just download the binary and it works
|
![]() |
|
eschaton posted:the meta programming is way better in Lisp and Smalltalk than in Ruby because everyone’s special DSLs fit in with the base language so much more, and you can therefore develop much better tooling to work with them (and bring more of the standard tooling to bear too) what if we wrote a language for people who werent showboating assholes though
|
![]() |
|
who would write it?
|
![]() |
|
tef posted:what if we wrote a language for people who werent showboating assholes though this was supposedly an explicit design goal for go, and what we got instead was a language designed by showboating assholes for people they think are stupid and incapable of learning
|
![]() |
|
Internet Janitor posted:this was supposedly an explicit design goal for go, and what we got instead was a language designed by showboating assholes for people they think are stupid and incapable of learning dunno about that, go used that an an excuse to avoid features rather than justify the featureset go wasn't so much designed but, it's part of a long series of hacks on C, starting with plan 9 so, plan9 c added things like anonymous structs alef came later, adding tuples, channels. (it also had generics) it wasn't until limbo came along that gc, modules, and types started coming after values then golang kicks off, from the original plan9 c compiler as for golang itself, it didn't really design that much, outside of the interface {}, gopath, and go fix/fmt and it still doesn't have much in the way of metaprogramming, or fancy semantics i'm not sure "showboating assholes for people they think are stupid and incapable of learning" is a reasonable descriptor when go came out, people were asking (and still) ask for a scalaz like feature set it wasn't so much that they thought go programmers were incapable of learning, or that they woudl be stupid but that the programs they were writing would be boring, not needing too much decoration that a new programmer shoudn't be burdened with learning a lof of new ideas to get started but yeah rob pike is a complete rear end in a top hat a lot of the time so i hear
|
![]() |
|
in practice i have a pretty sour opinion of go because all of the go codebases i have seen, including those written by experts and contributors to the language itself, are composed of reams upon reams of repetitive, copy-pasted logic. whether it is the lack of generics driving people to manually template-expand custom data structures, the lack of exceptions driving people to manually template-expand error propagation, or the general fear and loathing of anything except endless fields of for loops cultivated by the community's vocal anti-intellectual stance, golang appears to cultivate technical debt. it's like a built-in linguistic broken-window scenario: tools to abstract and reuse code reasonably do not exist by design so huh I guess I'll just mound on more garbage. how simple. at the micro level, go code is indeed straightforward and permits local reasoning. i argue that the sprawl of go codebases more than compensates for this benefit.
|
![]() |
|
Go just seems like it only aspires to fulfill Google's specific use case, which is C + garbage collection + static linking as a replacement for C for linux command line programs and network daemons, with the one modern addition of message-passing concurrency. It has already done that, so they don't really have any need for features like generics which would be necessary to turn it into a decent general-purpose language.
|
![]() |
|
tef posted:but that the programs they were writing would be boring, not needing too much decoration ... java?
|
![]() |
|
hackbunny posted:... java? honesty not that bad in hindsight, athough 1.5 could have happened quicker, and giving up on hardware jvms and embracing invoke dynamic, sure
|
![]() |
|
Internet Janitor posted:in practice i have a pretty sour opinion of go because all of the go codebases i have seen, including those written by experts and contributors to the language itself, are composed of reams upon reams of repetitive, copy-pasted logic. yeah but the alternative is scalaz where it's one line of code you don't understand instead of 20 you do ![]()
|
![]() |
|
the solution to scalaz poo poo is simple. dont put that crap in the std.
|
![]() |
|
tef posted:yeah but the alternative is scalaz where it's one line of code you don't understand instead of 20 you do literally the only other alternative yeah
|
![]() |
|
gonadic io posted:literally the only other alternative yeah yep it's almost like it is a tradeoff rather than an arbitrary set of good and bad points like, having a language with relatively simple to implement features with a goal of fast compilation times might not end up with generics, or row polymorphism, or lenses or a language that's about expressing higher order combinators in a more object setting might not end up with boilerplate, but might have achingly slow compilation times and a definition of map that's worth writing a blog post about or a language that's about pay as you go, really means a lot of boilerplate because for the most part, as you go, you pay
|
![]() |
|
As I grow older, I find my tastes change. My preferred codebases to fix bugs in and maintain are those that are relatively dense, long, and shallow. From that perspective, C and Go tend to be pretty readable. I've never written Go, and from what I've read, it's certainly not in any way a perfect language, but it doesn't offend me the way modern JavaScript practice does -- single-line functions in their own modules, blog posts by people who proudly proclaim they got rid of the if statement in their code... I do wonder how many people, especially proponents of metaprogramming, sit down and read code in one sitting like I do.
|
![]() |
|
my totally flippant opinion of Go and Node.js is that they're the two communities that are the largest proponents of microservices because both language are lacking in terms of facilities to allow the abstractions and code organization required to make a large code base maintainable. The weaknesses in the languages must be palliated by architectural patterns which enforce concepts (i.e. demarcations of programming in the large vs. programming in the small) that are hard to express with the base language itself.
|
![]() |
|
fits in nicely with that idea that design patterns exist to fill in holes in the language itself
|
![]() |
|
it seems to me that microservices is more about a weird obsession with decoupling, taken to a ridiculous extreme. like for example each microservice must have its own database, and you have to create other microservices to keep those databases synced ![]() I never noticed a correlation with specific programming languages, to me it feels more like a "natural evolution" to OOP's obsession with encapsulation and something about enterprise bureaucracies.
|
![]() |
|
microservices are easier to patch, upgrade, and scale. they are good afaik.
|
![]() |
|
Symbolic Butt posted:you have to create other microservices to keep those databases synced
|
![]() |
|
Symbolic Butt posted:it seems to me that microservices is more about a weird obsession with decoupling, taken to a ridiculous extreme. like for example each microservice must have its own database, and you have to create other microservices to keep those databases synced this is the post of a person who read the wiki for microservices but has never worked with them in any capacity decoupling at the service level is super cool and good. obviously it can be taken to extremes but so can anything. just model your domains and find the logical separations between operations and their storage requirements
|
![]() |
|
I'm just repeating what some microservices book said about how you should "refactor your monolithic database", maybe I just looked into a particularly terrible book? but idk, I vaguely remember some post from MALE SHOEGAZE describing this kind of dumbass attitude towards microservices databases, so I feel like that's a common approach that people take seriously.
|
![]() |
|
microservices shouldn't have databases. the second they do, they're no longer micro.
|
![]() |
|
people do take the microservice databases approach seriously and they are idiots
|
![]() |
|
luv 2 cosplay as google whilst working for an idiot 4 man fart startup
|
![]() |
|
necrotic posted:people do take the microservice databases approach seriously and they are idiots at my job each microservice has its own (mongo) database and entities that need to be available to multiple services (there are tons of them, as you can imagine) are synced by dumping them into kafka. it's a nightmare and the worst system i've ever dealt with. i've repeatedly broached the idea of consolidating the databases because there's just no reason to have them split up but "this would result in coupling" so it's never going to happen.
|
![]() |
|
maybe you should decouple from your job
|
![]() |
|
MALE SHOEGAZE posted:i've repeatedly broached the idea of consolidating the databases because there's just no reason to have them split up but "this would result in coupling" so it's never going to happen. you should have replied "with your face, fat chance"
|
![]() |
|
MALE SHOEGAZE posted:at my job each microservice has its own (mongo) database and entities that need to be available to multiple services (there are tons of them, as you can imagine) are synced by dumping them into kafka. it's a nightmare and the worst system i've ever dealt with. a service should have its own persistent database when its the owner of that data and all state changes go through it. if another service can't correctly interact with that data through just the first service's apis then they probably aren't separate services, and they are already coupled. the only difference is with one service you have a tractable coupling problem and with 2+ you have an intractable coupling problem. Symbolic Butt posted:it seems to me that microservices is more about a weird obsession with decoupling, taken to a ridiculous extreme. like for example each microservice must have its own database, and you have to create other microservices to keep those databases synced having not worked at a very small company doing microservices, i always get the feeling that there is not enough consideration of ownership since everyone works on everything and you're operating at a scale that sweeping cross service changes are still fast. as you scale up and teams break apart and have more concrete ownership lines, state synchronization across service boundaries becomes somewhere between untenable and insane. at the same time you probably haven't developed an internal culture of being a good service owner, so you have difficult to use safely APIs and backwards incompatible changes out the wazoo. imagine (almost) every service you build as being owned by a separate team with a distinct reporting structure, whose customers have no idea what the internal implementation is and rely on documented and undocumented API behaviors, who get really pissed when you break any of those behaviors, and whose only means of contacting you is via a pager at 2am. if you do that, you'll probably write fewer and better services :/ tl;dr treat your service like its the kernel and your customers are userspace
|
![]() |
|
also event-driven synchronization and post-hoc reconciliation are the 1920s devil and you should probably go somewhere else first for your fix consistent transactions are the bedrock of any successful large tech company, and its no surprise that google and amazon are built on top of consensus as a service
|
![]() |
|
MALE SHOEGAZE posted:at my job each microservice has its own (mongo) database and entities that need to be available to multiple services (there are tons of them, as you can imagine) are synced by dumping them into kafka. it's a nightmare and the worst system i've ever dealt with. go work with your friend on that .net stuff
|
![]() |
|
I haven’t really dealt with microservices, but I have dealt with a monolith that thought it was a microservice. It would call itself over HTTP.
|
![]() |
|
MononcQc posted:my totally flippant opinion of Go and Node.js is that they're the two communities that are the largest proponents of microservices because both language are lacking in terms of facilities to allow the abstractions and code organization required to make a large code base maintainable. The weaknesses in the languages must be palliated by architectural patterns which enforce concepts (i.e. demarcations of programming in the large vs. programming in the small) that are hard to express with the base language itself. wow i never thought about it this way but you are completely loving right
|
![]() |
|
fleshweasel posted:I haven’t really dealt with microservices, but I have dealt with a monolith that thought it was a microservice. It would call itself over HTTP. ![]()
|
![]() |
|
Suspicious Dish posted:As I grow older, I find my tastes change. My preferred codebases to fix bugs in and maintain are those that are relatively dense, long, and shallow. From that perspective, C and Go tend to be pretty readable. I've never written Go, and from what I've read, it's certainly not in any way a perfect language, but it doesn't offend me the way modern JavaScript practice does -- single-line functions in their own modules, blog posts by people who proudly proclaim they got rid of the if statement in their code... i wonder how many proponents of metaprogramming ever sit down and read someone else's code
|
![]() |
|
JewKiller 3000 posted:wow i never thought about it this way but you are completely loving right also the people who gravitate towards bad langs like go and node tend to be those who dislike good frameworks, libraries, and standards which would require better language features.
|
![]() |
|
fritz posted:i wonder how many proponents of metaprogramming ever sit down and read someone else's code I stopped touting metaprogramming after trying to use other people's code. What a loving nightmare and I hate that I ever liked it.
|
![]() |
|
necrotic posted:I stopped touting metaprogramming after trying to use other people's code. What a loving nightmare and I hate that I ever liked it.
|
![]() |
|
necrotic posted:I stopped touting metaprogramming after trying to use other people's code. What a loving nightmare and I hate that I ever liked it.
|
![]() |
|
![]()
|
# ? Jun 18, 2024 04:52 |
|
same these days i just do functional programming wank in js to scratch that itch instead lol react and its whole ecosystem do kind of act as enablers for it, too
|
![]() |