advanced web development

all cutting edge web technologies discussed here not allowed: PHP, Java, C#, Rails encouraged: backend in: Go, Elixir, Clojure frontend frameworks like: Angular, React, etc templating and transpiling languages like: Coffeescript, Clojurescript, Elm, Typescript

>>51 I have experienced a tiny bit with golang webservers, it's fun to work with and quite fast, even when proxied through nginx >angular and react javasoykaf is a cancer on the web and should be avoided as much as possible. Tiny content-enhancing features are okay, but only if they don't break the site when disabled.

But I can't live without PHP.

>>85 then start your own thread on conventional web development

What makes development in any of the languages "advanced"? Why exclude anything other than PHP if you want to exclude copy&paste wannabe webdevs?

>>51 >web dev on λ That's a bold choice. Anyway, I'm curious if languages like CoffeeScript and TypeScriptwill start dwindling down as ES6 gets picked up by more developers. Personally I'm learning React and potentially React-Native

>>91 1. They weren't saying PHP is advanced, they were asking why some languages would be inherently more advanced than others. 2. You shouldn't think you're being baited and resort to name-calling at the first sign of someone questioning your point of view. 3. I don't know for sure, but judging from how this board was moderated in the pre-wipe era, I have a feeling any further threads on web development would get locked, so telling someone to make their own thread is not very useful.

>>93 I think that ES6 is held back to much by backwards compatibility to compete with Coffeescript. There is too much explicit use of variables in loops instead of using mapping functions the way a language like Ruby does over all container objects. The syntax in Coffeescript is god-tier, it takes all the best syntax features from JS, Ruby and Python. Coffeescript uses Python like for loops like this for x in arr but can turn them into comprehensions like this x + 1 for x in arr when x > 2. The problem with Coffeescript of course is that it is transpiled to js so will never be a standalone programming language. A language like Julia takes all the good syntax ideas from Coffeescript and does make an outstanding standalone scripting language. In fact I predict that Julia is going to start showing up more as a backend web language as it has speed and multithreading ability comparable to Go.

>>97 ok, youre right, I misread the remark about PHP. So to answer your question, advanced backend programming languages are languages that have improved speed and systems level programming provided by a language like Go. I was tempted to disallow discussion of node.js sinceNode.js gets its speed by simply being a wrapper over a C++ API and also it fakes concurrency with callbacks which I think most will agree is a complicated way to program backends. But node.js is the defacto dependency manager for just about anything having to do with js so I cant really leave it out of the discussion. Other languages that would be advanced are languages that support large scale concurrency like Erlang/Elixir and languages that support metaprogramming like Clojure, Elixir, Julia. On the frontend I think we can all agree that things like frontend frameworks and template languages are advanced. html and css were designed as static markup languages and these frameworks give dynamic response ability to html and css. This is even better than if they were to redesign html and css because I dont think anyone could agree on the best way to make html and css programmable. By using js to manipulate html and css you leave open a lot of different design options. And then you have template languages like HAML and SASS which makes html and css directly programmable. I really think that javascript is limited to how far it can be improved, I commented on that above >>99 I think that javascript looping mechanisms are too explicity and dont allow enough mapping and itteration built in the way it is in Ruby and it can never be added without breaking backwards compatibility with old js code. I wont be surprised if browsers start adding native support to Coffeescript, Dart and Typescript as all three of these languages have something to offer.

>>93 >Anyway, I'm curious if languages like CoffeeScript and TypeScriptwill start dwindling down as ES6 gets picked up by more developers. I will probably stay with CS, mainly because I use it because of its syntax, not in spite of it. It's good ES6 has partially reached feature parity though.

>>51 Anybody Vuejs here? In my opinion it's much better than react for real-time applications. I still hate front-end work, but Vue makes it a little less painful.

Opinions on Python/Django or flasl for the back end? And why is GO encouraged?

Programming discussions always have to be created with such a care not to hurt anyone's ego. I don't think i've ever seen a programming thread without people feeling personally offended over technical details. It's quite depressive. <x> is just a language/framework/library, if you think it's soykaf, provide arguments and then people can talk about these arguments, if you think it's the best language/library/framework, then provide arguments too. Talking about a craft as if it was a religion is pointless, it only makes you look like you don't know what you're talking about.

>>185 >Opinions on Python/Django or flasl for the back end? Django is a Rails clone, Flask is a Sinatra clone. Dont get me wrong, Rails is a brilliant idea for a framework, but it has gone as far it is going to go. Rails is an 'opinionated' framework, it does a lot of work autogenerating in the background by being a DSL. But the future of frameworks are more API based frameworks that give more freedom and customizability to the programmer. >And why is GO encouraged? Even though its a compiled language, it takes a lot of syntax ideas from dynamic scripting languages. Because its a compiled language it is fast and low level and so can do a lot of system level server work. It has message passing concurrency built into the language. Its garbage collected so its as easy to use as scripting languages when handling data in memory. The fact that it does not force object orientation means that when connecting functions to structs are not part of any OO data type system. Conventional OO is nice when you know your program is going to always have the same type structure and never change. But web programming tends to change and evolve so Go lets you loosely connect functions as methods to structs(which act as classes) but have the freedom to be able to change them at any time by not being constrained to OO class types

