|
the one good thing jonathan blow did was the puzzle game grant for underrepresented developers (https://www.gamesindustry.biz/articles/2018-03-20-the-witness-studio-offering-usd20-000-grants-to-underrepresented-developers), and i have a friend who was on the committee that decided who gave out grants who said it only worked because everyone yelled at blow constantly to the point that he just withdrew from the decision making process entirely. not that he admitted that he was ever wrong, mind you; he just withdrew because he didn't like getting yelled at. the dude is lovely as hell. anyways, am i right in assuming that this is the rust ecs talk he was mad about? i'm gonna watch it, i guess. i've been writing a unity-style component framework for games in typescript, but a proper ecs system that separates state and logic seems closer to what i actually wanted. i used to try to build functional games but never knew how the gently caress to structure them; while an ecs system like this isn't really "functional" it's closer to the ideal i wanted when i was doing that, i think. i guess with the coming of webassembly i guess i could start looking into actually writing games in rust, but i do like typescript quite a bit. dunno if rust bridges to stuff like canvas or pixijs are up and running yet. converting the stuff i've been working on to ecs would probably be a nightmare but it might be interesting to build out a little ecs implementation in typescript or something abraham linksys fucked around with this message at 22:20 on Sep 14, 2018 |
#
¿
Sep 14, 2018 22:16
|
|
|
|
| # ¿ Mar 20, 2023 09:54 |
|
|
do people who hate the concept of javascript frameworks also write all of their web apps with no abstractions between them and a standard library http api or what
|
|
#
¿
Oct 19, 2018 22:27
|
|
|
i remember asana and slack were two companies that were very publicly proud of having home rolled their own JS frameworks, and of course they both became monstrous and awful, and now they're both being/were rewritten in react, so that's cool github also did this with atom (though tbf i think they actually rewrote the main editor in react and then once again back to vanilla js because of perf issues, but, yknow, don't build a loving text editor core in a framework that isn't specifically optimized for that) and going all in on turbolinks of all fuckin things for the main site abraham linksys fucked around with this message at 00:42 on Oct 20, 2018 |
|
#
¿
Oct 20, 2018 00:37
|
|
|
prisoner of waffles posted:Honest question coming from a place of pure ignorance: what's wrong with turbolinks? Sounds like a reasonable compromise between a "one HTTP request per view" back-end and a "walks like an SPA, quacks like an SPA" frontend this analogy is a bit of a stretch, but turbolinks is kinda like the css cascade in one of those things that works out very well for the people who put a lot of time and thought into working with it, and terribly for the other 90% of people basically: the kind of javascript code people usually want to write for server-rendered, "stateless" (or, more accurately, "short-lived") pages tends to be very "throw some event listeners down and forget about it," whereas turbolinks breaks this idea on a pretty fundamental level i'm far from a rails expert, but my understanding is that the traditional turbolinks experience is "everything works totally fine until suddenly you transition pages and get a completely baffling javascript error caused by stale state." this article covers some of the issues, and their workaround is a significantly different way of writing your frontend code, which... is fine, except the whole selling point of turbolinks was to not have to write your frontend code differently and i mean, everyone here who has used the github web interface, especially prior to like 2016 or so, has encountered the common bugs with turbolinks and PJAX-style solutions, where things don't load correctly and don't have error states (because turbolinks means you're not supposed to have to think about it!), or you hit back mid-navigation and the page gets in a hosed up state, etc. these are totally issues in other SPA architectures, but turbolinks seems unique in not giving you the tools to reason about it i am still sort of interested in pjax-style solutions, but you just need a lot more stuff to make it robust. hell, even turbolinks now has a "sister framework" (launched less than a year ago!) called stimulus that's supposed to be a framework for working with server-rendered html, which is a fantastic idea for turbolinks/pjax, but one that you had to roll yourself until now, and... thus, more jquery spaghetti was born, and in addition to being bad code from the outside was harder to debug because of the pjax stuff happening, and ugh (currently ripping turbolinks out of our admin panel due to some long-standing bugs we uncovered after i added production frontend error reporting on my 3rd day at work, egh)
|
|
#
¿
Oct 20, 2018 01:04
|
|
|
ive started rewriting a node/typescript/express web api in kotlin (w jdbi and some random express-ish web framework called javalin, which is nice but i do wonder if i should just use spring boot?) turns out this is basically what i wanted server-side typescript to be. the resource usage is p significantly higher to the point i've already had to figure out a couple command line settings to tell the jvm "hey i don't have infinite fuckin ram here please do some goddamn garbage collection" (apparently this is partially because i was using jdk8 with docker which breaks a bunch of the normal "look at the system resource availability" stuff). also not having things async-by-default kinda bugs me but in a language where you can, like, have an i/o thread pool, it doesn't seem to matter that much? and if any web framework (besides jetbrains's garbage semi-official one) starts using kotlin's coroutines that'd be nice too the main problem is that i think navigating the jvm ecosystem is tricky in the same way that navigating most ecosystems that don't have an obvious happy path is (even spring boot has something like 40 different packages you can choose to enable when you create a project), not a real obvious stack and happy path. the backend at my workplace is all java/kotlin so i have been pilfering from there pretty successfully, but it's weird. like, jdbi isn't hugely popular, but it's fairly intuitive and the limitations are at least obvious, and i think everyone generally hates java orms and goes with something like jdbi or jooq? and again jetbrains has another lovely semi-official kotlin library for this but it has the ugliest dsl of all time, lol at least it's all better than go, which was just the ugliest ecosystem of all time. just doing basic poo poo in sql pretty much requires one of several incompatible third party libraries with a single maintainer (sqlx being the most popular from the looks of it) because the built-in sql package is comically annoying to use (much like trying to use jdbc directly or whatever). i really tried to give go a fair shot because i liked the idea of its runtime characteristics (tiny footprint, fast startup) and goroutines, but holy poo poo, just the worst goddamn language to use. the time when i realized that most people use a third party package just to express null values in sql because go just expresses null values as "empty values" (0, empty string, etc) was the thing that made me bail the gently caress out
|
|
#
¿
Mar 2, 2020 03:42
|
|
|
oh neat, we're chatting wsl2, which i just set up i will say i/o wise, like, webpack actually works and seems reasonably fast at watching files. having to use lovely poll i/o is why i returned my surface book within hours of setting it up a couple years ago, was an absolute non-starter for web development, so this is exciting. of course, i'm running a very tiny project on a very beefy gaming desktop, since that's my only windows device, so i don't really know how it works in real-world situations. otoh, i'm annoyed that vscode is more or less the only game in town for an editor you can run in windows but use a wsl dev environment in. i've been thinking of using kotlin as my primary backend language for personal projects going forward, and intellij has no support for remote dev on wsl, and when they add it i'm sure it'll be in their ultimate edition whatever the gently caress paid thing, so that's a bummer. i could run intellij on windows and like... maintain both windows and WSL copies of all my java dependencies, but that sounds fuckin terrible. you can also apparently run intellij via X on WSL but that also sounds fuckin terrible. not really WSL's fault that kotlin is tied into intellij, though, which is what i came to this thread to complain about. y'all am i right in thinking there is no statically typed backend language for web development that is not one of: * objectively bad, like go. i tried writing more go since i figured it was easy to run everywhere but it's still a terrible language. it's just fundamentally unfun to write. i keep getting lured back to it due to the runtime characteristics (tiny! multiplatform! wEb ScAlE!) but bouncing off harder each time. also the vscode tooling is pretty bad, though tbf rust has this problem rn too since everyone wants a language server but no one seems to be putting in the high level of money and time needed for it to work well. i'm also bucketing java into this category though with the caveat that i think it is much better than go, just too verbose for personal projects and the reliance on code generation for any practical application is really gross * relatively hard to write for "normal" web development, like rust. rust actually has some compelling "practical" stuff like diesel, but i would have to spend quite a lot of time to learn it, and i'm not sure the language is actually the right fit for, like, business logic. also the async situation is still really messy on the library support side, though i'm not as negative about it as other people are (lord knows it's taken python a lot longer to figure its poo poo out) * tied into a semi-proprietary IDE or platform. this is kotlin. kotlin pretty much requires intellij and there are no other editors that have real ide-like support. intellij is at least open source at its core, but jetbrains loves to add new features exclusively to their paid IDE, like i think intellij ultimate has "out of the box support" for a bunch of frameworks and stuff that you won't get in the free version. this loving sucks because i think kotlin+jvm rules otherwise once you get over the hump of understanding the ecosystem, and i've been happily rewriting an api from typescript to kotlin over the last couple months * a language that does not actually have types at runtime, like typescript or (i think?) python+mypy. i think of this as a dealbreaker because, in web development, type reflection (whether runtime or compile-time) is incredibly useful for things like "mapping object fields to database columns" and "parsing json into a known shape." without this kind of reflection, you wind up with parallel "runtime and static" types, where you have e.g. a typescript interface and a json schema you have to keep in sync, or you use a hacky, poorly-maintained code generator to get one from the other, or you use a hacky, poorly-maintained library that infers complex static types from a bespoke runtime interface (e.g. io-ts). i honestly think the lack of this in typescript makes it worthless as a backend language and i'm shocked so many people are investing in it when you can't get things like "runtime type correctness for database access" like you can in any language that, like, has a runtime understanding of what is supposed to be in a variable and will yell at you if you set stuff wrong (as awful as go's `interface{}` situation is, at least when you go to convert an unknown pointer to a specific struct it'll holler if you're wrong!) i'm thinking about giving up on types and going back to, like, node with regular ol' js or something. at least vscode gives me autocomplete for imports in that scenario. maybe java with record types and graalvm will be the new hotness in a year or something, since that fixes both the verbosity/ide-generatior-dependence and performance issues. vscode actually is actively working on java support as well (https://devblogs.microsoft.com/java/java-on-visual-studio-code-update-april-2020/) abraham linksys fucked around with this message at 14:02 on May 7, 2020 |
|
#
¿
May 7, 2020 13:52
|
|
|
Finster Dexter posted:I'm of the shaggarpinion that c# is a great web dev language. And I think the .NET web dev community is finally moving away from MVC/MVVM as the end-all/be-all of web dev. (AFAIK, the new hotness is blazor stuff and preferring "endpoints" over "controller actions") blazor gives me big google web toolkit vibes and i haven't seen anyone using it in production yet. if you get over the hump of setup i think doing frontend programming with react or vue or whatever is decent these days, so i'm much more worried about finding a good backend independent of that. maybe someday if someone makes the dream batteries-included full stack framework that lets me, like, avoid defining my form models twice between the frontend and backend like you used to be able to do in 2003, i'd try something replacing a normal frontend stack, but until then i am happy to keep writin js against an api that said, i'm willing to believe the rest of c#/asp.net(??) is pretty good. i read about it a decent amount while learning jvm/kotlin, cuz there is a lot of back and forth between those ecosystems (e.g. lots of newer java db libraries being inspired by dapper). might take a peek i guess, can i just use it with vscode and command line tools? i assume vs for mac is still a weird xamarin thing (e: yes i know i was talking about WSL earlier, just still on mac for now while dipping a toe into windows dev so looking at cross-platform stuff) abraham linksys fucked around with this message at 15:53 on May 7, 2020 |
|
#
¿
May 7, 2020 15:46
|
|
|
Sagacity posted:why not just throw a hundred and fifty bucks (three figgies) at jetbrains to get intellij ultimate and be productive in kotlin? oh i have no problem with intellij CE really. i just have this weird quirky specific problem of wanting to do web dev on windows, using WSL(2), and intellij (even ultimate) doesn't yet support WSL. i am cynical and expect that when they do support WSL it will be tied into the ultimate version, and i'm not going to give them the money for that for personal projects, but idk maybe by that point there will be an open source alternative since it seems they're generally chill with that (and they did already start work on some kind of base WSL communication extension that other extensions can use so that's an okay sign) the other option, of course, is to not use WSL, and run my backend on windows in development. i don't love this because i'm not very familiar with windows and its way of doing things. i use docker in development to run services the backend relies on (postgres, redis), so if i could easily get those running in docker for windows, and get my java dev environment working correctly on windows, maybe it would be fine? but then i don't love running on windows in dev and deploying to linux in prod i could also try running intellij through X on WSL which apparently people do and have some success with but it sounds kind of annoying (love to install cygwin in 2020)
|
|
#
¿
May 7, 2020 18:23
|
|
|
Boiled Water posted:having been dunked severely in the dynamic pool of clojure doing backend stuff I can safely say that types are overrated i've been thinking about this for a bit and i don't really disagree i still think a lot of frameworks and libraries are surprisingly bad at the input/output portion, especially in node: * if you use a sql query builder like knex, you don't have any concrete "model" object with a definition, just a thing translating the returned table to a map, and you're at the mercy of hoping you are using the return value of a complex query correctly. this is actually still true in most static typed languages, since most* sql access in them still generally relies on something like "stringy query goes in, unknown result comes out, cast this result to a struct or object or whatever" and you get a runtime error if you gently caress up. that said, without validation in a dynamic language (or in a no-types-at-runtime-language like typescript), you don't get a runtime error immediately, you just get a surprise `undefined is not a function` or whatever down the road, which can be way worse * yes i know of things like jooq and diesel that try to avoid this but they're still fairly uncommon compared to either arbitrary string-builders or ORMs that generate queries from models * if you use a dumb framework like express, and you want to access a query param, you just access whatever on `req.query["paramName"]`. it's totally up to you to parse it and validate it and turn it into a 400, and it doesn't come with something to do this, unlike an actual useful framework. this means a bunch of apps wind up with issues where they just straight up forget to validate it, and everyone has to roll their own validation or bring some other bad library to do it. i know `if (isNaN(parseInt(queryParam)) { return response.status(400); }` isn't the most code to write but it's goofy as hell this is a thing you have to do in the most used web framework on node, the one every fuckin demo is written in so the problem isn't just static typing it's like... types at runtime. the thing is, you get runtime types for "free" in most static typed languages, except something like typescript or mypy. when i am using javalin, a small kotlin framework that's pretty directly inspired by express, it still offers a basic `getParameter()` function that will cast to a given type and 400 out if it fails, because you just expect that poo poo in a framework built for a staticly typed language. in conclusion maybe i should just start writing rails apps again instead of trying all this other poo poo
|
|
#
¿
May 7, 2020 22:23
|
|
|
realized that by trying to build a stateful websocket server in a non-single-threaded language runtime for the first time i have opened myself up to an entire loving class of concurrency problems  go's channels are super hard to reason about on this front, particularly. they really recommend you avoid atomic values or mutexes, and you're supposed to use channels instead, as described here. but that just seems like a terribly difficult pattern to use at scale in practice. i guess a big part is just careful reasoning about what's truly shared - like, my app has a thing where users update their own state with websocket messages, but no other users can update that state. if a user is tied to a websocket connection (and there's a 1:1 user:socket relationship), and i've properly implemented the weird queue pump system this websocket library recommends to limit processing messages to one at a time per connection, i can theoretically assume that only one thing is touching that state at a time. which, like, is a lot to fuckin have to think about, versus the world i'm used to of "this poo poo's single threaded so as long as you never yield to the run loop through callbacks/yield/await you'll be fine to increment that counter or whatever" i guess i could just start doing all my state management in some kind of database to serve as a "lock"? i guess that's not that weird, like, that's how you can handle multihreaded connections in regular ol' "stateless" http apps, your state lives in a database that is smart enough to handle a bunch of concurrent access. theoretically if i cared about scaling this app horizontally i'd want state in a db and some kind of pubsub broker anyways, maybe i'll just shove everything into redis
|
|
#
¿
May 8, 2020 06:17
|
|
|
lmao as of 2017 go actually added a concurrency safe map to their standard library (https://medium.com/@deckarep/the-new-kid-in-town-gos-sync-map-de24a6bf7c2c) it is, of course, a `map[interface{}]interface{}`, meaning both keys and values are untyped, because go does not have generics
|
|
#
¿
May 8, 2020 06:42
|
|
|
DrPossum posted:Your mileage will vary, but I basically do this with kotlin and docker in Windows 10 with Intellij ultimate. I transitioned that project from linux a few months back and other than some gradle fuckery and changing accomodating docker's general Windows/Linux differences it with was surprisingly painless. Just make sure you have Windows 10 pro because home doesn't support the virtualization needed for docker. good news/bad news on this one: * good news: docker is moving to using wsl 2 as a host. unlike regular hyper-v, wsl 2 actually works on windows 10 home, which is pretty unexpectedly cool of ms * bad news: intellij is still behind the curve on properly supporting wsl2, though, even compared to other jetbrains IDEs (https://youtrack.jetbrains.com/issue/IDEA-223986). that said, i guess if my source lives in windows, and is just mounted into docker-on-wsl, it should be okay, the same as what you have now? i'm curious to know more about your setup! does intellij have built-in stuff for running inside docker you're using (debugging/running tests/etc)? i think i understand how you'd normally use docker for development on the command line (have a build folder with the app that's mounted into the docker fs, set up a dockerfile that just runs the app, restart docker any time you rebuild the app), but i don't really know how it'd work with intellij, especially the testing side of things. if intellij is running gradle etc. in windows, you have to maintain your dependencies on windows and "just" mount the build output into docker, right? that seems kind of reasonable for java, since theoretically the jvm should be able to handle stuff built on one os and running on another, much better than, like, how you can't just copy-paste a `node_modules/` folder from one os to another if it has any native c dependencies since they need to be rebuilt i think if i was living in a world where i was doing most of the work through an IDE, i actually wouldn't really give a poo poo whether it was running on windows or linux, tbh. for node/frontend dev i am in the command line most of the time and it'd be kind of weird, though. also i'd have to rewrite all my shell scripts, i guess? development "on windows" is so much more mysterious to me than this WSL stuff, but i'm not sure i actually have any technical blockers from preventing me from doing development on windows, other than just learning new poo poo
|
|
#
¿
May 8, 2020 17:35
|
|
|
tak posted:go is fine, and interface{} isn't that scary if you only use it when you actually need to on one hand, i kind of disagree with this because type safety is the entire reason i've left the comfort of my p-lang shell and started trying all these other languages, so while i don't necessarily need haskell levels of type magic, i do want to not have to cast in and out of unknown on a regular basis. that said, in practice, i see your point. like, basically every web framework i've seen in a static-typed language has middleware functions you can run that can store or read values on an "http request context." this way you can have a middleware function that goes like "if this user has an auth token, find their user from the DB and store it on the request context, so my route handlers can quickly grab the user from the context." in practice, the context is inevitably some kind of `map[string]interface{}` where you can store whatever the hell you want and just have to type cast on either side i do like that in static type languages you can, y'know, type cast, instead of in JS either relying on nominal typing with instanceof (which is rarely useful because everyone just uses anonymous objects instead of classes), or writing duck-type runtime asserts for every single `unknown` value you have, which is a ton of boilerplate (and, in typescript, doubled boilerplate since you end up having to maintain that along with your static `interface`) quote:if you're using vscode for go use the nightly go plugin. there's a great official go language server that's been in the works for a while (gopls) included, which you can also use in any editor that supports the lang server protocol too i'm using this and it's... not the worst editor experience i've had, but man, it's not great. i tried it like ~6 months ago and it was a loving wreck, so i can say now it's relatively usable, but it still cannot pick up new or moved files without me restarting the language server. i think everyone is having trouble getting a language server working well (i believe rust's is still similarly unstable) so i'm pretty sympathetic to it, but it's weird that a language that's been around a decade has such an immature tooling situation - like, i know language servers are new and there was an ecosystem of CLI tooling, but now all of that's been abandoned or deprecated and not updated to support the new go modules stuff, so as far as i can tell i'm stuck with this language server. or, uh, goland. Soricidus posted:you can even compile it into a single self contained binary these days with graalvm. or run it straight from the source code like a plang if you’re allergic to compilers. java good i wanna try this at some point, but graalvm requires a lot of manual configuration if you're using libraries that involve any kind of reflection, which in the web dev world, is "most of them." that said most frameworks at least have tutorials for getting started with graalvm and i know some are specifically built for it (quarkus, micronaut), i just gotta figure out if i'll wind up wanting some dependency that doesn't work in a native context. i've been using jib to produce super-lightweight docker images for deployment, which hasn't required much effort at all. my small javalin app hovers around 170 megs of memory which fits comfortably onto the cheapest digitalocean box you can get, along with postgres/redis/a node frontend server. i'm sure this is like 10x the footprint of a go server with the same functionality, but i feel like also took me 1/10 of the effort to write, so shrug
|
|
#
¿
May 8, 2020 17:52
|
|
|
Notorious b.s.d. posted:c# would be a good language if it weren't for that whole "microsoft" thing yeah i think it's been weird that while reading a little bit about c#/asp.net i just have not seen anything other than like "we just use what microsoft offers," with the exception of folks using dapper instead of entity framework i mean kotlin sorta has this problem in terms of "kotlin-first" ecosystem being primarily just jetbrains developers experimenting with half baked ideas (ktor, exposed) but you have, yknow, the whole fuckin jvm ecosystem to lean on there with pretty much any popular framework or library having some kind of compatibility layer if necessary i noticed that in the asp.net docs they talk about a few open source projects that seem to be de facto standards in the community, like IdentityServer4 being used for auth (efb by Eldred here) Nomnom Cookie posted:the only languages worth using in 2020 are java, rust, and python feel like once java records land in whatever the next java LTS version is i might give it a shot? until then kotlin seems like the way to go
|
|
#
¿
May 8, 2020 18:54
|
|
|
jesus WEP posted:I’ve heard okay things about avalonia for .net core CRIP EATIN BREAD posted:kotlin multiplatform is good honestly, for as much of a loving joke as dart has been for the last decade, flutter seems to be getting some legitimate adoption outside of google. i think right now if i wanted to make a native ios/android app that would be my first stop react native still seems okay if you can somehow figure out how to share components and logic with a react web app. in practice i have literally never met anyone who has successfully done this for anything but, like, a small module with some helper methods, or a couple components that use react-native-web that all the frontend developers hate. i'm not sure it's worth buying into the react ecosystem otherwise, unless you already know react or want to get some of your frontend team to work on it. at my company which is primarily a native app, we have a react native app because it was the only real shared-code game in town when we decided to combine code, and the apps are still like 50/50 native/react, and we have a split between specialized native devs and frontend devs who have started doing native development i've built a server-side rendered vue web app, so i've occasionally thought of looking into nativescript w/ vue to build a native app to go with it, but i don't think it has much adoption at all and i'm skeptical i could actually share enough components to matter. it probably would end up being either a wrapped web app with enough of a native facade that apple wouldn't reject it (no idea what their standards are on this atm other than that they get mad if you serve "most" of your app over the web instead of shipping code in the app bundle), or a flutter app. hell maybe now is the time once i get through this stupid go websocket thing, not like i'm doin much else carry on then posted:i know 0 go but what does nothing, which is the point, those are equivalent things however, map is a language construct, and not one defined in userspace like a java HashMap is. you cannot write your own type-safe HashMap implementation in go, because while maps are "generic" in that they can hold a given type as keys or values, you cannot make your data structures that are. which is why go does not have a type-safe equivalent to, say, ConcurrentHashMap - they implemented the stdlib `sync.Map` data structure as a go data structure instead of doing whatever they did to create the language `map` construct, and thus, it is fully untyped. abraham linksys fucked around with this message at 23:27 on May 8, 2020 |
|
#
¿
May 8, 2020 23:24
|
|
|
Nomnom Cookie posted:i'd rather punch myself in the balls pretty hard than try to do websockets in go really the things that are most important to me about this websockets project (concurrency, building a little json protocol, small http api running alongside so i don't have to do rpc-over-websockets which is the fuckin worst) aren't that bad in go like... if i did this in kotlin (or java), i'm not sure what i'd do differently. probably would use javalin's small websocket wrapper which gives you regular ol `onConnection/onMessage/onClose` callbacks instead of go's weird goroutine/for-select/channel poo poo, but i'd still have the same problem of stuff being multithreaded by default and that would require some concurrency work if i did this in python with asyncio, it would be single-threaded making any in-memory state trivial to work with by comparison. so there is that, maybe i should just revisit python for the first time in a minute. honestly i'd probably just use node if i was going a dynamic-typed route though just b/c it's what i'm most familiar with.
|
|
#
¿
May 8, 2020 23:42
|
|
|
Space Whale posted:Also wondering about other languages. I'm pretty open, just want something that will lead to, yanno good environments. honestly a somewhat lateral move into java would probably give you a lot of backend dev opportunities at a lot of, like, mature startups/web/app companies if that's the sort of environment you're looking for? i think it's pretty common at "hip" places these days as they mature and give up their python monoliths and such. lotta folks writing rewriting their big ol' p-lang mess into services in java (not necessarily even microservices, mind you, just "hey maybe checkout should live in a nice java service that has types and api documentation instead of being split arbitrarily across twenty files across our giant rails codebase"). that's where my company is at and where my friends' companies seem to be headed, and because a lot of folks are coming from the experiences of moving "rapidly" with rails/django/flask/laravel/node/whatever, they gravitate towards "fresher" stacks when it comes to java instead of just falling back on spring and hibernate or whatever (thus why we use kotlin, for example) go might be an option but i really have no sense of what go looks like in production and who's using it and where. it keeps coming up in like bullshit "languages developers want to learn!!" surveys but i have no idea where it tracks in terms of what companies are hiring for abraham linksys fucked around with this message at 03:27 on May 9, 2020 |
|
#
¿
May 9, 2020 03:24
|
|
|
Phobeste posted:wait does this mean you have to check that ok variable every single god damned time you take a value out of the map or be subject to surprising downstream errors if the key didn’t have a value oh boy i get to tell you about what actually might be even worse than a lack of generics: go uses zero values instead of having a concept of a nil value. so let's say you got this: code:no, what you will see is: quote:true this is because you get an empty Butt if it's not present in the map, which is the zero value of a struct. an empty struct will have a zero value for didFart, which is false, because it's a bool. this also applies for strings (""), ints (0), and floats (0.0). now, you can represent the concept of nil in Go, but you have to use a pointer: code:now, you could make the argument of "well, who needs a nullable boolean anyways?" but you know what structs get encoded and decoded to? database fields. json fields. things that are nullable. which is why the sql package has to ship nullable types as separate structures. which, by default, you have to manually convert yourself for json encoding/decoding. which is why there is a whole package you can install for nullable values that you can use in json decoding and encoding. also go did not have a native sql.NullTime until 1.13, which is like a year ago. and to actually answer your original question, they do at least tell you in a map whether or not it found a value, so you don't have to try to guess whether you purposefully stored a zero value or if a key is missing. that's why you check the second argument: code:abraham linksys fucked around with this message at 04:40 on May 9, 2020 |
|
#
¿
May 9, 2020 03:55
|
|
|
it kind of rules how golang's zero values and error returns are like you tried to explain the concepts of null safety and option types to someone and they just completely loving missed the point as hard as they possibly could
|
|
#
¿
May 9, 2020 03:58
|
|
|
i started rebuilding my lil app in kotlin and it's going okay, though running it on windows still going to be interesting. at this point i think i'd be fine living in windows for development (esp cuz docker works w WSL2 so dependencies like postgres can be managed through that instead of having to janitor them on windows, which seems much more annoying). the only problem with this is that this project also has a webpack-built frontend, and running that on windows instead of WSL2 seems bad given what i know about the node ecosystem and windows. i'd even be okay splitting the frontend and backend across os's (given they're independent of each other) except they're in a monorepo that i'd have to two copies of (one on the windows FS and one in the WSL2 FS) i did get intellij up and running in X under WSL2 and it actually was super easy so i might just go with that for a bit. i think the only problem i'm going to run into is when it inevitably, like, tries to open a link to some docs site in konquerer or whatever the gently caress instead of my windows browser e: oh you can totally just launch windows firefox.exe within WSL2 this poo poo whips. the x window server i'm using supports multiwindow mode so you cannot even tell this intellij is running under linux except for the hosed up font rendering (but it's a java app anyways so) abraham linksys fucked around with this message at 22:24 on May 9, 2020 |
|
#
¿
May 9, 2020 22:11
|
|
|
Nomnom Cookie posted:me: please let’s have a defined interface somewhere i'd love to use json schema if every single generator for it didn't appear to be an unmaintained trainwreck thinking about that now in fact b/c i am writing message types in both kotlin for the server (using data classes + jackson) and typescript for the client (using io-ts), and i would like to have a single source of truth instead  protobufs are kinda promising but i'm not sure what the state of using them in kotlin is yet, a grpc-kotlin package just got released but i'm not using actual grpc so i think i'd be stuck with the java protobuf lib and i'm not sure how awkward that is from kotlin fwiw i will slightly defend(?) express by noting that it sucks rear end and doesn't really do much because every single early node package maintainer was infected with small module brainworms. no one wants their hello world to have 20 different dependencies so they all just use express and don't have poo poo like that. there's some projects like nestjs or hapi or fastify that make validation part of the core, though only nest lets you easily use typescript for static types abraham linksys fucked around with this message at 18:45 on May 10, 2020 |
|
#
¿
May 10, 2020 18:43
|
|
|
Achmed Jones posted:a little curious: do you or other engineers work on web services (like, REST APIs or whatever) within that monorepo? i continue to want to hear more stories about people using go for web stuff, because that has somehow, according to various surveys, become the biggest usage group, but also it seems like a loving awful language for it in so many ways like i still want to know what everyone uses for sql in practice. do they use one of the bad orms? one of the bad query builders? do they seriously use database/sql and loving scan every row result in manually? it baffles the mind
|
|
#
¿
May 16, 2020 07:06
|
|
|
Soricidus posted:fibers this is like my least favorite thing about leaving the safe single-threaded confines of js async/await on a single-threaded event loop meant it was extremely easy to reason about concurrency because you knew, if you were in a sync function accessing some poo poo, that within that function it was absolutely impossible for it to change out from under you. the await breakpoints then told you "on the other side of this, something might have changed." it was nice! sure you had "colored functions" or whatever that stupid blog post is about, but in practice js has been async by default for i/o for years, it's other languages who are having trouble catching up (see: kotlin coroutines are kinda pointless because none of the jvm db libraries and only a handful of http servers/clients support them) now everyone suddenly wants this green thread stuff which i thought were thoroughly argued against here in a compelling way. when you have threads (green or non-green), you suddenly find yourself having to do poo poo like create awkward-to-use queues to prevent unwanted concurrency, and i hate this! threads are totally fine for cpu-intensive poo poo, but in your normal i/o-bound web context just give me one drat thread and an event loop with async/await or yield or whatever i don't really know where .NET async/await lands with all this? i assume given it's a non-plang you have all sorts of threading options, but i'm unclear if, for example, asp.net gets a (pooled) thread per request or if it single-threads everything synchronous i still haven't managed to figure out erlang, i dunno, maybe it'd make me see the light on this poo poo, but i'm skeptical. i assume they have like... patterns for abstracting over state so you never actually want shared state and thus it doesn't matter, or something
|
|
#
¿
May 20, 2020 02:15
|
|
|
leper khan posted:Just hold the state in its own thread. Then communicate between threads by dropping messages in thread safe queues. Easy. yeah i should probably be better at figuring out how to structure things like this i built a lil websocket chat server in kotlin and just threw a bunch of ConcurrentHashMaps at it and hoped for the best, i dunno. like, i use them to store "which rooms exist, and which users are in that room," which has to be saved somewhere. i dunno how you make something like that into thread-local state in javascript, i would be able to hold state like that in a singleton or whatever and never have to worry about it being concurrently accessed
|
|
#
¿
May 20, 2020 02:24
|
|
|
redleader posted:the js concurrency model is unironically the best thing in the language. if js had been created with a more traditional concurrency model (all threads all the time, molest shared and ui state as you will) then i'd probably have taken a long walk off a short pier by now y'know, i suppose this is a big difference, the model makes way more sense in a client side environment where you're mutating ui state than in a backend where your mutable state is likely going to be in some kind of database this is also true of anything with a "ui thread" i guess; don't most ios apps just use a single thread by default except for background services (i know i've seen a lot of articles like "how to move your slow poo poo off the ui thread" which makes me think it's all there by default atl east)
|
|
#
¿
May 20, 2020 07:14
|
|
|
vim's a lot easier once you just give up on learning the more advanced motions and just start using visual mode for everything complicated ime i do need to get better at using the surround motions though that's like the one thing i just straight up forgot how to do and i know is super useful
|
|
#
¿
May 20, 2020 16:13
|
|
|
a past boss once did git push -f before they changed the default to only push the current branch instead of all and we sure did have fun asking the last person to merge if they could push their local master again since it was the only one with the merge commit
|
|
#
¿
May 21, 2020 01:44
|
|
|
Xarn posted:
i had never heard of force-with-lease until, uh, yesterday love that famously learnable ux of git
|
|
#
¿
May 21, 2020 16:58
|
|
|
can you run through your build manually or somethin? or just do a rollback to an older version everyone at work likes to merge a revert PR and deploy that when something breaks, but that process takes like 45 minutes between building and testing the revert branch, merging, and building and testing master, and i always get annoyed when we have a critical bug and no one just thinks to deploy an older built docker image from a past deploy and prod is just broken for 45 minutes for no reason ofc this is in a frontend context where you don't have to worry about doing schema migrations down or whatever which is more complicated
|
|
#
¿
May 27, 2020 22:37
|
|
|
there are aspects of hooks I find compelling from an API front but when you break down the "how we got here" part it is just incredibly grim i do appreciate that dan abramov is pretty honest about like "yeah i didn't think anyone would really use redux for this long i thought someone would build something that sucks less by now." i think if he hadn't moved onto react core we would have gotten something more like redux-toolkit sooner which helps a lot we use redux+sagas in our codebase and it's the largest app i've ever worked on and i absolutely hate it; our patterns are awful and i keep trying to present a refactor proposal but get stymied by just how difficult it is to fix (also i hope dan figures out his visa situation so he can quit facebook cuz he's a very smart dude who i have to imagine does not really want to be working on react anymore)
|
|
#
¿
Jun 21, 2020 01:22
|
|
|
Sapozhnik posted:The new and stabilized React context mechanism is a fine and dandy way for deep passing of shared state without all the mess associated with Redux. You either use the provider/consumer component pairs that React spits out, or even better, just use the provider component and declare right there in your class which one piece of ambient context a given class consumes (which is going to be something slightly narrower in scope than "literally the entire universe") with a static contextType. If your component needs to simultaneously consume two bits of ambient context then you very probably have a bad design on your hands. this is about where i've landed; I use context or occasionally something like a form library that wraps context if I'm lazy. my last app, greenfield and small in scale, was "vanilla" React + Formik for forms (which I think is now all-in on hooks and I'm not sure how it is these days) and it was really nice since I had a very shallow app and rarely needed to worry about passing data down into very-nested stuff also I now use Vue for personal projects lol; Vue 3's composition API seems to be like hooks with an easier-to-reason-about form of magic (reactive proxies) and I'm looking forward to it making it easier to use TypeScript with Vue
|
|
#
¿
Jun 21, 2020 01:25
|
|
|
Shinku ABOOKEN posted:IIRC Redux was cargo culting whatever elm was doing. elm is a functional language and works very well with that pattern (even when you have nested things and components written by other people etc...). however javascript is javascript, and therefore you get what you get. the thing that bums me out most about redux is it failed to include the "commands" aspect of the Elm architecture, which in Redux terms is "what if reducers could dispatch further actions as part of their return value?" it means you can avoid the thick action creator layer almost all Redux apps have (see: sagas, etc) there were a couple stabs at doing this (redux-cycle being the biggest I think) but I don't think they got much adoption
|
|
#
¿
Jun 21, 2020 01:28
|
|
|
i think everyone wants SSR in some flavor at this point, but there's a big split between "we've got a very complicated universal app that returns HTML to the client on first render and does client-side rendering and routing after that" versus "we've got a traditional server-rendered app that talks to the database and returns HTML templates" we have the former for our marketing site and it's a loving appalling over-architected nightmare, and the client-side rendering performs far worse than if we just did a full page navigation instead. I'd like to find a way to pull it out of universal React hell, but the problem is, I definitely can't be like "okay, let's build a Rails app!" ideally we'd have something in between that is pulling together the right data for each page (in a backend-for-frontend-like manner) from our services and rendering HTML i'm not sure anyone's really pulled pjax/"html over the wire" stuff into a nice out of the box framework yet. basecamp is like the only company that seems to be championing this stuff, and I'm pretty sure they still build on Rails/Turbolinks/Stimulus? there's some irony here in that, like, the last few times I've used Rails, it's been acting purely as an API (which usually means you don't get to use half the most useful features of Rails, like libraries that generate auth scaffolding or all the forms stuff, making Rails pretty fuckin pointless tbh), but I think what I'd actually want would be the opposite - Rails as a rendering layer consuming my actual backend API. of course I'm not sure Rails is even a great option for that considering its lack of async I/O, and you'd be missing out on all of the other nice Rails integrations where it binds to your models and whatever, and that's... why when people want that "rendering layer," they go for something like Next.js and drag all the complexity of the React ecosystem in instead, even if you really don't need the client-side aspect at all
|
|
#
¿
Jul 18, 2020 12:50
|
|
|
as a primarily-frontend dev i get kinda confused by all the serialization talk just b/c it seems like browser json is still faster in any benchmark i've been messin around with multiplayer websocket games lately so i'm theoretically in the market for fast (de)serialization and smaller message sizes but as far as i can tell from googling, json is still the way to go. signalr supports messagepack but provides zero actual benchmark tools indicating anything about performance, which you'd really kinda hope for if they've bothered to add the option
|
|
#
¿
Jul 29, 2020 17:58
|
|
|
love to use kotlin coroutines with the wide array of libraries that support them, such as, uhhhhhhhhhhhhhhhhhhhhhh (i guess there's got to at least be android stuff that uses them right??)
|
|
#
¿
Aug 7, 2020 15:13
|
|
|
CRIP EATIN BREAD posted:its literally as easy as hm... appears that i've been owned CRIP EATIN BREAD posted:it's exactly how the entire spring ecosystem does all their reactive stuff on both plain java and kotlin, but adding all sorts of kotlin extensions like a reactive DSL for rest endpoints etc is there a quick docs page you can point me to on what that kotlin reactive DSL looks like? i'm using a small framework called javalin since i got scared away from spring boot by the spring docs (which are extremely the kind of docs that assume you already are familiar with this ecosystem and are just trying to learn some specific new thing in it, instead of having any good overview of "what the gently caress is spring, and spring boot, and webflux, and here's the kotlin extensions for all of these things")
|
|
#
¿
Aug 7, 2020 17:17
|
|
|
bob dobbs is dead posted:the basic and not really fixable problem is that npm is a for profit vc backed company and they expect their main revenue source to be npm. which is fuckin stupid. you must have missed that this problem was solved https://thenewstack.io/github-acquires-npm-buying-microsoft-a-presence-in-the-node-javascript-community/
|
|
#
¿
Aug 16, 2020 04:57
|
|
|
the only js framework i know of that has embraced DI as a concept was angular and, well, that didn't go super well on a number of fronts with react/redux a lot of the time the patterns actually lend themselves pretty well to not needing mocking since there's usually some layer of indirection you can test instead (testing that an action is dispatched instead of mocking out a method on an object). a lot of times stuff that would be provided by a DI container can live in some top level component and get accessed through context, for things like api clients and whatnot, which... i dunno that's basically DI, if you're coming from the perspective of "DI is basically just passing dependencies as arguments to things"
|
|
#
¿
Sep 11, 2020 00:51
|
|
|
piratepilates posted:redux is one of the react cases where it got super hyped up for some reason, and everyone thought it should be used everywhere always at all times for everything. to be fair, local state and async behavior was difficult to unit test in react for a really long time. was hard to write a test like "click this button that will trigger a mocked async api call and check to make sure it updates to show a success state" or something, compared to testing "this async action creator will dispatch a success action, this reducer will set the didSucceed flag in redux state, this mapStateToProps() will pass didSucceed from the store to the wrapped component, and this component will show a success state when passed didSucceed=true." newer, better test libraries and hooks might have fixed this to an extent? i just remember pre-redux react having to do a lotta setTimeout(fn, 0) hackery to get my tests to run in order with async behavior (i don't write unit tests for personal projects, and at work we're still using class components + a nightmarish redux-saga layer, so i don't know specifics of testing with hooks and the like) abraham linksys fucked around with this message at 17:05 on Sep 11, 2020 |
|
#
¿
Sep 11, 2020 17:00
|
|
|
|
| # ¿ Mar 20, 2023 09:54 |
|
|
DaTroof posted:i only started using it recently, but so far enzyme has been v needs suiting we're moving off enzyme to react-testing-library soon, probably, though i couldn't really tell you exactly why i did a couple minutes of googling and found this article that describes the problem with async testing that i've faced in the past, but also indicates that react-testing-library has a waitFor() util that solves this problem, neat: https://www.benmvp.com/blog/asynchronous-testing-with-enzyme-react-jest/
|
|
#
¿
Sep 11, 2020 17:07
|
|