Carthag Tuek posted:

couldn't you make an "empty" nginx step that only has those deps & use that as the dep for further steps

would limit the need to update stuff to one place

Soricidus posted:

given the popularity of the packer ansible provisioner I’m not sure it exactly saves us from anything

Nomnom Cookie posted:

the io performance on wsl2 is real inconsistent and disappointing after all the press. yeah, git is faster. that seems to be the only thing they did any perf work on. apt is slow as frozen balls

Notorious b.s.d. posted:

well, two things

1. the windows i/o layer is irreparably broken. anything that touches the windows i/o layer, ever, will be horrendously slow.
   
   so the advantage to a virtualized kernel is that filesystem operations can pass through a block cache before talking to the windows i/o layer, reducing the total number of operations. makes git faster. doesn't help apt much.
   
   
2. apt is already slow as balls for reasons unrelated to i/o, so having bad i/o and how loving awful libapt is in combination sucks worse
   

abraham linksys posted:

y'all am i right in thinking there is no statically typed backend language for web development that is not one of:

abraham linksys posted:

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 posted:

y'all am i right in thinking there is no statically typed backend language for web development that is not one of:

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")

abraham linksys posted:

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 posted:

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

Corla Plankun posted:

c# does seem to meet all your rquirements but since the backend system is just going to be pooting out json anyway it seems pointless to care about type safety in webdev

abraham linksys posted:

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)

Sagacity posted:

why not just throw a hundred and fifty bucks (three figgies) at jetbrains to get intellij ultimate and be productive in kotlin?

alternatively, use the community edition, write something cool and open source it. boom, free open source license for intellij ultimate courtesy of our eastern bloc friends

mystes posted:

I never used google web toolkit, but I think that was a lot heavier? Blazor normally feels more like just react but with c# transpiled to javascript (or run in the server). The main problem with blazor is that you can't really use blazor server for production and the webassembly version isn't stable yet either, so there's basically no way to use blazor in production right now.

I think Microsoft must of decided that webassembly was the future of transpilation and decided to go right to that rather than javascript, and I guess only time will tell whether that was a smart move, but it's sort of unfortunate in that it means that blazor isn't really usable at the moment.

Normal asp.net is perfectly good now, though. Despite the name it just uses c# not the old asp language.

abraham linksys posted:

prisoner of waffles posted:

idk holmes, sounds like you should consider c# for the whole dotnet core experience

how does the thread feel about frontend poo poo? apropos of nothing, I think I'm extremely horny for the absolute minimum amount of javascript on the front end. like if you need something complex and interactive go hog wild but don't make react a dependency to just build what could have been a static page

is it glaringly apparent from these opinions that i do not do webshit for work? lol

carry on then posted:

i'm all for this for projects of a small/reasonably static scope (or at least just pulling in whatever js libs I need manually instead of adding a build step that doesn't need to be there) but lmao if anyone will ever reasonably scope something small instead of set out to change the world with every wepage

Boiled Water posted:

having been dunked severely in the dynamic pool of clojure doing backend stuff I can safely say that types are overrated

sure sanitize you’re input and output and the edge of your program but in the middle why bother?

Boiled Water posted:

having been dunked severely in the dynamic pool of clojure doing backend stuff I can safely say that types are overrated

sure sanitize you’re input and output and the edge of your program but in the middle why bother?

prisoner of waffles posted:

idk holmes, sounds like you should consider c# for the whole dotnet core experience

how does the thread feel about frontend poo poo? apropos of nothing, I think I'm extremely horny for the absolute minimum amount of javascript on the front end. like if you need something complex and interactive go hog wild but don't make react a dependency to just build what could have been a static page

is it glaringly apparent from these opinions that i do not do webshit for work? lol

DELETE CASCADE posted:

it's actually the opposite of this. at the edges of your program, there are no types, it's just strings coming in and strings going out. ie the "universal interface" of unix pipelines. only inside your program do the types matter. you use them to express constraints in your program, like "this input is sanitized now" or "we are in this state" or "this data structure i am using has the following interface" and so on. you bother to do this because it takes away a lot of cognitive load while programming, since the type system is propagating constraints around for you. if it isn't removing cognitive load for you, then either the type system you are using sucks, or you are using it wrong

Sapozhnik posted:

love to build user interfaces using a document layout system for scientific articles

abigserve posted:

I put off learning react for years and then I finally did it and it's actually far, far simpler than static pages and the end result is cleaner imo - your presentation layer is completely decoupled from your backend outside of maybe convenience functions.

If you're writing a quick webapp it's both faster to get something working and looking nice with react than it is pure html/css

Sapozhnik posted:

Ehh, yeah, just as long as you don't use Redux. Then there's the new Hooks crap which is basically hidden global variable hell with all the non-testability that entails, plus an extra side of quasi-linguistic rules that must be obeyed otherwise the whole thing has the potential to break extremely strangely. Yes, there are unit test helpers and linters and stuff for it but it's still some really weird janky brittle poo poo that ultimately seems to exist to paper over the Context consumer mechanism in a way that solves one problem by introducing four new ones.

I dunno, React is thrashing around in some strange directions lately.