>>185 I think both are quite nice. I don't know very much about Rails or Sinatra and I am not that interested in web development… But I like the Python scientific stack and it's easy to quickly present results without much background knowledge. >>184 May you tell me what a realtime web application is? I am still looking for a frontend framework to use but I don't really understand their differences… Vue and React are mainly for single page applications, is that right?

I've been working on making React Native apps recently. I had never done native dev before that. I found that hardest part was dealing with the workflow, getting everything setup properly, figuring out how to store files, how to access them, etc. A ton of little, confusing, timesinks. I ended up having to code a native module to play/store files too, which was a major pain in the ass. Now that it's done, I can spit out variants very easily. I also just finished this, a React app: https://learntorecognizenumbers.com First time I've developed a website with React.. was pretty simple, but I don't have any network or database calls. >>185 >Opinions on Python/Django or flasl for the back end? Just use Django imo. I created a site in Flask (ecommerce) and by the time I was done I had hacked so much soykaf on top of Flask, it was a huge, confusing, mess. Would have been easier to stick with Django from the start and use the structures the framework provides.

>>51 >advanced web development >lists angular and react. Surely you see how stupid you are.

>>202 no I cant, why dont you tell me a better way to make client-side dynamic websites

>>202 see >>186 enlarge your post today, for free; call 999-ENLARGE

I founded a startup on clojure / cljs and now I can't go back. I'm taking a job working remote from Austin tx doing fulltime clojurescript soon. It's awesome!

Any lains ever used sanic (async python3 webserver) in production? It looks pretty good in theory, but I don't know...

>>207 I'm trying to get into clojure, what framework do you use to handle basic webdev stuff like handling http requests and to interface with your db ?

I'm curious. Why isn't Scala considered as advanced?

>>277 I think OP mixed "advanced" with "recent". Just treat it as "modern web dev thread".

>>277 OP here, nothing wrong with Scala, it is advanced, but the only people I know who like Scala are Java programmers. I think Groovy is doing more to extend the Java ecosystem into web programming with Groovy on Grails

>>278 "trending on twitter webdev thread"

Feel free to create one more web development thread; simply cease complaining in this one.

>>200 actually a fun project, guess I will be using it

https://learnbchs.org/

>>808 wh-what? who use this?

>>810 No one. It's a bad joke.

>>808 While this is obviously not suited for real life web development, it's still pretty interesting. I always wondered how you would write a web application if you had to use C or something similar.

>>822 There are actually a few web frameworks for C, I don't think anybody writes full web applications with them though. Perhaps microservices.

>>810 undeadly.org probably lobste.rs can other openbsd developers also work with C for web dev, such as flak from tedunangst, anoncvs. IIRC, marc.info too.

>>824 >probably lobste.rs Nope, it's a rails app: https://github.com/jcs/lobsters Who would be crazy enough to build such a big web app in C?

>>824 Forgot man.openbsd.org and sblg: https://kristaps.bsd.lv/sblg

>>825 Yes, thanks to point out. >Who would be crazy enough to build such a big web app in C? Everyone who cares about simplicity? I would use it, personally.

>>827 Simplicity from what standpoint? I really doubt a big web app written in C would have a simple codebase. >>824 flak is written in Go. http://www.tedunangst.com/flak/post/humungus

>>827 >Everyone who cares about simplicity? I would use it, personally. How is a website built in C more simple than a website built in Node? I don't mean that as an accusation, i literally cannot see any aspect that would be more simple. Performance, security, code clarity. All of which seem much more laborious in C, not only because C is inherently more difficult to deal with from a security point of view, but because a framework in C will probably have a fraction of the support express (or any web-driven language/framework) has.

>>830 >How is a website built in C more simple than a website built in Node? I think its important to point out that node is itself written in C++ and that Javascript is used as a wrapper language. Unlike most every other language, Javascript does not have a standard library, it cant do I/O or anything else on its own.

>>833 >can't do anything on it's own. Neither can any language that uses a runtime instead of syscalls. What are you even getting at here besides stating the obvious but passing it off as something "wise" to people who don't know better?

>>834 Im not stating the obvious, Javascript is the only language I know of that cant be used as a standalone language. And a lot of people are not aware that node itself is written in C++. A comparison was made between writing a website in node and C, that is not a valid comparison. Not trying to be 'wise', just clearing up wrong assumptions

>>833 I know, that does not answer any of my questions.

I'm developing small websites for hosting on CloudFront, with the dynamic portions (generally a contact form) hosted on a small server. I've been mulling over Hugo vs Metalsmith for Static Site Generation. Hugo seems really good for blogs, and it's super portable (compiled Go binary), but I'm not sure if I want to invest in the Theme API so I can adapt it to more general sites. Metalsmith is on the total opposite side of the spectrum for SSG, being a super pluggable toolchain. Anyone else do static-site development? Cost to performance wise, static sites are sexy. On CloudFront it's $3.40 per 100,000 page views (assuming 400KB) 100000 * 0.085 / (1GB / 400KB)

>>841 I ended up writing my own static site generator in Javascript. It's very simple, it just uses the ES6 template strings as a templating engine, and takes markdown files and compiles them into HTML. Works remarkably well provided you don't need pre-built theme support.

>>835 > Javascript is the only language I know of that cant be used as a standalone language. Are you SURE you don't mean self-hosting? Because having a runtime or compiler written in another language isn't anything to scoff at considering it's really common and not weird at all.

>>829 >Simplicity from what standpoint? From the less abstraction standpoint. From the no bloated framework standpoint too. >>830 >How is a website built in C more simple than a website built in Node? Same as above. Your perspective about this problem is user centered. You, for sure, will have a much faster and easiness using Node. But that's a perspective looking only for the comfort and convenience of the developer. If you approach this by another perspective, you'll see that it's much more simple (machine code wise).

>>845 Actually, I think that by using plain C you're building way worse abstractions. The "machine code" bullsoykaf you talk about is hardly relevant, and it all depends on the compiler anyway. For example, Ur/Web is a domain-specific language that's focused writing web applications, and it uses an optimizing compiler that produces C code. The resulting code is way safer and more performant than any application a developer would bother to write directly in C, because writing code that both runs fast and is pleasant to read is a fuarrrking drag in C. So it's not about eliminating the abstractions, it's about choosing the right ones. With enough macros you could write a web framework in Lisp that runs just as fast as a painstakingly optimized application written in C.

>>847 >>845 (me) >it's about choosing the right ones. good point.

>>845 >From the less abstraction standpoint. What? Computer science is built on abstraction, it's not something to be ignored or treated as a negative aspect, unless this said abstraction creates performance, security or code clarity issues. Which you haven't mentioned, and i don't know what <language> has a defective abstraction layer, enough to warrant rework. >will have a much faster and easiness using Node. But that's a perspective looking only for the comfort and convenience of the developer. But that's a very basic principle of good software engineering. Having abstraction is not for the good quality of life for the developer, it never was. It's more security and efficiency for the final product because humans are flawed, thus try to minimize the risks of either your lack of attention or knowledge. Not only that, but you haven't provided any positive arguments for developing in C. What, exactly, is C able to do that makes it worth it performance issues and security issues? C is a difficult language in the sense that it's very easy to fuarrrk up performance or security (and usually one implies the other). So what is there to make up for it? Any common "hipster" language is patched days/hours after a breach is exposed. Often times it also provides solid safety for the end user, even if this is your first website and you have no idea what you're doing. Performance is a non-issue except if you're using a CMS, and even then it depends on how much the CMS allows you to tweak it. Non issue because in either C or Ruby, the end user will always be the bottleneck. Code clarity i don't even need to write anything. So unless you disagree, "hipster" languages and frameworks have more security, more clarity (which, as you probably know promotes realistically less breaches and bugs) and performance is objectively not sensitive. So what exactly does C offer for web development, what does C do better?

>>844 >Are you SURE you don't mean self-hosting? I stated very clearly what I meant, I said that there are no javascript implementations that include any libraries to do even the simplest I/O, thats a very simple statement and I dont get why you want to conflate it with issues about self-hosting and runtimes written in another compiler. If you make another ridiculous interpretation of of one of my posts I'm not going to continue to respond.

>>849 You win. As I've said, good point. The website I pointed about C webdev is not mine. It's from an openbsd developer. Although I don't agree with some of your arguments, such as: >But that's a very basic principle of good software engineering. Not for me. For me the formalism is the basic principle, not user/developer centered. But, anyway, every other thing you've said makes sense. Ignore abstraction would be dumb. I just don't think that javascript and ruby are a good language to do it. Maybe Go, but for fuarrrks sake, not JS. https://github.com/j4cbo/stilts https://github.com/urweb/urweb

>>849 >So what exactly does C offer for web development, what does C do better? There are times where you need a fast systems level language because a scripting language just cant handle the load of large scale server services. This video given by Yehuda Katz explains how he had to use Rust as Ruby just couldnt handle the load of the server utility he was designing: https://www.youtube.com/watch?v=GktVBv76fe0&t=383s

>>855 There will always be edge cases, that wasn't the focus of the discussion i think. Just average web development scenario.

>>263 There aren't really many frameworks in clojure. There kind of are but usually your app is made of many libraries. you could say Frameworks are used to keep track of stateful processes that your app needs to work (db, messaging, logging, etc.). -- my favorite is mount. anyway For noobies I'd reccomend checking out Luminus. As a seasoned clojure/script dev, I agree with like 85% of the library choices there. so if you learn those libraries you'll be in a good position to.

>>263 As a general rule for any programming language I think its best to start out with simple Sinatra-like microframeworks before you move on to big opinionated monolithic frameworks. Start out simple, learn the basics first, these books can help.

>>845 The sheer quantity of websites that need to be created, maintained, modified, and secured + "time is money" is why languages like C aren't used.

>>189 >Even though its a compiled language, it takes a lot of syntax ideas from dynamic scripting languages. That's totally how I've felt, I came from Python and I've always felt like Go had a lot of the good stuff from Python. Very simple, very intuitive, but with concurrecy tools that don't suck

>>189 I feel you! I wrote a soykafty webserver in golang and now coworkers rely on it and are requesting features. Sadly this was my first time using golang and turning json into structs and back is a mess. It's falling apart at the seams. But it's still fun to write in and maybe I'll spend 10 hours rewriting it someday. That aside, anyone have any good golang libraries to share?

This may or may not go here, but it looked like a good thread to ask it in. Do you think JavaScript will ever be completely or mostly replaced with something else?

>>2610 JS is the new PHP. Just like PHP, there is a period of adoption, mass usage as it becomes a meme language, then a slow rise/plateau as it gets picked up by everyone and their mothers, and a slow, slow decline as the next big thing is taught in schools. It's worth learning, especially if you'll be working with systems that aren't bleeding edge and have a lot of talented people working on them. Even then, I'm sure there will be some ES6 in there.

>>2611 Except that as os 2017 people are still making new software in PHP (see the 4kev thread)

>>2611 What will replace JavaScript, though? Web Assembly? It would need to be something all browser vendors agree upon, if not. Otherwise, we'll be back when "Works best in X" was common.

>>2610 Javascript is a brilliant language, the fact that it uses prototype OO allows its use of high order functions to be a lot more powerful than Python or Ruby because the scope of prototype OO is much more free'er than class based OO. The fact that both Dart and Typescript failed completely proves that no one wants class based OO in Javascript. The only thing that holds back Javascript is its very weak iterator and mapping functions which means that for and while loops are used way too much in Javascript compared with Python and Ruby. I personally think that ES6 syntax is too wonky as it tries to preserve backwards compatibility with ES5. I really like Coffeescript a lot as it adds all the modern features you would want in Javascript and wish it was a standalone language built into browsers instead of a transpiler language. >>2617 >>2619 Please do me a favor and dont feed the 'meme language' troll in my thread. There is a certain person (yes, it is one person) who goes around calling every new language a meme language, this adds nothing to the discussion except ignorance.

>>2611 >JS is the new PHP It's not about hype. Javascript is merely the lowest common denominator that all browser vendors support. The exact same way C is for processors. >>2620 >Javascript is a brilliant language, the fact that it uses prototype OO allows its use of high order functions to be a lot more powerful ... The fact that both Dart and Typescript failed completely proves that no one wants class based OO in Javascript Being popular is not the same as being superior.

>>2620 Dart most likely didn't catch on because only Chrome supports it, last I checked, which means it's not really viable. Other than CoffeeScript (Which has been mentioned in this thread before), what do you guys thing will be the JS-killer? As someone who is trying to get into a web development role, with requirements for entry-level positions ever increasing, the idea of JavaScript dying is mildly worrying.

>>2626 >what do you guys thing will be the JS-killer? The big question is whether or not Web Assembly will work as well as people say it will. Ideally the best option for supporting languages in browsers is to give people the option of being able to run any language binary or interpreter. Since Web Assembly is a VM or sorts I dont think there will be much speed advantage of running a compiled language vs a interpreted language considering the compiled binary is running on a VM.

>>2626 It'll be WebAssembly, but not any time soon. They have GC primitives on their long term roadmap; once implemented, browser vendors will eventually stop maintaining their js engines and just relegate JavaScript to nearly the same position as other dynamic languages and it'll lose its favored status. Web developers tend to be the restless sort and will wander off toward the first flavor-of-the-week that gets decent support for compiling to wasm.

>>2626 Dart and CoffeeScript both transcompile to Javascript; they can't replace it.

>>2659 It would be possible to make both Dart and Coffeescript a stand-alone programming language rather than a transpiler language and embed those languages in the browser. So yes they could replace js

>>2626 I don't think you need to worry about that, JS isn't gonna die anytime soon. >>2628 >Since Web Assembly is a VM or sorts I dont think there will be much speed advantage of running a compiled language vs a interpreted language Wrong, a VM with very low-level instructions like webasm's has a lot of potential for performing huge optimizations. The last webasm previews ran the same code (compiled from C to both js and webasm) much faster than the js version. >>2651 >once implemented, browser vendors will eventually stop maintaining their js engines and just relegate JavaScript to nearly the same position as other dynamic languages I'm not so sure about this. On one hand, the webasm proponents are all stressing that webasm will be a tool to aid JS, and not the other way around. On the other, it's possible that they could implement a JS compiler for webasm and just use that, which would make a separate JS virtual machine redundant. >>2659 >>2661 Dart can be compiled to both js and its own VM's bytecode, and I think you could easily compile the VM to webasm with emscripten already. That said, it will certainly not kill JS.

>>185 I very much like flask for small/quick webapps. I guess it is a sinatra clone but its a sinatra clone i like.

>>824 lobste.rs is rails

OK, here goes cool story about my Sunday. In the morning I installed simple-react-app and were trying to get posts from my Tumble dashboard with some npm modules. Every module gives me an error about CORS and i deployed my app to Heroku. How do you think what I see now? net::ERR_SSL_PROTOCOL_ERROR This fuarrrking soykaf do not interact with APIs by default too. Is there another way to get my app on localhost to wor with remote APIs such as YouTube and Tumblr?

What are good, small static site generators without too much bloat? http://gohugo.io/ Seems nice but wanted to see what Lains have heard of

>>2699 Thats interesting, Im learning Go so i will want to try that out. I like site generators like Jekyll that give a lot of programatic control.

>>2699 I've been considering compiling TeX to HTML, but I currently just write it manually. I was working on a simple HTML generator program, but got bored with it.

>>2704 >I've been considering compiling TeX to HTML, but I currently just write it manually. This will not work. Translating a non trivial (and different each time) tex layout to CSS is basically impossible because of different screen sizes,

>>2710 Well, the TeX layout is trivial. The handwritten HTML is mostly <p> tags with some bolding, centering, and hyperlinks. It's so trivial, that my current thinking is to simply maintain two versions, since the TeX can be arrived at almost entirely by a copy and paste from the rendered HTML.

>>51 >not allowed: >PHP, Java, C#, Rails >said guy, while posting on a php written board >Go Not for a big projects, good only for microservices or little projects >Elixir Very green, but promising >Clojure Well you can code for food on that one >Angular Hey boi, want to support old Angular 1 legacy project? >React Get ready to clone webpack boilerplate of the boilerplates >Coffeescript Not needed >Clojurescript Look for Clojure >Elm That one is not so bad >Typescript Well, good to use with angular 2 or other microsoft projects

>>2704 Try KaTex

>>2724 >not allowed: >PHP, Java, C#, Rails >said guy, while posting on a php written board I assume that's because OP thinks they are boring and not worth discussing, not that they are not worth using.

>>2734 >I assume that's because OP thinks they are boring and not worth discussing, not that they are not worth using. Thats true for Java/C# and Ruby, I (the OP) do think that PHP is obsolete and should have been replaced by another language. One could argue that microframeworks like Sinatra and Django replace vanilla PHP. But Java/C# will continue to completely dominate enterprise programming unless some extraordinary new technology replaces it. Rails is still the easiest CRUD framework to learn although it is very restrained to just doing CRUD web apps and nothing else.

I'm curious about the Scala + ScalaJS stack. Does anyone have experience with it? ScalaJS is supposed to have really good interop with Javascript libraries.

Will I survive If I do not learn C# or Java? In my current internship I am using Rails. I do not find Java or C# interesting. I think I would rather spend my time learning languages and frameworks like C/C++, NodeJs, Python/Django, PHP, and so on. Nothing too much "Entreprise" . Can I land on my feet not using/learning C# or Java?

finally found a tutorial series that's enjoyable to read: https://internetingishard.com/html-and-css/ any other high quality guides?

>>2767 Good reference materials (not necessarily tutorials, but might help you nonetheless): http://cssreference.io/ http://htmlreference.io/ Tutorials: http://learn.shayhowe.com/advanced-html-css/ http://marksheet.io/ https://zellwk.com/blog/understanding-css-box-sizing/ http://learn.shayhowe.com/advanced-html-css/

>>2774 Also a reference, but the mozilla developer network is fantastic.

Here is a good tutorial on how to do web scraping with Python's Beautiful Soup library: https://www.youtube.com/watch?v=XQgXKtPSzUI&t=1141s

>>2724 >>Go Not for a big projects, good only for microservices or little projects >Go > Not for a big projects, good only for microservices or little projects What are you smoking anon? Digital Ocean and Uber both run on Go. Big projects are microservices these days.

>>93 Coffeescript has already been in freefall for a while. Typescript... no. Static type checking is just too useful.

>>2734 php is not worth using

If Go is cutting edge web development, then so is https://learnbchs.org/

>>5122 Go is cutting edge because of the culture around it. They seem to be ridiculously obsessed with microservices, docker, kubernetes, et al. way more than any other language is.

>>5122 Take your try hard bullsoykaf somewhere else, Im getting really sick of all the pissy basement dwellers with their 'C is the only language' meme, fuarrrk off with that. This is advanced web development thread, if you dont like it, or dont think its really advanced, then by all means start your own advanced web thread. I dont need idiots who spew memes and cant back anything up with facts.(Argue in good faith and avoid spilling soykaf.)

>>5123 >Go is cutting edge because of the culture around it. They seem to be ridiculously obsessed with microservices, docker, kubernetes, et al. way more than any other language is. This is only Google structuring the language around their own needs. It is not a reflection of the industry as a whole or what anyone except Google necessarily needs. >>5124 >Im getting really sick of all the pissy basement dwellers with their 'C is the only language' meme, fuarrrk off with that. >>5122 was disparaging Go, not advocating C. Read more carefully before having childish outbursts in future.

>>5125 >This is only Google structuring the language around their own needs. It is not a reflection of the industry as a whole or what anyone except Google necessarily needs. And to further my point, no one cares about your opinion about what Google thinks of Go. Youre doing nothing but playing off stupid memes about programming languages. You have no technical input to this discussian, you are a troll.(Argue in good faith and avoid spilling soykaf.)

>>5126 >>5128 Go is not an advanced language. Go cannot do abstract data structures, unless they're already baked in; Go can only do concrete data structures. Go's error handling requires the programmer to remember and perform manual checks over and over. Go's concurrency is overrated and available in most languages. Go was designed specifically so young undergraduates or recently graduated students can quickly pick it up rather than for power or safety. Go only gets any attention because it's from Google.

>>5131 >Go's error handling requires the programmer to remember and perform manual checks over and over. Is there a language that doesn't? Even the try/catch paradigm forces you to handle specific errors in specific ways. And don't reply with Erlang's "let it fail" philosophy since that's not error handling. I don't even like Go but your criticism doesn't seem valid to me.

>>5128 >no one cares about your opinion about what Google thinks of Go. Correct me if I'm wrong but Google has full control over Go the programming language. It's one of their look-but-don't-touch "open source" projects like Chromium. So what Google thinks is actually the only thing that matters. >advanced web programming languages like Go Multiple people seem to be disagreeing with you here with well reasoned arguments. Feel free to post some content instead of empty insults.

>>5131 >>5135 Go hate threads get posted almost everyday on /g/, now you want to bring that here. Im not wasting my time arguing about stupid memes like its a "Google controlled language", fine. These are all just lame ass attempts and propping up your failing and obsolete C++ language, Im not biting, you can keep hating Go, I'll keep using Go. Mods: Im asking you to clear out all the programming language memes and propaganda from my thread. This is OT, if someone wants to hate on Go they can start their own Go hate thread.(Do not call for mods, or announce reports in a thread.)

>>5135 >Correct me if I'm wrong but Google has full control over Go the programming language. Go isn't "owned" by google, even though they created it. The core developers mostly work at google, but they have rejected features that googlers wanted but they didn't, they're autonomous. The discussions are entirely open on the mailing lists, there's no secret meetings, just Rob Pike not letting people add things he doesn't like (which is fine considering it's his language). That said, go still is like kicking dead whales down the beach but Pike controls it, not google.

>>5140 >That said, go still is like kicking dead whales down the beach Mods!!! I am asking you guys to clean my thread, or are programming language flame war threads ok now? Because if they are I will go ahead and start a C++ vs Go thread, not that it would be interesting to see when they can only come back with muh templates muh exceptions(Do not call for mods, or announce reports in a thread.)

>>5134 There's a difference between immediately crashing when a function fails and returning an invalid value that will cause the program to fail some time later. The try/catch paradigm isn't perfect, but it at least defaults to stopping the program instead of letting it continue in an invalid state. Or in other words, you have to check in Go even when all you want to do is stop the program. >>5138 >>5141 If a thread is started to discuss several things, and OP lists them out, and one of those things is Go, then the thread will probably include a conversation about Go at some point. Problems with Go are likely to be regurgitated in Go threads until they're resolved. You are the only one who seems upset or surprised by this.

>>5135 >>5140 I think the point being made is best summed up by, "It's one of their look-but-don't-touch "open source" projects like Chromium.". Google will make open source projects to extract labor and build confidence, but they rarely let anyone else in. Corporate Google may not have full control of Go or Chromium, but only Google employees have the authority to move things into the canonical branch, afaik.

>>5134 try haskell, or any language (C#, F#, rust, scala..) that can make a maybe or either monad. Sorry, I have to disagree also with the notion that the listed technologies are cutting edge. They mostly cover rehashed 70s, 80s programming paradigms. Elm is pretty neat though. I'm not trying to start a flamewar but I think using a language from base principles and writing your own frameworks will help anyone learn faster. But then all who climb the mountain see the same peak. Good luck.

>>5146 >The try/catch paradigm isn't perfect, but it at least defaults to stopping the program instead of letting it continue in an invalid state. Or in other words, you have to check in Go even when all you want to do is stop the program. Are you talking about doing something like this ? private void fun (Object... args) { try { // 50 lines of code here } catch (Exception e) { e.printStackTrace(); System.exit(); } } If yes, this is disgusting and you shouldn't do that in your programs ever. There's always a way to handle specific errors and, if you can't recover from them, display a useful message to tell the user exactly what's going wrong. Or are you saying that you shouldn't even try to catch your errors and have your program silently fail, JavaScript style? This is even more terrible. >>5150 >try haskell, or any language (C#, F#, rust, scala..) that can make a maybe or either monad. You still have to check everything though. enum errors { Reason1, Reason2, Reason3 }; match important_function() { Err(errors:Reason1) => do_something(), Err(errors:Reason2) => do_something_else(), Err(errors:Reason3) => do_another_thing(), Ok(_) => print!("Success!") } The syntax is certainly more concise, but you still have to keep checking for every kind of error.

Criticism of Go in a thread encompassing Go isn't invalid. The criticism here is well-reasoned, I think, and so abides by the rules. >>5141 Starting a thread purely as an offshoot of an argument, in the manner you have, is frowned upon.

>>5156 >Are you talking about doing something like this? No, what I mean is that an uncaught exception will crash the program whether or not I catch it. This is good, because it stops the program from continuing in an invalid state. Ideally I should catch all exceptions and handle them. However, if I choose not to catch because there's no meaningful way to recover, I'm lazy, or I'm forgetful, then the program will at least crash before ruining any local files. >You still have to check everything though. Maybe or Either monads are useful because they encourage you to check at the site the error occurs and force you to check eventually. Programmers are encouraged to check early because if they don't take the 'real' value out of the Maybe or Either early, then whatever they pass the monad to or return it to has to extract the value. Passing a Maybe monad instead of the value inside of it complicates function signatures, so usually programmers will just extract the value the moment a Maybe monad is returned. Programmers are forced to check by the way monad works. In Java, if you try to extract a value from an Optional type with nothing inside then an exception will be thrown. If a function just returns a null reference or -1 to signal failure, then it's possible for that to be returned or passed somewhere else with an error message that doesn't help at all or, even worse, no crash at all. With a monad, the check has to be made and it tends to be made closer to where the problem is. Worst case with monads or exceptions is the program crashes. Worst case without monads or exceptions is the program continues running while destroying data or equipment.

>>5156 >still have to check everything that's not true, you can still fmap calculations over maybe / either types if any of the values in use are Nothing then that will bubble up the call stack. You never even have to handle the error if you don't want to and can still have a valid program. Of course doing this is not appropriate for all programs, sometimes you will want different behaviour for different errors but it is entirely up to you. The idea of using monads rather than exceptions is that you keep all undefined behaviour separate from the meat of your program.

>>5160 one of the big reasons to use monads (in the way we are talking about) is as a type safe way to describe a computation such that the compiler will not let you compile a program that will crash. it saves you from undefined behaviour. for example if you use a maybe monad you will never have a null reference exception.

>>5160 While you certainly have a point, I'd like to point out that you don't necessarily want your programs to crash in case of uncaught errors. If you get an error because you're closing a socket that was already closed by the client it was connected to, crashing doesn't make sense. The program should just keep on running. Handling this kind of error is time consuming for programmers while benefits aren't that great. Since I think Go is meant to be one of these "move fast, break things" programming languages I think it makes sense for it to have the error-handling paradigm it has. Of course, I don't think every language should handle errors this way, for example it clearly wouldn't make sense for Rust to abandon monads for a less-safe counterpart. >>5163 Every error has a different meaning and a different way to be recovered from since often the function that throws the error depends on code that was executed before (e.g. allocated memory, mutated structures, opened file descriptors...). In my opinion, you really should make sure you have specific code to handle failures. This is one of the reasons why I really like the goto-cleanup paradigm C has.

>>5140 > they have rejected features that googlers wanted but they didn't, they're autonomous. Do you have a specific example in mind? I tried to look around but it's a difficult thing to search for. Also related $ whois golang.org ... Registrant Organization: Google Inc. ... Registrant Email: dns-admin@google.com

>>5178 Name me one open source programming language that allows *anyone* to go in and change the core syntax that everyone uses?

>>5163 Every error has a different meaning and a different way to be recovered from since often the function that throws the error depends on code that was executed before (e.g. allocated memory, mutated structures, opened file descriptors...). In my opinion, you really should make sure you have specific code to handle failures. This is one of the reasons why I really like the goto-cleanup paradigm C has. Allocated memory and opened file descriptors will be automatically by RAII though (Go would probably use deferred calls for this). And mutated structures is handled by having immutability by default and avoiding mutation as much as possible unless it is absolutely necessary. I think "don't mutate something irreversibly to do something that might fail" is a fairly basic rule one should follow. There should be no reason to explicitly mutate something unless avoiding mutation increases the complexity of your algorithm. The ideal that you should aim for is to have all errors handled by just leaving the current scope and starting over. Sadly, Go seems to encourage the exact opposite of this philosophy, i.e. C-like imperative thinking with mutable state which leads to thirty year old bugs like shellshock.

>>5183 Literally any Lisp-family language.

>>5186 ha ha, funny >Lisp is written in itself so when I extend the language I am extending the core language I am aware of this, and this is a lame attempt at making a point about changing a language standard

>>5183 >Name me one open source programming language that allows *anyone* to go in and change the core syntax that everyone uses? Open source doesn't work like that. Most people submit patches or "pull requests" in today's lingo and only a few people central to the project have commit bits but that's not what we're talking about here. >>5178 pointed out that Google literally owns the golang domain. Mozilla doesn't own the rust-lang domain. Actually Rust is a good example of a genuine community project with an actual boundary between the corporate sponsor. C and C++ are languages directed by committees of individuals from around the world who are either independent to acting on behalf of a company. Literally anyone can go to committee meetings and have their say. The reason that is a good thing is because they vote on language changes to get the best outcome for everyone. The criticism being leveled at Go is that Google pretends it is an open source project but really Google makes all the decisions and everyone else can fuarrrk off. Which is pretty uncool.

>>5189 >who are either independent OR acting on behalf of a company

>>5189 >The criticism being leveled at Go is that Google pretends it is an open source project but really Google makes all the decisions and everyone else can fuarrrk off. Which is pretty uncool. Most every language is like that, Python, Perl, Ruby, D, Swift, all have a benevelent dictator that controls what the language standard will be. You are just drumming up stupid bullsoykaf that doesnt belong in this thread. I do have another thread where you can level these *serious* issues at Go.

>>5187 To give an example: CLOS started off as a library made by Users, which was eventually included as a core language feature. There's a ton of similar examples in modern languages with macros such as Rust, Nim, or Julia. Features can start off as macros and then be included as an actual feature if a library containing a macro-implemented feature is popular.

>>5171 >I'd like to point out that you don't necessarily want your programs to crash in case of uncaught errors. No, you do always want to crash in case of *uncaught* errors. If there's an exception that is safe to handle, like one thrown due to a client prematurely ending a connection, then you catch it and handle it explicitly, even if all you do is discard the exception and proceed. Good systems are fail safe. Using ignorable return values to indicate errors is bad specifically because it is not fail safe.

>>5191 >Most every language is like that, Python, Perl, Ruby, D, Swift, all have a benevelent dictator There is a nuance you are missing. Guido, Larry Wall and Matz are just individuals who started cool languages. D was started by a company but the community wrestled control from them. Swift is in the exact same boat as Go but I wouldn't brag about it. >>5189 >Mozilla doesn't own the rust-lang domain. It wouldn't matter if they did because Mozilla is a non-profit. The reason they exist is to make cool things and keep the internet open. Google and Apple only exist to make money for shareholders. If you trust Google to "do the right" thing in any context except making money for themselves then you are very foolish. So I think people are right to be suspicious of pseudo-open source, pseudo-community languages like Go and Swift.

An interesting article started going around today about a project that dumped Go for Node.js. The tl;dr was that Go was too slow and took too much RAM. The interesting thing is that I couldn't find any indication in the surrounding commentary that they were using the language incorrectly. It's just that Go is genuinely terrible for that type of problem which is surprising. https://github.com/maxpert/raspchat/releases/tag/v1.0.0-alpha

>>5214 >Mozilla doesn't own the rust-lang domain. >It wouldn't matter if they did because Mozilla is a non-profit. The reason they exist is to make cool things and keep the internet open. Google and Apple only exist to make money for shareholders. If you trust Google to "do the right" thing in any context except making money for themselves then you are very foolish. >So I think people are right to be suspicious of pseudo-open source, pseudo-community languages like Go and Swift. Thats a nice conspiracy theory you have except there is such thing as language standards. This means that ANYONE can implement their own compiler in any of these languages (even C# or VB have open standards) so you dont have to live in fear that your programming language will be subverted to the agenda of corporate subjugation. Python, Ruby, D, Go, Javascript all have many different compiler implementations.

>>277 Scala's a good choice if you like the idea of carpal tunnel syndrome.

>>5246 Defining ADT's through subtyping is a perfectly fine way to do it. The issue here is that Scala is a bit verbose with the case class and extend keywords instead of using indentation and arrow or double colon operators to do it. First of all, it gives you a full GADT instead of just ADT functionality, since you can specialize the generic parameter of Either in the extends declaration. So the better comparison would be with Haskell's GADT notation, not the traditional ADT notation: data Either a b where Left :: a -> Either a b Right:: b -> Either a b Which is still more compact, but wouldn't be if you suddenly also wanted to be able to define the constructors later instead of putting them in an indented block below the declaration. Secondly, it lets you add more cases instead of being restricted to the cases you define in the declaration. Classical ADT's are limited by the expression problem, while subtypes of an abstract type are not. You define functions on just the subtypes. If they cover all cases, you can use them on the supertype as well. With that said, the union types that will be added in Dotty are probably a better way to handle this for a plain GADT: case class Left[A](value: A) case class Right[A](value: B) Either[A,B] = Left[A] | Right[B]

>>5253 * A plain ADT